There is definitely not much in the world that is more satisfying then coming up with completely new and original solution to a problem that has been troubling for days and night. Many programmers want to do everything them self and in their own way.
BUT..
”Doing it your way, is not always the best way”
Becuase when a big problem comes up often many people before you had the same problem alredy and also has the solution. So today we are going to discuss design principles that people have come up with over the years, and hot they can make you better programmer.
So far, we have really been concentrating on all the thing that you can do before you start coding your application. But even though you did a good job gathering requirements, analysing, writing out features, and drawing use case and other diagrams. At some point you will have to do the actual coding and that is where design principles really come handy.
A design principle is a basic tool or technique that can be applied to designing or writing code to make that code more maintainable, flexible, or extensible. Also using proven OO-design principles result in more maintainable, flexibe and extensible software.
OO-Principles
- Encapsulate what varies
- Code to an interface rather than to an implementation
- Each class in your application should have only reason to change
- Classes are about behaviour and functionality
Principle 1#: The open-closed principle (OCP)
Our first design principle is the OCP and is all about allowing change but doing it without requiring you to modify existing code. Here is how we usually define the OCP:
Closed for modification
Suppose you have a class with a particular behaviour, and you have go that behaviour coded up just the way you want it. Make sure that nobody can change your class’s code, and you have made that particular piece of behaviour closed for modification. In other words, nobody can change the behaviour because you have looked it up in a class that you are sure won’t change.
But Open for extension
But then suppose someone else comes along, and they just have to change that behaviour. You really don’t want them messing with your code, which works well in almost every situation. But you also want to make it possible for them to use your code, and extend it. So you let them subclass your class, and then they can override your method to work like they want it to. So even though they didn’t mess with your working code, you still left your class open for extension.
Principle 2#: THe don’t repeat yourself principle (DRY)
This is another principle that looks pretty simple, but turn out to be critical in writing code that’s easy to maintain and reuse.
- Lets abstract out the common code using DRY, we need to take that’s common between 2 classes and put it in a single place
- Now remoce the code from other locations
- And reference the code from step 1
Principle 3#: THe single responsibility principle (SRP)
The SRP is al about responsibility, and which objects in your system do what. You want each object that ou design to have just one responsibility to focus on- and when something about that responsibility changes, you will know exactly where to look to make changes in your code
REFERENCES
- Head first object-oriented analysis and design – chapter 8
https://www.interaction-design.org/literature/topics/design-principles
Olles blog 