Sunday, April 20, 2014

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.

Read on

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.

http://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.

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

http://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.

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


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.


interface JumpringService {
    public void jump();
}

public class JumpingServiceImpl implements JumpingService {

    @Inject
    private Jumpable jumbable;

    @override
    public void jump() {
        jumpable.jump();
    }
}

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

Sunday, April 6, 2014

map() function in JavaScript, Scala etc

These are absolutely awesome functions. They allow you to apply a function on every element of an array and return a new array with the result of the function.

In theory these are called higher-order functions, i.e they can take one or more function as an argument.

Consider the following JavaScript function:

var array = [1,2,3,4,5];
var twoTimesArray = array.map(function(n) {return n*2;});
console.log(twoTimesArray);

output: [2, 4, 6, 8, 10]

So that just multiplies every element of array by 2 and returns the resulting array.

Without map functions you would have done something like this:

var array = [1,2,3,4,5];
var twoTimesArray = [];
for(var i = 0; i < array.length; i++ ) {
    twoTimesArray[i] = array[i] * 2;
}
console.log(twoTimesArray);

Clearly, that is a lot of code compared to the previous one.

And, if you use Scala, code becomes much more concise.

scala> val l = List(1,2,3,4,5)
l: List[Int] = List(1, 2, 3, 4, 5)

scala> l.map(x => x*2)



Imagine doing the same thing in Java. First we will look at Java 6

List<Integer> array = Arrays.asList(1,2,3,4,5);
List<Integer> twoTimesArray = new ArrayList<Integer>();
for(Integer i: array) {
    twoTimesArray.add(i*2);
}



And in Java 8:

List<Integer> array = Arrays.asList(1,2,3,4,5);
List<Integer> twoTimesArray = new ArrayList<Integer>();
array.stream().forEach((string) -> {
    twoTimesArray.add(string*2);
});



The difference between for-each loop and using stream api (collection.stream()) in Java 8 is that we can easily implement parallelism when using the stream api with collection.parallelStream(). Whereas, in for-each loop you will have to handle threads on your own.

Programming becomes fun when we add bit of functional style into OO languages.

Related Posts Plugin for WordPress, Blogger...