Data - Operation - Integration and Glue
Trying to build up software by atom components like molecules
one year ago I started separation of my classes into data, operation, input, output, integration and glue classes. This was inspired by blog of Ralf Westphal:
If you follow this approach, you don't need any mocking or testdoubles anymore. Yes really!!
And then you can easily write tests.
I think, this may be a new programming paradigm, I call it "molecular software development".
But how to illustrate this?
Think of classes like atoms, then a SW component will be a molecule.
D: Data (Daten)
B: Binder, Glue (Verbinder)
Data classes are full egocentric, they only can be connected with other data. They have no complex functionality, also validation is done in separate operation classes. They will be passed through the system.
Operations know only themselves and data objects. They have inputs (methods) and cannot directly call other operations or integrations. To call something outside, they have to call glue connector classes (lambdas, if existing in programming language). Here all the logic will be implemented. Only here! Here tests are needed. Many tests, but easy to implement with no need for mocking or testdoubles!
Converter are special operations that transform data between different classes or versions. They transform i.e. car.v1 into car.v2 and create, move or change attributes to do that. So all other operations use only a fix version of data, i.e. op1 use car.v1, op2 car.v2.
Input and Output are separated into own operation classes, because they are difficult to test.
Integrators and glue connectors should not contain complex logic, no logic is best case. They just convert data and call operations or other integrators. They usually need not to be tested, but they can. Glue is given to operator classes to call something in outside.
Factory or builder classes are creating instances and combine them to components or applications.
The idea of "molecular software development" is now not to allow other connections than described above. In best case it would be impossible to violate these rules by development environment.
In very small projects everything may be mixed in a single class, but methods should NOT mix behavior, so you will get operation methods, integration methods, input and output methods.
To be continued...