Can lambda expressions be the alternative of polymorphism?

Question

I am learning lambda expressions and functional interfaces. We can directly write an implementation of the interface by the lambda expression. So I think, it could be the alternative for polymorphism.

I have some code using polymorphism,

interface Drawable {
    public void draw();
}


class Shape {

    protected String name;

    public Shape(String name) {
        this.name = name;
    }
}

class Rectangle extends Shape implements Drawable  {

    public Rectangle(String name) {
        super(name);
    }

    @Override
    public void draw() {
        System.out.println("I am "+this.name);
        System.out.println("Drawing rectangle with 2 equal sides.");
    }
}

class Square extends Shape implements Drawable {

    public Square(String name) {
        super(name);
    }

    @Override
    public void draw() {
        System.out.println("I am "+this.name);
        System.out.println("Drawing square with 4 equal sides.");
    }
}


public class DrawShape {

    public static void main(String ar[]) {

        Drawable rectangle = new Rectangle("Rectangle");
        rectangle.draw();

        Drawable square = new Square("Square");
        square.draw();

    }
}

I have written above code using lambda expressions and functional interface,

@FunctionalInterface
interface Drawable {
    public void draw();
}


class Shape {
    private String name;
    public Shape(String name) {
        this.name = name;
    }

    public void draw(Drawable d1) {
        System.out.println("I am "+this.name);
        d1.draw();
    }
}



public class DrawShape {

    public static void main(String[] args) {
        Shape s1 = new Shape("Rectangle");
        Drawable rectangle = () -> System.out.println("Drawing rectangle with 2 equal sides.");
        s1.draw(rectangle);

        Shape s2 = new Shape("Square");
        Drawable sqaure = () -> System.out.println("Drawing square with 4 equal sides.");
        s2.draw(sqaure);
    }

}

Which is the better approach? What about other aspects like code reusability, code maintenance and modification, coupling and cohesion etc for lambda?

Answer 1

I would argue that lambda expressions allow developers to write fully polymorphic types, the way full class implementations do.

Polymorphism is often seen in two ways:

Drawable drawable = new Rectangle("name");
drawable.draw();
Shape shape = (Shape) drawable; //same object, multiple types.

And:

Drawable drawable2 = new Rectangle("name");
drawable2.draw(); //Rectangle.draw() implementation invoked
drawable2 = new Square("name");
drawable2.draw(); //Square.draw() implementation

Neither of these two is perfectly allowed for by lambda expressions:

1. Lambda expressions will only be used to implement functional interfaces. This is the first major limitation.

2. Although one can do this:

   Drawable drawable = () -> System.out.println("drawing rectangle");
   drawable = () -> System.out.println("drawing square");
   

   This is not strictly the same thing as the second code snippet above (in a more complex example, one would be able to provide a basic implementation in Shape, and have it overridden in Rectangle and Square; and that wouldn't be possible with lambdas). Also, one would be correct to argue that the two assignments above use different source code.

3. One can't just "cast" types as with classes:

   Drawable drawable3 = () -> System.out.println("Drawing something");
   Shape shape3 = (Shape) drawable3; //Class cast exception.
   

In other words, lambda expressions are a good fit for functional programming coding, not a substitute for good Object-Oriented design.

Answer 2

I am agree with @yelliver & @cricket_007, what you did is just using anonymous class instead of subclass.

You wrote

Shape s1 = new Shape("Rectangle");
Drawable rectangle = () -> System.out.println("Drawing rectangle with 2 equal sides.");
s1.draw(rectangle);

It is same like

Shape s1 = new Shape("Rectangle");
Drawable rectangle = new Drawable() {
    @Override
    public void draw() {
        System.out.println("Drawing rectangle with 2 equal sides.");
    }
};
s1.draw(rectangle);

So the two examples you created are not same. Your first example uses a subclass whereas the second one is using an anonymous class.

So I think, it could be the alternative for polymorphism

Clearly it is not an alternative, it is just another way to implement.

Benefits of lambda expression in Java.

1. Fewer Lines of Code

In above example you can see anonymous class is changed by just ->.

2. Sequential and Parallel Execution Support by passing behavior in methods

You can iterate any collection by just using foreach(). (example)

list.forEach(item->System.out.println(item));

3. Lambda Expression and Objects

In Java, any lambda expression is an object as is an instance of a functional interface. We can assign a lambda expression to any variable and pass it like any other object (example) . like

list.sort((Developer o1, Developer o2)->o1.getAge()-o2.getAge());

Answer 3

lambda-expressions in Java 8 represents the instance of a functional interface (interface with only 1 method). In your 2nd approach, you just create a anonymous class. It does not make sense if you want to re-use code. For more information, you can refer to why/when to use anonymous class: How are Anonymous (inner) classes used in Java?

public static void main(String[] args) {
    Shape s1 = new Shape("Rectangle");
    Drawable rectangle = new Drawable() {
        @Override
        public void draw() {
            System.out.println("Drawing rectangle with 2 equal sides.");
        }
    };
    s1.draw(rectangle);

    Shape s2 = new Shape("Square");
    Drawable sqaure = new Drawable() {
        @Override
        public void draw() {
            System.out.println("Drawing square with 4 equal sides.");
        }
    };
    s2.draw(sqaure);
}

Answer 4

Both the imperative style and the functional style has its own pros and cons. in this specific case using the functional style approach is better simply because you don't need to create a class for every case where you needed to encapsulate a single piece of functionality.

As one can quickly notice creating a class for every case where you needed to encapsulate a single piece of functionality leads to unnecessary boilerplate code

With the imperative approach, one could write code and make it up as you go. one may even end up writing classes upon classes without fully understanding what the implementation will be which may result in a large and unsustainable code base.

On the other hand, the functional approach forces one to better understand their implementation before & while we're coding.

That said, it’s very important to understand that functional programming itself should not be thought of as a "replacement" for object-oriented programming.

You may actually find your self-going back to the OOP approach when the business logic gets more complex.

Answer 5

In my opinion, the second approach is more flexible as the logic of drawing is separated from the shapes themselves.

So, let us concentrate on the second approach. The @FunctionalInterface is optional as any given interface is considered a functional interface if it has only one single abstract method (also called SAM interfaces).

As I said, the second approach is more favorable as any given approach promoting code separation leads to a reusable, maintainable and loosely-coupled solution.

Your second solution is more inclined to a behavioral-passing approach. One way of implementing this approach (specially if your behavior can be represented as a tiny single expression) is by lambda expressions.

So, for example, given a rectangle shape, drawn depending on a given context, you can create two separate lambda expressions (behaviors) and pass them to the drawing logic when the context changes.

    Shape s1 = new Shape("Rectangle");

    s1.draw(() -> System.out.println("Drawing rectangle in context 1."));

    // context changes

    s1.draw(() -> System.out.println("Drawing rectangle in context 2."));

You can not try the code snippet above in your first example, because the drawing logic is hardcoded in the shapes themselves.

To sum up, always favor decoupled solutions, and if your behavior to be decoupled can be represented as tiny single expressions, the best way to approach it is by using lambda expressions or if your behavior is already implemented elsewhere, you can take advantage of method references.