Subscribe to Sergio Tapia - Lost in the GC.        RSS Feed
-----

The OO Cheat Sheet - The Motherload

19 April 2011
Icon 5 Comments
Posted by Sergio Tapia Icon
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:

  • itself
  • its arguments/parameters
  • any objects it creates/instantiates
  • its direct component 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

Categories: Uncategorized

Back to Sergio Tapia - Lost in the GC. →

5 Comments On This Entry

Page 1 of 1

gregwhitworth Icon

19 April 2011 - 11:05 AM
WOW. Nice composite of links and resources.
0

Kutlar Icon

19 April 2011 - 11:56 AM
Very nice.
0

Sergio Tapia Icon

19 April 2011 - 01:09 PM
I'm glad you guys liked it. Don't forget to share this link to some of your programming buddies. :D
0

diego_pmc Icon

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

Sergio Tapia Icon

19 April 2011 - 04:31 PM
Taken from Reddit where I found this. Someone posted your exact same response.

I'm assuming you are aware of the example to which the author is referring, but in case you aren't or in case someone else is curious:

class Rectangle {
  private int _w, _h;

  // Some rectangle stuff goes here: constructors,
  // accessor functions, etc...

  int SetWidth( int w ) { _w = w; }
  int SetHeight( int h ) { _h = h; }
};

class Square : public Rectangle {
  public Square( int w ) : Rectangle( w, w ) { }
};

void Foo() {
  Square s(10);
  s.SetHeight(4); // uh oh! Now we have a square that is not square!
}


The point is that even though mathematically a square is always a rectangle, this does not imply that a Square class has an is-a relationship with a Rectangle class in an OO programming language. This problem arises because Rectangle is mutable; thus, one solution is to make Rectangles (and therefore Squares) immutable.

Another would be to not model the relationship between the Rectangle class and the Square class as an inheritance relationship.
0
Page 1 of 1

Trackbacks for this entry [ Trackback URL ]

There are no Trackbacks for this entry

6 user(s) viewing

6 Guests
0 member(s)
0 anonymous member(s)

About Me

Posted Image


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.

Categories