Email Password Remember me?  Lost your password?

Introduction

Often, while developing software, we can get carried away and "hack" away until we get it working. However, it's sometimes handy to have a guideline.

So here's my pin up list of design principles to strive toward. These are only guidelines, and should be treated as such. They are not rules to follow...

• Hide details of the implementation: Code to contracts and not implementations. Contracts are either abstract classes or pure interfaces.
• Keep coupling to a minimum: A class can depend on native types (basic ints, bools, etc.) but should only depend on a select few peer classes. If the dependencies are high, consider this a smell and refactor to reduce the dependency. This can include creating new specialized types that are composed of the dependencies, but again this must be managed correctly.
• Maintain maximum cohesion: A class should focus on a single concept.
• Favour composition over inheritance: There’s a few different ways to get objects to collaborate – inheritance, composition, subscription through event handling.
• Adhere to the Open closed principle: An object should be open for extension (able to extend its behaviour), but closed for modification (while extending the behaviour, you should not modify its source code)
• Follow LSP where possible. Liskov Substitution principle: objects that have references to base types should be able to use derived types without knowing the difference. The basic concept behind polymorphism. TIP: design objects around behaviour and not data.
• Use Inversion of control / Dependency Inversion principle: A formal definition: High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.
• Employ the Interface Segregation principle: Objects should not be forced to depend on interfaces that they don't use.
• Consider using the Law of Demeter: Only talk to your immediate friends, so the following would be considered a violation:

  • var payment= Client.Wallet.GetMoney(10.00); 

  • This will be an interesting one to enforce if you plan on sticking to Domain driven design principles which suggest that you should get to entities through their aggregates.
• Encapsulate the variations: When encountering variants, encapsulate those bits that vary and make them first class citizens.
• Consider using Factories for object creation.

The above are principles and guidelines and violating them is okay, but only if you understand why doing so is better than following them.

fuzzelogic Solutions.com
Read the blog

You must Sign In to use this message board.

Per page 102550

FirstPrevNext

My vote of 1 Leyu 5:13 14 May '09   It's not well organized and doesn't provide a value. I'm also disappointed by the last article "Open Closed Principle" which originally was posted in www.lostechies.com. I mean if this article is considered to be a guide why not provide links to resources which might aid other developers, like the original S.O.L.I.D papers and the like. CodeProject is not keeping it's high quality articles as it used to. Sign In·View Thread·PermaLink A good reminder Phil Martin... 4:52 13 May '09   Thanks for the timely reminder Zakir. I would like to see a bit more explanation of some of the topics to make it a bit more of an in depth read. You said "The above are principles and guidelines and violating them is okay, but only if you understand why doing so is better than following them." - without the extra detail, the chances of understanding the why without finding information in other places would be quite limited. The other main thing is you try to explain the Demeter by using only a counter-example, but no explanation of how to make it satisfy the law. But aside from that, a very handy list, and a good reminder of things that are too easy to forget when deadlines are fast approaching. Sign In·View Thread·PermaLink My vote of 5 Yuriy Levytskyy 0:16 13 May '09   It's something every OO developer must keep in mind Sign In·View Thread·PermaLink My vote of 1 nextDev.net 23:25 12 May '09   20 lines to resume SOLID principles. Useless and already done on 10'000 other articles. Sign In·View Thread·PermaLink 5.00/5 Re: My vote of 1 Phil Martin... 4:49 13 May '09   nextDev.net wrote: Useless and already done on 10'000 other articles. On CodeProject? Where? I think I'd like to see a bit more exposition, but overall it was a very handy reminder of things that are easy to forget when deadlines are looming. Sign In·View Thread·PermaLink Keep coupling to a minimum LotharLanger 12:02 12 May '09   Hi Zakir, i wonder what's your judgement about data binding mechanisms which are promoted in .NET - i think - from the beginnings. Even without using them explicitly there is a lot of coupling going on "under the hood" - for the good in most cases and sometimes creating surprises. For example trying to explicitly set the 'Visible' property of a control contained in a form to 'true' within the constructor of the form does not give you the result of the property being 'true' before the form is shown. So in my understanding there must be a coupling of the 'Visible' property going on that is not really obvious although it makes sense - kind of... You should sell it as the ten commandments of OO which sounds great ... in a christian/jewish world at least. They are meant to strive for but almost never achievable. Lothar Sign In·View Thread·PermaLink Re: Keep coupling to a minimum Zakir Hoosen 23:50 12 May '09   Hi ! Using one of the UI patterns (mvc, mvp, mv What-ever), you keep binding to a minimum. Sign In·View Thread·PermaLink

Last Visit: 4:48 21 Nov '09     Last Update: 4:48 21 Nov '09 1