Full credit and source goes to Mmiika.
During my usual morning stroll on some programming forums, someone shared this fantastic link:
http://mmiika.wordpr...ign-principles/
It's a compilation of good articles encompassing a wide variety of different OO rules and paradigms. Check it out. :)
S.O.L.I.D. Class Design Principles
Single Responsibility Principle (SRP)
A class should have only one reason to change. For example, if a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.
Links:
Open/Closed Principle (OCP)
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types. If class A inherits from class B, then wherever you can use A you should be able to use B. E.g. remember that square is not necessarily a rectangle!
When extending: Preconditions cannot be straightened, Postconditions cannot be loosened, visible Invariants cannot be changed (?).
Invariants: users depend on this both before and after sending a message. Use a proper set-based inheritance relationship. Not following set semantics is very risky.
Subsumption Rule: A reference to a subtype can be used in any context where a reference to a super type is expected. This principle extremely limits what SHOULD be done with the pure extension (inheritance) mechanism. Do not follow at your own risk.
Interface Segregation Principle (ISP)
The dependency of one class to another one should depend on the smallest possible interface.
Dependency Inversion Principle (DIP)
Depend upon abstractions (interfaces), not upon concrete classes.
Other Important Ones
Law of Demeter
aka Principle of Least Knowledge: Only talk to your friends
Any method M of an object O may only invoke the methods of the following kinds of objects:
See
Hollywood Principle
Don’t call us, we’ll call you.
Don’t Repeat Yourself (DRY)
Remove duplication.
Program to an interface, not an implementation
Just another way to say dependency injection, or IoC.
You Ain’t Gonna Need It (YAGNI)
Do not add code that you “think will be used later”. Add code only at “Last Responsible Moment”
Keep It Simple, Stupid (KISS)
What is the simplest thing that could possibly work?
Miscellaneous
Encapsulation and Information Hiding
http://en.wikipedia....mputer_science) http://en.wikipedia....ormation_hiding
Separation of Concerns (SoC)
http://ctrl-shift-b....f-concerns.html
High Cohesion
http://en.wikipedia....mputer_science)
Low/Loose coupling
Head First Design patterns page 53
http://en.wikipedia....mputer_science)
Convention over Configuration (CoC)
http://en.wikipedia....r_Configuration
Command-query separation (CQS)
http://en.wikipedia....uery_separation
http://martinfowler....Separation.html
[edit] Design by Contract (DbC)
http://en.wikipedia....ign_by_contract
http://c2.com/cgi/wi...esignByContract
Dependency Injection (DI)
Inversion of Control (IoC)
Avoid Fragile Baseclass
http://en.wikipedia....gile_base_class
Has-a Is-a
http://en.wikipedia.org/wiki/Has-a http://en.wikipedia.org/wiki/Is-a http://en.wikipedia....ect_composition
What is Identity
http://en.wikipedia....ed_programming)
Interchangeability
http://en.wikipedia....mputer_science)
Option-operand separation
http://en.wikipedia....rand_separation
Intention Revealing Names
http://c2.com/cgi/wi...nRevealingNames
http://www.hanselman...ItsTheTits.aspx
Zero Friction Development
http://www.google.co...ion+development
Encapsulate Variation
Separate what varies from what stays the same. Also known as Serenity Principle.
http://blogs.msdn.co...hat-varies.aspx
Head First Design patterns page 9, 111
Composition over inheritance
Head First Design patterns page 23, 243, 397
Common Closure Principle
Classes that change together must be placed in the same package.
http://c2.com/cgi/wi...losurePrinciple
During my usual morning stroll on some programming forums, someone shared this fantastic link:
http://mmiika.wordpr...ign-principles/
It's a compilation of good articles encompassing a wide variety of different OO rules and paradigms. Check it out. :)
S.O.L.I.D. Class Design Principles
Single Responsibility Principle (SRP)
A class should have only one reason to change. For example, if a change to the business rules causes a class to change, then a change to the database schema, GUI, report format, or any other segment of the system should not force that class to change.
Links:
- http://davidhayden.c...05/29/1066.aspx
- http://c2.com/cgi/wi...bilityPrinciple
- Head First Design patterns page 185, 336, 339, 367
- http://msdn.microsof...e/cc546578.aspx
- http://codebetter.co...gimme-an-s.aspx
Open/Closed Principle (OCP)
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
- http://davidhayden.c...06/04/1096.aspx
- http://en.wikipedia....losed_principle
- Head First Design patterns page 86-87, 407
- http://c2.com/cgi/wi...ClosedPrinciple
- http://codebetter.co...uot-o-quot.aspx
Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types. If class A inherits from class B, then wherever you can use A you should be able to use B. E.g. remember that square is not necessarily a rectangle!
When extending: Preconditions cannot be straightened, Postconditions cannot be loosened, visible Invariants cannot be changed (?).
Invariants: users depend on this both before and after sending a message. Use a proper set-based inheritance relationship. Not following set semantics is very risky.
Subsumption Rule: A reference to a subtype can be used in any context where a reference to a super type is expected. This principle extremely limits what SHOULD be done with the pure extension (inheritance) mechanism. Do not follow at your own risk.
- http://davidhayden.c...06/10/1226.aspx
- Agile Principles and Patterns page ?
- http://c2.com/cgi/wi...tutionPrinciple
- http://en.wikipedia....ution_principle
- http://javaboutique....torials/JavaOO/
- http://codebetter.co...gimme-an-l.aspx
Interface Segregation Principle (ISP)
The dependency of one class to another one should depend on the smallest possible interface.
- http://davidhayden.c...06/15/1482.aspx
- http://c2.com/cgi/wi...gationPrinciple
- http://www.google.co...ation+principle
- http://doodleproject...nPrinciple.html
Dependency Inversion Principle (DIP)
Depend upon abstractions (interfaces), not upon concrete classes.
- http://davidhayden.c...06/10/1261.aspx
- http://en.wikipedia....rsion_principle
- Head First Design patterns page 139-143
- http://c2.com/cgi/wi...ersionPrinciple
Other Important Ones
Law of Demeter
aka Principle of Least Knowledge: Only talk to your friends
Any method M of an object O may only invoke the methods of the following kinds of objects:
- itself
- its arguments/parameters
- any objects it creates/instantiates
- its direct component objects
See
- http://en.wikipedia....Least_Knowledge
- http://ctrl-shift-b....of-demeter.html
- Head First Design patterns page 265
Hollywood Principle
Don’t call us, we’ll call you.
- http://en.wikipedia....ywood_Principle
- Head First Design patterns page 296
Don’t Repeat Yourself (DRY)
Remove duplication.
- Pragmatic Programmer page 27
- http://en.wikipedia....repeat_yourself
- http://c2.com/cgi/wi...tRepeatYourself
Program to an interface, not an implementation
Just another way to say dependency injection, or IoC.
- Head First Design patterns page 11, 110-111, 243, 335
- http://www.artima.co...principles.html
You Ain’t Gonna Need It (YAGNI)
Do not add code that you “think will be used later”. Add code only at “Last Responsible Moment”
Keep It Simple, Stupid (KISS)
What is the simplest thing that could possibly work?
Miscellaneous
Encapsulation and Information Hiding
http://en.wikipedia....mputer_science) http://en.wikipedia....ormation_hiding
Separation of Concerns (SoC)
http://ctrl-shift-b....f-concerns.html
High Cohesion
http://en.wikipedia....mputer_science)
Low/Loose coupling
Head First Design patterns page 53
http://en.wikipedia....mputer_science)
Convention over Configuration (CoC)
http://en.wikipedia....r_Configuration
Command-query separation (CQS)
http://en.wikipedia....uery_separation
http://martinfowler....Separation.html
[edit] Design by Contract (DbC)
http://en.wikipedia....ign_by_contract
http://c2.com/cgi/wi...esignByContract
Dependency Injection (DI)
Inversion of Control (IoC)
Avoid Fragile Baseclass
http://en.wikipedia....gile_base_class
Has-a Is-a
http://en.wikipedia.org/wiki/Has-a http://en.wikipedia.org/wiki/Is-a http://en.wikipedia....ect_composition
What is Identity
http://en.wikipedia....ed_programming)
Interchangeability
http://en.wikipedia....mputer_science)
Option-operand separation
http://en.wikipedia....rand_separation
Intention Revealing Names
http://c2.com/cgi/wi...nRevealingNames
http://www.hanselman...ItsTheTits.aspx
Zero Friction Development
http://www.google.co...ion+development
Encapsulate Variation
Separate what varies from what stays the same. Also known as Serenity Principle.
http://blogs.msdn.co...hat-varies.aspx
Head First Design patterns page 9, 111
Composition over inheritance
Head First Design patterns page 23, 243, 397
Common Closure Principle
Classes that change together must be placed in the same package.
http://c2.com/cgi/wi...losurePrinciple
5 Comments On This Entry
Page 1 of 1

diego_pmc
19 April 2011 - 02:07 PM
Actually, a square is always a rectangle. Maybe you meant it the other away around.

Page 1 of 1
Trackbacks for this entry [ Trackback URL ]
0 user(s) viewing
0 Guests
0 member(s)
0 anonymous member(s)
0 member(s)
0 anonymous member(s)
About Me

Bienvenidos! I'm a USA ex-pat living in Bolivia for the past 10 years. Web development is my forte with a heavy lean for usability and optimization. I'm fluent in both English and Spanish. I guest write for the popular Python website Python Central. Visit my website.
My Blog Links
Recent Entries
-
-
-
DevOps for dummies - VPS Configuration from scratch - Rails, Nginx, PostgreSQL.
on May 22 2013 02:36 PM
-
-
Recent Comments
-
Sergio Tapia
on May 24 2013 12:33 PM
DevOps for dummies - VPS Configuration from scratch - Rails, Nginx, PostgreSQL.
-
Lemur
on May 23 2013 04:53 PM
DevOps for dummies - VPS Configuration from scratch - Rails, Nginx, PostgreSQL.
-
laytonsdad
on Apr 30 2013 11:30 AM
Dream.In.Code Badge Generator! Share your flair on your site or blog.
-
-
Jstall
on Nov 04 2012 09:18 AM
The Pragmatic Bookshelf mega blowout sale - 40% off select Ruby on Rails books.