User Tools
Sidebar
start
Table of Contents
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.
Information expert principle
Assign a function to the class that can perform it best (as in has the data to be able to do it).
- General Responsibility Assignment Software Patterns (GRASP)
Overloading
Single dispatch
Overload in typing library
Is for type checking only, the actual implementation is still just done in one function. I guess these days since you can define multiple input types and return types with type hints i guess this decorator may be considered obsolete.
Inheritance
Inheritence is very tight coupling. Should be used with care as complex inheritance hierachies can make maintence very complicated. Try not to go deeper than 1 level of inheritance.
Abstraction
Abstract base classes
Concept similar to interfaces, its a contract for sub classes.
Protocol classes
Defines a interface by defining the properties and functions a class can adhere to. Its more close to duck typing. Does not rely on inheritance. In runtime the interpreter checks if all the members match.
Protocols allow for finer granularity (interface segregation), more protocols can be combined in a class before it becomes messy as there is less tight coupling in code.
Multiple inheritance
Python supports multiple inheritance. So a class can have multiple parent classes. The method resolution order (left to right by defined clases) is important to take into account as it defines which method in parent class gets called if the same method exists in multiple classes.
The multiple inheritance feature is also named mixins as you mix multiple types of classes actually multiple inheritance tree's together.
When using mixins you need to know the implementation details of classes to figure out a resolution order that will work. So the class structure can become complex and hard to work with.
Arjan advises against using mixins, and when used the parent classes should only have methods so that initialisation issues (think of resolution order) with parameters are avoided.
Mixin classes should not have instance variables.
So its powerfull but try to avoid and use with care as it will get complicated.
According to Python Mixin (Pythontutorial.net) a mixin class can be seen as the interface concept but with implementation. “A mixin bundles a set of methods for reuse”
start.txt · Last modified: by Niels
