10 Commandments of Object-Oriented Design

no, this isn’t the word of god.

it isn’t the word of jon skeet/martin fowler/jeff atwood/joel spolsky (replace it with your favorite technologist) either.

we were reviewing some code and started discussing why we cut corners and don’t follow common sense principles. even though everyone has their own nuggets of wisdom regarding how classes should be structured based on the functional context but there are still some fundamental principles which one could keep in mind while designing classes.

i. follow the single responsibility principle

every class should have one and only one axis of change. it is not only true for classes but methods as well. haven’t you seen those long-winded-all-encompassing gobbledygook classes or methods which when spread out on a piece of paper turn out to be half the length of the great wall of china? well, the idea is not to do that.

the idea is that every class or a method has one reason to exist. if the class is called loan then it shouldn’t handle bank account related details. if the method is called getloandetails then it should be responsible for getting loan details only!

ii. follow the open closed principle

it enables you to think about how would your system adapt to the future changes. it states that a system should allow the new functionality to be added with minimal changes to the existing code. thus, the design should be open for extension, but closed for modification. in our case, the developer had done something like this:

public class personalloan
{
    public void terminate()
    {
        //execute termination related rules here and terminate a personal loan
    }
}

public class autoloan
{
    public void terminate()
    {
        //execute termination related rules here and terminate a personal loan
    }
}

public class loanprocessor
{
    public void processearlytermination(object loan)
    {
        if ( loan is personalloan )
        {
            //personal loan processing
        }
        else if (loan is autoloan)
        {
            //auto loan processing
        }
    }
}

the problem with loanprocessor is that it would have to change the moment there is a new type of loan, for example, homeloan. the preferable to structure this would have been:

public abstract class loan
{
    public abstract void terminate();
}

public class personalloan: loan
{
    public override void terminate()
    {
        //execute termination related rules here and terminate a personal loan
    }
}

public class autoloan: loan
{
    public override void terminate()
    {
        //execute termination related rules here and terminate a personal loan
    }
}

public class loanprocessor
{
    public void processearlytermination(loan loan)
    {
        loan.terminate();
    }
}

this way, the loanprocessor would be unaffected if a new type of loan was added.

iii. try to use composition over inheritance

if not followed properly, this could lead to brittle class hierarchies. the principle is really straightforward and one needs to ask — if i was to look at the child class, would i able to say “child is a type of parent?” or, would it sound more like “child is somewhat a type of parent?”

always use inheritance for the first one, as it would enable to use the child wherever parent was expected. this would also enable you to honor yet another design principle called the liskov substitution principle . and use composition whenever you want to partially use the functionality of a class.

iv. encapsulate data and behavior

most of the developers only do data encapsulation and forget to encapsulate the code that varies based on the context. it’s not only important to hide the private data of your class, but create well-encapsulated methods that act on the private data.

v. follow loose coupling among classes

this goes hand-in-hand with encapsulating the right behavior. one could only create loosely coupled classes if the behavior was well encapsulated within classes. one could achieve loose coupling by relying on abstractions rather than implementations.

vi. make your classes highly cohesive

it shouldn’t be that the data and behavior are spread out among various classes. one should strive to make classes that don’t leak/break their implementation details to other classes. it means not allowing the classes to have code, which extends beyond its purpose of existence. of course, there are design paradigms like cqrs which would want you to segregate certain types of behavior in different classes but they are only used for distributed systems.

vii. code to interfaces than implementations

this promotes loose coupling and enables one to change the underlying implementations or introduce new ones without impacting the classes using them.

viii. stay dry (don’t repeat yourself)

yet another design principle that states not to repeat the same code at two different places. thus, a specific functionality or algorithm should be implemented at one place and one place only. it leads to maintenance issues if the implementation is duplicated. the reverse of this is called wet – write everything twice

ix. principle of least knowledge i.e. law of demeter.

this states that an object shouldn’t know the internal details of the objects it collaborates with. it is famously called — talk to friends and not friends of friends. a class should only be able to invoke public data members of the class it is collaborating with. it shouldn’t be allowed to access behavior or data for the classes that are composed by those data members. it leads to tight coupling if not followed properly, thus creating systems which are harder to change.

x. follow the hollywood principle: don’t call us, we'll call you

this enables to break the mold of conditional flow logic and allowing code to be executed based on events. this is either done via event callbacks or injecting the implementations of an interface. dependency injection , inversion of control , or observer design pattern are all good examples of this principle. this principle promotes loose coupling among classes and makes the implementation very maintainable.