Design principles
Favour composition over Inheritance
Reasons:
Inheritance is a “is a” relatioship, creates strong cohesion of subclasses to their parent classes.
Does not really separate code as sub/child classes still are the type of parent.
Composition provides a way to actually separate code/functionality into separate classes. By assigning properties of those types the functionality can be attributed to the class.
Sign of “good” code is if there is one single “dirty” piece of code that knows the details/ specifics and patches things up then you have done a good job.
Composition provides more flexibility, better re-use.
Coupling
Degree in which parts of the code are dependent on each other. Low coupling means independent modules/functios etc. Helps in making the parts more reusable. Easier to update.
There is always going to be coupling as parts make use of each other. The point is to be aware and decide where and how to create the coupling.
To keep (some) control over maintainability of the software. Its a strategic effort to choose where you want to have what type of coupling.
Content Coupling
- strong type of coupling, try to avoid!
- content coupling is when a function updates something directly which is passed in as an argument. (modifies something / state of something outside of its own scope)
- problem is that coupling occurs on low level implementation between classes, so the acting function or class needs to know/depends on the internal implementation of the other class.
Can be avoided somewhat by creating functions (setters getters) so that the internal parameters are "encapsulated".
Global coupling
functions share global data, directly modify something out of their own scope. Try to avoid!
Import coupling
Imports that are needed to make a file work correctly
Its not a bad thing, but its coupling, try not to use libraries if there is a alternative which does not need the import.
External coupling
Reliance on a service provided by external system. Like a Rest
API.
Control Coupling
one part of the application controls the flow of another part of the application by passing control information. (for instance passing a flag that controls behaviour)
to avoid split the function up in multple functions, increases readibility and increases cohesion.
The coupling is still there if code is split in multiple functinos, as now some other parts of the code select which function to call. But having one function to group the logic together seems a unecessary layer.
Stamp / Data Structure Coupling
When models share a composit data structure such as a class, struct, tuple and use only a part of it.
Its not something bad, but possibly can be avoided by using abstraction (like protocol classes). Then the coupling to the explicit (bigger) class is removed. In other words the scope of the dependency is than smaller.
Data coupling
- When modules interact with each other and methods share data through parameters. Is a “good” type of coupling as it is a low level data.
Message Coupling
when parts of program is connected via messages (pub sub)
the coupling is created by the content/structure of the messages.
law of demeter
principle of least knowledge, units should only talk or interact with closely related units.