Complexity kills. It sucks the life out of developers, it makes products difficult to plan, build, and test.
—Ray Ozzie, CTO, Microsoft Corporation
- cities have teams of people who manage particular parts of the city, the water systems, power systems, traffic, law enforcement, building codes, and so forth
- Although software teams are often organized like that too, the systems they work on often don’t have the same separation of concerns and levels of abstraction.
Software systems should separate the startup process, when the application objects are constructed and the dependencies are “wired” together, from the runtime logic that takes over after startup.
- Lazy initialization
- Separation of concerns
- Test double
- Mock object
move all aspects of construction to main, or modules called by main, and to design the rest of the system assuming that all objects have been constructed and wired up appropriately
To create instances of models use ABSTRACT FACTORY pattern . In this case you can easily swap factories in your test.
- Separating construction from use
- Move responsibility of construction to another authoritative mechanism
Don't create instance of object unless it's used
It is a myth that we can get systems "right the first time."
We implement only today's stories. Then refactor and expand the system to implement new stories tomorrow. This is the essence of iterative and incremental agility.
TDD + Refactoring + Clean code
Research about AOP (aspect-oriented programming) Laravel environment might be using this approach
Annotation processors might be using this approach, take a look at mockfit
- Android room library might be using this approach check it out
- Decorator pattern
An extension language of Java to provide aspect programming
- It is not necessary to do a Big Design Up Front. You can start your architecture so simple to meet user stories and evolve gradually
- Even well-designed apis can be over-kill when they aren't really needed
- Modularity and Separation of concerns make decentralized management and decision making possible.
- You always have to make a choice, even if you’re not 100% sure if it’s the right one. It’s always better to take your best guess, and see how things work out, rather than spend endless hours debating one choice or another. (Analysis paralysis - Head first OOAD)
You might have different frameworks or standards to do a job. In web development eg. Laravel, Django, Flask, Ktor, Asp.net, …
If one minimal framework suffices your customer needs, don't obsessed with big luxiory tools that will only delay delivery
Good DSL minimizes the "communication gap" between a domain concept and the code. Eg. Gradle, SQL, Html, …