SOLID design principle

When it comes to OO designing, it is a good idea to have a strategy to follow. A strategy allows you to think and organize ideas in a particular fashion that is comfortable to you. I’ve found SOLID principle easy enough for beginners and experts to understand and practice. This was originally put forward by Rober C. Martin , who is a pioneer in agile software development and extreme programming.

Checkout Cleancoders to know more.

Chances are, you may be already using SOLID principle, just without giving it a name.

tl;dr

S - Single Responsibility Principle (SRP)

O - Open/Closed Principle (OCP)

L - Liskov Substitution Principle (LSP)

I - Interface Segregation Principle (ISP)

D - Dependency Inversion Principle (DIP)

Thats right, SOLID stands for a bunch of other acronyms.

S - Single Responsibility Principle (SRP)

The single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.

Fairly simple. A Student class should manipulate Student properties and not the the properties of School. Specification of the class remains mostly untouched unless there is a big change in requirement of your software.

It is good to keep in mind that, there can be some exceptions to this. For example a utility class may provide methods for managing both Students and Schools.

O - Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification. The idea is that once a class is implemented completely, it should not be modified for including new features. Bugs and error correction must be done as and when required. Adding a new feature will require new specification and release of newer version. https://en.wikipedia.org/wiki/Open/closed_principle

L - Liskov Substitution Principle (LSP)

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. See also design by contract . That right there is the basic use of Dependency Injection, right? You define a parent interface and replace them by concrete implementation which are derivatives.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

class Animal {
    public void makeNoise() {
        System.out.println("noise");
    }
}
class Dog extends Animal {
    @override
    public void makeNoise() {
        bark();
    }
    public void bark() {
        System.out.println("bow bow bow");
    }
}
Dog dog = new Animal();
dog.makeNoise();
@Inject
Animal animal; // can be replaced by Dog

https://en.wikipedia.org/wiki/Liskov_substitution_principle

I - Interface Segregation Principle (ISP)

Many client-specific interfaces are better than one general-purpose interface. Interfaces provide abstraction no implementation. When developing client interfaces, it should be kept at minimum and should only expose those methods which are essential for that client.

https://en.wikipedia.org/wiki/Interface_segregation_principle

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

interface Jumbable {
    void jump();
}
interface Climbable {
    void climb();
}
class Dog extends Animal implements Jumbable {
    @override
    void jump() {
        //jump
    }
}
class Monkey extends Animal implements Jumbable, Climbable {
    @override
    void jump() {
    }
    @override
    void climb() {
    }
}

##D - Dependency Inversion Principle (DIP)

One should “Depend upon Abstractions. Do not depend upon concretions.” Dependency injection is one method of following this principle.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

interface JumpringService {
    public void jump();
}
public class JumpingServiceImpl implements JumpingService {
    @Inject
    private Jumpable jumbable;
    @override
    public void jump() {
        jumpable.jump();
    }
}

https://en.wikipedia.org/wiki/Dependency_inversion_principle