cohesion

Encapsulate what varies.

Favor composition over inheritance.

Program to interfaces, not implementations.

Strive for loosely couple designs between objects that interact.

Classes should be open for extension but closed for modification.

Depend on abstractions. Do not depend on concrete classes.

Only talk to your friends.

Don’t call us, we’ll call you.

A class should only have one reason to change.

Continuing from the basics of OO, we now move on to its principles. The list above is taken from the wonderful book Head First Design Patterns and it enumerates some of the most important principles in OO. I’ll explain briefly what each principle means below the cut.

Continue reading “Object Oriented Principles”

sample OO class diagram

As you may already have read in my previous posts, one of my biggest pet peeves in the IT industry today is that a lot of people are using Object Oriented Programming (OOP) without even understanding the basic concepts behind it. They’re not using OOP for its benefits over the previous generation’s simple structured procedural programming; they’re using it simply because the language they’re coding in is OOP (e.g. Java, .NET).

To put it bluntly, it’s like writing spaghetti code in a structured programming language.

With this being my perspective about the local status quo, I feel that I have to post about the basics of OOP before moving on to the other fun stuff related to programming.

Continue reading “Object Oriented Programming Basics”