Common Behavioral Patterns (part 2/3)

Behavioral Pattern

Choosing a good appropriate pattern would help make the code cleaner, easy to reuse, and limit the potential error, thereby speeding up the process of building.

Behavioral Patterns describe the communication between different objects.

Command, Iterator, Memento

1. Command

Command Pattern
  • We apply this pattern when
    - We want to separate the UI and the business logic to prevent duplicated methods.
    - We want to pass a method as a parameter of another method.
    - It also helps to implement undo, log, transaction, and the callback (inside the execute method of the invoker class)
  • In ruby, the comment layer and receiver layer have been removed when we using block, lambda, proc.
  • This pattern would have
    - Invoker receives the command request from the client. Invoker stores a command as a private variable and Invoker would have a public execute method.
    - Command is the middle layer. The execution method of this class would contain the receiver execution method.
    - Receiver contains the main behavior logic.
  • For example, an editor with several buttons. By default, we implement an interface Button and there are many subclasses. It could happen a problem when we change some logic in the base class. Furthermore, some of them such as Ok, Save, and Yes have the same logic “save”. It would be duplicated code if we define the “save” function on each subclass. So, by splitting out the logic and we can reuse the code.
  • Let's take an example, an editor has 3 buttons “copy”, “cut”, “paste”

2. Iterator

  • This pattern aims to control collections’ data (array, hash, tree) and behavior by splitting the iterator into a separate class for easy reuse and extensibility.
  • For example, we have CircleShape and SquareShape. These shapes are different structures and behaviors from each other. The CircleShape’s node can move around, but the SquareShape’s node can not.

3. Memento

  • This pattern is about capturing the history of an object. It let us save and restore the previous state of an object without revealing the details of its implementation.
  • In this pattern, we would have 3 objects such as
    - Originator is the one that would be captured states. Every moment it only has a state.
    - Memento is the recipe for how we store the state of Originator. We can count memento as a revision of Originator.
    - CareTaker, like its name, would hold and take care of the Originator and Mementos
  • Let's get an example, we would like to log all the historical changes of the campaign.





passion in finding solutions and research some things relate to technical and helpful in life. Also strongly interest in foods, travel, and gentle music :)

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Meetings, meetings everywhere

How to Introduce Throttling to Your Production Service — the Easy Way

System Design: Database Transactions & ACID compliance (Part 1)

Applying Test-Driven Development

Erlang-For-Beginners E101: List Comprehensions

Best of the Week — October 25/31

XXS: The height is 145CM and the weight is 34KG, which is suitable for XXS size

CS373 Fall 2021: Tushar Kohli

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store


passion in finding solutions and research some things relate to technical and helpful in life. Also strongly interest in foods, travel, and gentle music :)

More from Medium

NoSQL Databases

Dealing with randomness in tests

The trade-off between query performance & data consistency when working with connected data in…

A user schema defined in user.js file

How to Use the JSON Data Type in PostgreSQL: A Brief Manual