This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
There are many! Robert Martin has put a nice collection of 11 together. THS BLOG references a set of articles on the 11, and the "PPP" book he mentions is a must read if you want to explore this stuff thoroughly.
I collected a few articles and such HERE that you're welcome to read and comment on. Look for light-hearted ideas like "Don't Confuse Your Dog".
We love this stuff. Try a few of these articles on for size and let us know what you think.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Here's a list of articles on various design principles. Start with the article called Principles and Patterns and work your way through from there.
I cannot express this enough--these are the best articles written by authorities on the general principles of OO design and analysis that I've ever seen.
Joined: Jan 29, 2003
I recommend Uncle Bob's work frequently, but want to throw out one warning: Some of the C++ articles solve problems Java doesn't have. If you think you may have stumbled into one of those, throw out a lifeline here and we can figure it out together. Cheers!
Here a some OO principles you can read in the fabulous O'Reilly book "Head First in Design Patterns" :
1) Encapsulate what varies 2) Favor composition over inheritance 3) program to interfaces not implementations 4) Strive for loosely coupled designs between objets that interact 5) Classes should be open for extension but closed for modification (Bertrand Meyer) 6) Depend on abstractions Do not depend on concrete classes 7) Only talk to your friends 8) Don't call us, we' call you (use callback functions) 9) A class should have only one reason to change
We don't have many rules here, but one thing we like is to speak to real humans (in contrast to feed bags ). Therefore we have a naming policy that requires every member to use a real sounding name as his display name. Please adjust your display name accordingly. Thanks! [ August 28, 2005: Message edited by: Ilja Preuss ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jul 11, 2001
Originally posted by FUTTERSACK MICHEL: 1) Encapsulate what varies 9) A class should have only one reason to change
The Single Responsibility Principle.
3) program to interfaces not implementations 4) Strive for loosely coupled designs between objets that interact 6) Depend on abstractions Do not depend on concrete classes
Dependency Inversion Principle
5) Classes should be open for extension but closed for modification (Bertrand Meyer)
Open Closed Principle, obviously.
7) Only talk to your friends
Law of Demeter
2) Favor composition over inheritance
I don't think this is a good principle. It's a good heuristic for beginners who tend to overuse inheritance. Experienced developers don't favor composition over inheritance, they try to find a good balance between them.
What seems to be missing are
Single Choice Principle, and Liskov's Substitution Principle