Software design principles are not things that change as often as technology and toolkits and it seems odd to me that its not as cool to learn about modern best practise and established principles. Most developers learn over time a "gut feel" of when code smells right or not. But when quizzed to elaborate why, struggle to do so.
SOLID is a great acronym to remember; it covers most of a developers "good sense of smell".
- S - Single Responsibility Principle - the notion that a class should have a single responsibility or strong theme. This also (at least in my opinion) covers the Separation of Concern principle. The intention is to make it clear what a class does, where to put new code, and to keep class size small and easy to comprehend. Avoid the God-Object anti-pattern; a large be-all-and-do-all large object.
- O - Open / Close Principle - Classes should be open for extension but closed for modification. The basic idea is to intentionally design how a class can be legitimately extended. Don't allow unintended or accidental modification. For example, seal your classes unless you know its legitimate to subclass; carefully control your public interfaces, don't make all classes public as a matter of course.
- L - Liskov's Substitution Principle - the notion that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program”. To a certain extent this is a given in .NET; any argument type that is not sealed, including interfaces, any subclass can be given as that argument.
- I - Interface Segregation Principle - the notion that “many client specific interfaces are better than one general purpose interface. I also interpret this to mean interface separation between classes is far better than "welding" classes together directly. But also reinforcing the SRP and SoC principles of preferring many small tightly themed interfaces.
- D - Dependency Inversion Principle - When adding related dependent objects to an object, reference them by abstractions (interface or abstract). This way any object in the system can be substituted with a test object or a future replacement.
Some behavioural practises:
DRY - Don't Repeat Yourself.
Don't write the same piece of code twice. A modification should not need to be performed in two places.
KISS YAGNI - Keep It Simple Stupid You Ain't Going to Need It. If you don't need it now, don't write it now. Most of us developers are guilty of over engineering that borders on making a class or library less usable.
Occam's Razor - Refers to a process of shaving away assumptions (and possibly risks) from two or more competing hypothesis to leave the best with the least assumptions and therefore the highest chance of success.
References:
No comments:
Post a Comment