I have read a book about OOP named: Object Oriented Analysis and Design. This is the third time I have read that book. Mostly because I think that I memorize by repetition, also because every time in a while I like to re-read those books that I consider valuable.
In this case, I have decided to write down my notes about the book, so I can check this out at any time and refresh my OOP knowledge. So, here are a small subset of my book notes:
About well designed software
“The way to ensure a software is well designed is by trying to change it. If it is hard, there are places to improve. If one thing must be changed but many class are involved, that is a sign of bad design.”
We must strive to keep our software as flexible as possible. That means, our software must be easy to change and adapt. In this agile era, that is one of the most important requirements of a software product.
Having said that, do not focus on trying to create a the most flexible software ever. It is true that our software must be flexible, but do not fall in the perfection fallacy. No matter how much effort you put on your software, there are always opportunities of improvement.
The general idea is: keep your software flexible enough, stick with clean code principles but do not paralyze due to looking for perfection.
Object Oriented Principles
“Program to an interface not only helps with replacing the implementation but we will be working with implementation classes that doesn’t even exists”.
You can easily split the work among developers, assign them responsibilities to specific ares (for instance, a developer would be focus on infrastructure side, while another developer would be focus on business domain stuff). Since, your team in working with the “program to an interface” paradigm, they can just describe the interface they may need from other services, components, etc, use a mock library to mimic the functionality required by that interface implementator and move forward on their job without the need of waiting for the implementation to be done.
“Encapsulate what varies”.
This is one of the most valuable but underestimate object oriented principle. I consider this principle as one of the foundations for great software. This use to lead to important improvements, so keep this in mind at all time.
“When you have a design problem, go through the OO principales to see opportunities of improvement.
OO principales:
Inheritance
Polymorphism
Abstraction
Encapsulation”
“When you have properties that vary between objects, use a list to encapsulate them. Hence, no further changes when adding or changing properties.”
Object Oriented Principles and Software Architecture
“Quote: The best way to get good at software design is to write software”.
Do not fall into the fallacy of that Software Architects do not code. That is a lie.
To become a great Software Architect, you must write code. It is true that a Software Architect do not write as much code as a dedicated developer, but it is important to do it as much as possible. It not only helps to get better at software design, but you will transmit the intention of the architecture you designed by leading by example with code.
“High cohesion in classes is important. Hence, every class must focus on doing one thing and one thing only.
A cohesive system doesn’t mean it is easy to change – for instance, changing how the system work may require a lot of work – but it might be easy to do relatively small changes”.
“OO principales also applies to big software projects. Remember:
Encapsulate what varies.
Program to an interface rather to an implementation.
Don’t engage in details when starting working on a system. Defer details as long as you can”.
A similar statement is on Uncle Bob’s Clean Architecture book. For instance, Rome was not built in one day, it took a long time and it was built one piece at a time. Hence, do the same when you are facing a big software project. Rather than be intimidated by the size, just apply the Object Oriented Principles at small scale and keep working up to the big picture of the your system. It is one brick at a time process. Remember that principle that you learnt back in colleague that perfectly apply to these scenarios: Divide and conquer.
“Don’t feel fear when a big problem comes out. They way to handle big problems through the architect point of view is:
- Understand what the system should do.
- Having a clear understanding of the big picture.
- Break up the system into smaller pieces that represents small problems.
- Then, apply all techniques learnt previously”.
This is close related to the previous paragraph that I wrote.
“When working on what is architecturally important, ask these questions:
Is it essential to the system?
What is that mean?
How am I gonna implement this?
Things that match above questions are architecturally important because they are high risk tasks. Focus on those high risk tasks first. The idea is to reduce risks while we are developing at the beginning.
When working on architecturally important things and make the system do what it has to do, focus on the simplest solution. Don’t go to deep with super-mega-perfect solutions that would add complexity.
Focus on things that help you reduce risk.
Another architecture technique is to look for commonalities and variabilities. Common things helps on creating abstract or base classes. While variability helps on encapsulation”.
I know that define what is software architecture or what is architecturally important is really hard to say. There are so many opinions. However, these are very good guidelines to pinpoint to what is architecturally important within the boundaries of your software system. Reading through these statements would help on defining the architectural edge of your software.
Object Oriented and SOLID principles
“OO principles in an easy:
- Encapsulate what varies.
- Program to an interface rather than an implementation.
- Classes must have only one reason to change.
- Classes must be behavior and functionality”
This is a summary of the Object Oriented Principles in simple words.
“The OCP principle is about encapsulation and abstraction. You abstract and lock the base behavior or the behavior that stay the same but open for modifications through extension which is done by encapsulating what varies.
The DRY principle is about avoiding duplication. It is not only about code but about having functionality in one place only.
Tip to make an analysis over the SRP:
Write several lines as follows:
The [class] [method] itself. For example: The bird flies itself.
If it doesn’t make sense, that method may be violating the SRP.
LSP is about base types that can perfectly substitute sub-types”.
This is a short list of some tips for the SOLID principles. In this book, they briefly touch the SOLID principles. However, any good point or topic is worth it to have in notes.
Vicluar Daniel Merchan 