Week 12 - Iterator and Composite Design Patterns

The Iterator & Composite Design Pattern¶

Classification¶

Iterator Design Pattern¶

• Behavioral Design Pattern

Composite Design Pattern¶

• Structural Design Pattern

Pattern Definition¶

Iterator Design Pattern¶

• Hard Definition: Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
• Easy Definition: Traverses elements of a collection and removes that responsibility from the collection itself.

Composite Design Pattern¶

• Hard Definition: Compose object into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
• Easy Definition: Represents data relationships in an upside down tree (i.e. part-whole hierarchy)

Representations¶

Mermaid Graph Iterator Design Pattern¶

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

classDiagram
    Iterator <-- Client
    Iterator <|.. ConcreteIterator
    Aggregate <-- Client
    Aggregate <|.. ConcreteAggregate
    ConcreteIterator <-- ConcreteAggregate
    class Client{
    }
    class Iterator{
        <<interface>>
        +hasNext()
        +next()
        +remove()
    }
    class ConcreteIterator{
      +bool is_wild
      +run()
    }
    class Aggregate{
        <<interface>>
        +createIterator()
    }
    class ConcreteAggregate{
        +createIterator()
    }

Mermaid Graph Composite Design Pattern¶

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

classDiagram
    Component <-- Client
    Component <|-- Leaf
    Component <|-- Composite
    Composite *-- Component
    class Client{
    }
    class Component{
        <<abstract>>
        +operation()
        +add(Component)
        +remove(Component)
        +getChild(int)
    }
    class Leaf{
        +operation()
    }
    class Composite{
        +operation() : "for(Component c : children) c.operation"
        +add(Component)
        +remove(Component)
        +getChild(int)
    }

UML Iterator Design Pattern¶

UML Composite Design Pattern¶

Real World Usages¶

Iterator¶

• Of course the Java Collections framework!!!
• Scanner class!!! <- WHAT!?! Wow, that makes sense!

Composite¶

• Document Object Model! Yes, the DOM of most documents and browsers use this design pattern!
  • HTML Elements are the leaf components!
  • Document is like a Composite component!

Java Code Example¶

• Iterator Design Pattern
• Composite Design Pattern

Main Take-Aways from the textbook¶

Iterator Design Pattern¶

• An Iterator allows access to an aggregate’s elements without exposing its internal structure.
• An Iterator takes the job of iterating over an aggregate and encapsulates it in another object.
• When using an Iterator, we relieve the aggregate of the responsibility of supporting operations for traversing its data.
• An Iterator provides a common interface for traversing the items of an aggregate, allowing you to use polymorphism when writing code that makes use of the items of the aggregate.
• The Iterable interface provides a means of getting an iterator and enables Java’s enhanced for loop. Java Collections inherit from Iterable and most Java data-structures implement the Collection interface

Composite Design Pattern¶

• We should strive to assign only one responsibility to each class.
• The Composite Pattern allows clients to treat composites and individual objects uniformly.
• A Component is any object in a Composite structure. Components may be other composites or leaves.
• There are many design trade-offs in implementing Composite. You need to balance transparency and safety with your needs.

Main OOP Principles of Iterator & Composite Pattern¶

Iterator Design Pattern¶

• Programs to the Interface, not the implementation. Client only needs to know that it has a Collection and can get an Iterator.
• Encapsulates what varies by encapsulating the iteration itself.
• Loosely Coupled design since it decouples the client from the implementation of the collection.
• Single Responsibility. The collection has only one reason to change because it doesn’t have to support iteration internally, it just manages the collection.
• Polymorphism! Client iterates over different collections as if they are the same even though the underlying iteration implementations are significantly different.
• Open Closed Principle because the iterator allows the Collection code to be closed to modification, but open to adding iteration.

Composite Design Pattern¶

• Loosely Coupled design since it decouples the client from both the leaf and composite structure and provides a uniform way to traverse and access both.
• Programs to the Interface, not the implementation. Both the Leaf and Composite structures inherit or implement the common abstract class or interface.
• Favors Composition Over Inheritance because the Composite is literally composed of other Components to accomplish the uniform treatment of hierarchy elements.