Scala as "Better Java" from object-oriented viewpoint

Scala as "Better Java"
from object-oriented viewpoint

Shinya Mochizuki
lepidum Co Ltd.
02 March 2013

https://lepidum.co.jp/ Copyright © 2004-2013 Lepidum Co. Ltd. All rights reserved.

About this talk

Main Topic

Object-Oriented Programming

No Functional Programming!


Difficulty

Easy! But...

Difficulty != Importance


What is Scala?

FP + Traditional OO like Java

FP + Improved OO compared to Java


What is a pretty program?

Structured by reusable components.

Components is expressed as

Function, Class, Module, etc.

In OO, a component is basically class.

More precisely, class instances.


What is a component?

Structured by components.

Mostly smaller.

Component composition is expressed as

“composition” != Composite Pattern (GoF)

Function composition, Inheritance, Include, etc.

In OO, composition is inheritance.


Implmentation inheritance

Component composition by OO feature.
public class Logger {...}
public class Counter extends Logger {...}
public class Receptionist extends Counter {...}

Problems

Unintended polymorphism.

Counter is not a Logger! Neither is Receptionist.

Publishing implementation details.

Receptionist inherits Counter and Logger public methods.


Lack of language feature

No multiple composition in Java

e.g. Multiple inheritance like C++


Composition direction

Single inheritance

Only vertically.

Multiple inheritance

Vertically and horizontally.

But has some problems.

e.g. conflict method resolution


In Scala?

Scala's feature: Traits and mixin

Traits are like Java's interfaces, but

can contain arbitrary method implementations.

Class/Trait can inherit from arbitrary trait.

Inheriting traits is called “mixin”.

Trait as component

can be composed horizontally.


In Scala: Implmentation mixin

Using trait instead of class.
trait Logger {...}
trait Counter {...}
class Receptionist extends Logger with Counter {...}

Resolved

Unintended polymorphism.

Unresolved


Problems

Each component is hard linked.



Implementation only Inheritance.

Like private inheritance of C++.


Lack of language feature causes...

Repeated patterns.

Like GoF's Design Patterns.


Aggregation (aka Composition)

Well-known alternative.
public class Receptionist {
private Logger logger = new Logger();
private Counter counter = new Counter();
...
}
●
Resolved


Unresolved



Hard linking problem

For a component to be reusable, it must:

Remove hard links.

Abstract dependencies (aka interface extraction).
public interface ILogger {...}
public interface ICounter {...}
public class Logger implements ILogger {...}
public class Counter implements ICounter {...}


Dependency Injection (DI) Pattern

Well-known pattern in Java community.
private ILogger logger;
private ICounter counter;
public Receptionist(ILogger logger, ICounter counter)
{...}
...
}

Resolved



Dependency Injection (DI) Pattern

Problems

Wiring is too verbose.
ILogger logger = new Logger(...);
ICounter counter = new Counter(...);
Receptionist receptionist =
new Receptionist(logger, counter);

Unclear dependencies between components.



Java dosen't have features for

Expressing dependencies.

Flexible composition.



Work-around libraries/frameworks.


DI Container frameworks provide it.

e.g. Guice, Spring Framework, Seaser, etc.


Using DI Container

For example, in Guice
@Inject private ILogger logger;
@Inject private ICounter counter;
...
}

Resolved



Using DI Container

Resolved

Wiring (Composition) is too verbose.
public class Module extends AbstractModule {
@Override protected void configure() {
bind(ILogger.class).to(Logger.class);
bind(ICounter.class).to(Counter.class);
}
}



Createing some common patterns.

Work-around libraries/frameworks.

Scala has the features that Java lacks!


Scala's feature: Self type annotation

Expressing dependencies
class Receptionist {
this: ILogger with ICounter =>
...
}

Resolved



Scala's feature: Self type annotation

Flexible composition.
val receptionist =
new Receptionist with Logger with Counter

Resolved

Wiring (Composition) is too verbose.


Self type annotation vs DI Container

Static vs Dynamic?

Flexibility

Static < Dynamic

DI Container wins?

But static methods can compound dynamic methods.

To be precise, Static + Dynamic vs Dynamic!

Static + Dynamic > Dynamic


Is self type annotation perfect?

No, unfortunately it is not...


Fibonacci number

Easy and simple example.
public class Fib {
int fib(int n) {
if (n <= 1)
return n;
else
return fib(n – 1) + fib(n – 2);
}
}


Extend Fib

Memoization, easy.
public class MemoFib extends Fib {
private Map<Integer, Integer> tbl =
new HashMap<Integer, Integer>();
@Override int fib(int n) {
if (tbl.containsKey(n))
return tbl.get(n);
int result = super.fib(n);
tbl.put(n, result);
return result;
}
}


Extend Fib

Logging, easy.
public class LogFib extends Fib {
@Override int fib(int n) {
System.out.println(“Entering fib(“ + n +
“)”);
int ret = super.fib(n);
println(“Exiting fib(“ + n + “) = “ + ret);
return ret;
}
}


Combination explosion

Combine extension features.
public class MemoLogFib extends LogFib {...}
public class LogMemoFib extends MemoFib {...}

Problems


Code duplication.

Code of MemoFib and MemoLogFib are duplicated.

The same is true for LogFib and LogMemoFib.


Decorator pattern (GoF)

Specialized DI Pattern.
public interface IFib {...}
public class Fib implements IFib {...}
public class MemoFib implements IFib {...}
public class LogFib implements IFib {...}

Resolved


Code duplication.


Decorator pattern (GoF)

Problems

Composition is too verbose.
IFib fib =
new MemoFib(
new LogFib(
new Fib()
)
)


Try to apply self type annotation

The result ... ?
class Fib extends IFib {...}
trait MemoFib extends IFib { this: IFib =>
def fib(n: Int) = ... // how to refer composited fib?
}
new Fib with MemoFib // oops, error! Lacking override modifier

Problems

Can not refer to its own required components.

Can not composit components.

The Cause

Provided and required components are same.


Scala's feature: Abstract override

Modifier for overriding abstract method.
trait LogFib extends IFib {
abstract override def fib(n: Int): Int = {
println(s“Entering fib($n)”)
val ret = super.fib(n)
println(s“Exiting fib($n) = $ret”)
ret
}

Resolved

Can not refer to its own required components.


Scala's feature: Abstract override

Flexible combination with mixin.
new Fib with LogFib with MemoFib fib 42
new Fib with MemoFib with LogFib fib 42

Resolved

Combination is too verbose.

Can not composit components.

Improved

Resolving abstract method at composition timing.


Summary of Scala's OO features

Traits and mixin

provides flexible component composition.

Self type annotation

expresses required other components.

Abstract override

refers to abstract methods by super.

can handle some corner case of self type annotation.

provided and required component are same.


Benefities of the language support

Patterns can resolve problems, but...

Mostly verbose.

Need for common language.
●
Frameworks can resolve problems, but...

A little verbose compared with language feature.

Sometimes too large.

Language support needs for

reusability, readability and writability.


Scale, Scale, Scale!

Out of scopes

Sealed modifier, case class, pattern match and extractor

As (G)ADTs and pattern match

(Abstract) type member

Structural subtype

Implicit conversion and view bounds

Implicit parameter and context bounds

As type classes

Path/method dependent types

Etc...


Q&A

Any questions?


Thanks

Scale Your Programming!


Scala as "Better Java" from object-oriented viewpoint

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Scala as "Better Java" from object-oriented viewpoint

Semelhante a Scala as "Better Java" from object-oriented viewpoint (20)

Scala as "Better Java" from object-oriented viewpoint