views:

138

answers:

6

I'm hoping to assemble a definitive and useful study guide. Please help!

I'll start:

  • Program to an Interface not an Implementation
  • Interface Separation Principle
  • DRY Principle (Don't Repeat Yourself)
  • Law of Demeter
  • Liskov Substitution Principle
  • Dependency Injection/Inversion of Control
  • Separation of Concerns
  • Loose Coupling
  • Open Closed Principle
  • Prefer Composition over Inheritance
A: 

Interface Separation Principle

DRY Principle (Don't Repeat Yourself)

sgmeyer
DRY isn't OO-specific.
Bryan Oakley
Maybe not, but it still applies.
sgmeyer
@Bryan Oakley Pretty well everything in the original list also applies to hardware, let alone any software paradigm. The mains plug is LSP in practice.
Pete Kirkham
+1  A: 

Program to an Interface not an Implementation.

brumScouse
Unless an interface is overkill.
duffymo
Closely followed by understanding what that actually means.
Robin
+7  A: 

I'd just refer people to Uncle Bob Martin's writings and call it a day. I think context beats a simple list any day. There's lots to read there.

Know the rules; know when the rules don't apply; know when to break the rules.

Most of all, don't base all your knowledge on dogmatic lists of snippets.

duffymo
One problem I've found when learning OO design is trying to wade through the myriad of different approaches available. Starting out and getting a good grasp of what is relevant and suitable takes a bloody long time (for some of us).
brumScouse
I think learning anything well takes a long time: http://norvig.com/21-days.html
duffymo
yea, I'm just wanting a starting point for further study really, to make sure I don't miss anything.
Gary
+2  A: 

My definitive list:

  1. Find, read, and understand the original "Law of Demeter" papers.
  2. Find an Object Friendly language that you like.
  3. Determine the following: Given the intention of maintaining encapsulation, maintainability, parsimony and readability, and given the features of this language, how should I use this language?

3 is kind of a doozy, but at least you'll have a point of view from which to read other people's advice on how to use the language.

philosodad
+2  A: 
  • Program mindfully
  • Immutability is your friend
  • So are state transition diagrams
  • O/R frameworks are not all they are cracked up to be
  • Program mindfully
  • Patterns are a communication mechanism, not a mandate
Burleigh Bear
+1 just for "O/R frameworks are not all they are cracked up to be". I like all of these a lot.
duffymo
what's the value of state transition diagrams?
Gary
In my experience, if there's no non-trivial state transition diagram for a class, there are good odds the objects are really just a bit of data. (Note the states might well be private to the class).
Burleigh Bear
A: 

General Responsibility Assignment Software Patterns (or Principles)

Pangea