c# barcode generator library open source Shape Abstractions in Font

Painting DataMatrix in Font Shape Abstractions

If we have a collection of shapes that derive from the common trait OShape that has an area method on it, our object definitions would look something like the following if we used a traditional OOP approach:

trait OShape { def area: Double } class OCircle(radius: Double) extends OShape { def area = radius * radius * Math.Pi } class OSquare(length: Double) extends OShape { def area = length * length } class ORectangle(h: Double, w: Double) extends OShape { def area = h * w }

Let s compare this with the pattern-matching implementation:

trait Shape case class Circle(radius: Double) extends Shape case class Square(length: Double) extends Shape case class Rectangle(h: Double, w: Double) extends Shape object Shape { def area(shape: Shape): Double = shape match { case Circle(r) => r * r * Math.Pi case Square(l) => l * l case Rectangle(h, w) => h * w } }

In the pattern-matching example, all of the logic for calculating area is located in the same method, but the fact that the method exists is not obvious from looking at the Shape trait. So far, the OOP methodology seems to be the right answer because it makes obvious what shapes can do. However, if we have a shape library and we want to calculate the perimeter of each of the shapes, there s a benefit to pattern matching:

def perimeter(shape: Shape) = shape match { case Circle(r) => 2 * Math.Pi * r case Square(l) => 4 * l case Rectangle(h, w) => h * 2 + w * 2 }

In this case, the open data makes implementing the perimeter method possible. With the OOP implementation, we would have to expose data to make the perimeter method possible to implement. So our OOP implementation would look like

trait OShape { def area: Double } class def def } class def def } class def def def } OCircle(radius: Double) extends OShape { area = radius * radius * Math.Pi getRadius = radius OSquare(length: Double) extends OShape { area = length * length getLength = length ORectangle(h: Double, w: Double) extends OShape { area = h * w getHeight = h getWidth = w

More broadly, it s rare that the designer of an object hierarchy implements all the methods that a library consumer is going to need. The visitor pattern is a design pattern that allows you to add functionality to a class hierarchy after the hierarchy is already defined. Let s look at a typical visitor pattern implementation. Following is the interface that defines the visitor. The code contains

circular class references and will not work at the REPL. So, first the code, and then a walkthrough of the code:

trait def def def def } OCarVisitor { visit(wheel: OWheel): Unit visit(engine: OEngine): Unit visit(body: OBody): Unit visit(car: OCar): Unit

trait OCarElement { def accept(visitor: OCarVisitor): Unit } class OWheel(val name: String) extends OCarElement { def accept(visitor: OCarVisitor) = visitor.visit(this) } class OEngine extends OCarElement { def accept(visitor: OCarVisitor) = visitor.visit(this) } class OBody extends OCarElement { def accept(visitor: OCarVisitor) = visitor.visit(this) } class OCar extends OCarElement { val elements = List(new OEngine, new OBody, new OWheel("FR"), new OWheel("FL"), new OWheel("RR"), new OWheel("RL")) def accept(visitor: OCarVisitor) = (this :: elements).foreach(_.accept(visitor)) }

The library author has to think about extensibility and implement the visitor pattern. Note also that the class hierarchy is fixed in the visitor because the visitor has to implement an interface that defines all the possible classes that the visitor can handle:

trait def def def def } OCarVisitor { visit(wheel: OWheel): Unit visit(engine: OEngine): Unit visit(body: OBody): Unit visit(car: OCar): Unit