CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Darrell Norton's Blog [MVP]

Fill in description here...

5 Principles to code by

According to Agile Software Development: Principles, Patterns and Practices, there are five object-oriented principles that help avoid rotting software:

  1. Single-Responsibility Principle.  A class should have only one reason to change.  Originally called cohesion, it was defined as the functional relatedness of the methods within a class.  However, this is hard to apply.  By shifting the definition of cohesion to the relatedness of reasons for change, we get the much more pragmatic and applicable “a class should have only one reason to change.”  Now you can easily look at a class and see whether it violates this principle or not.
  2. Open-Closed Principle.  Software entities should be open for extension, but closed for modification.  What this means is that changes of a certain kind, the dimension in which the design is closed, do not require changes to existing code, only additions of new code.  For example, if adding a new way to calculate taxes to a point-of-sale system, existing code should not need to be modified although new classes (code) may be added.
  3. Liskov Substitution Principle.  Subtypes must be substitutable for their base types.  In Design by Contract terms, subtypes can only weaken the original precondition and strengthen the original postcondition.  In other words, the subtype must accept everything that the base type accepts (or more), and can only return the same range of values that the base type returned (or less).
  4. Dependency-Inversion Principle.  Abstractions should not depend on details.  Details should depend on abstractions.  In most traditional n-tier models, the higher-level layers depend on the layer beneath it.  What happens is that the highest-level layers transitively depend on all the layers beneath them.  Instead of that, the DIP recommends inverting this dependency through an intermediate interface, thus breaking the transitive dependencies throughout the layers.
  5. Interface Segregation Principle.  Clients should not be forced to depend on methods that they do not use.  Fat interfaces subject clients to changes in that interface to accommodate other clients’ needs.


Comments

Darrell said:

I liked the principles, but had some other issues with the book. Overall it was still good. I'll post the review tomorrow!
# February 5, 2004 8:04 AM

CfAtlanta said:

I read these exact same points in a well-articulated series of articles by Robert C. Martin in 1995 (8 or 9 years ago). In fact, he made exactly these points and no additional points as far as I can remember. Did you realize that your post was so strikingly similar?
# February 5, 2004 10:11 AM

Darrell said:

No, I did not realize that. I was just summarizing section 2 of Robert Martin's book "Agile Software Development: Principles, Patterns, and Practices".
# February 5, 2004 1:56 PM

Steve said:

I'll look forward to the review. I read it a while ago before I had really formed a lot of my opinions / thoughts on Agile. Be interested to check out your review to hear the things you did and didn't like.
# February 5, 2004 3:41 PM

Fletcher Dunton said:

Darril:

That sounds interesting. What langauge are the examples programmed in?
# February 6, 2004 12:44 AM

Darrell said:

The examples are C++ and Java.
# February 6, 2004 1:27 AM

Udi Dahan - The Software Simplist said:

Anyone hear about the Law of Demeter ?

Anyone consider its effects on the O/R mapping stuff ? Like that Customer.Orders[0].Product.Name is not good ?
# February 11, 2004 12:40 PM

Darrell said:

Udi - I have! I was just covering the basics in Robert Martin's book, not trying to be comprehensive. Sorry! :)

As for its effects on O/R mapping, I have not considered it much. As much as I've debated with the O/R mapper vendors, I would use one if I worked on a project with a complex domain. However, I think the "RecordSet" and "Table Gateway" patterns (from Martin Fowler's PofEAA book), as implemented in .NET via the DataSet, work for a larger range of domain complexity than most believe.

BTW, thanks for stopping by. I love your blog too.
Darrell
# February 12, 2004 1:20 AM

Udi Dahan - The Software Simplist said:

Darrell,

Thanks for the warm compliments !

The main problem that I have with the DataSet is that 9 times out of 10 it will strongly bind your presentation to the database schema. This is problematic especially when it comes time to denormalize the DB a bit to improve performance.

Anyway, the way to somehow get around the law of demeter in the case of O/R mapping, that I've found, is auto-generating the majority of the code. Obviously, this doesn't alleviate the REAL issues, but somehow makes them hurt less =)
# February 24, 2004 8:06 AM

Darrell said:

Udi - yeah, it does bind the app to the database schema. My solution so far has been to "fix fast" rather than decouple the code.

And I strongly believe in code generation. Although the XPers say it is a code smell, it is very straightforward, understandable, and easily debuggable.
# February 24, 2004 8:26 AM

Udi Dahan - The Software Simplist said:

I disagree that code generation = code smell by XP. It's a way of maintaining the DRY ( don't repeat yourself ) principle that is so central to refactoring. Without refactoring, where's XP ?
# February 24, 2004 10:00 AM

Darrell said:

Probably nowhere. :)
# February 24, 2004 1:05 PM

james fowler said:

no comment
# September 27, 2004 12:19 AM
Check out Devlicio.us!

Our Sponsors

Free Tech Publications