Design Patterns in Smart UI

One of the reasons why Smart UI fascinates me is the way Design Patterns have been applied. As we go and explore Smart UI code, we would encounter many Design Patterns.

But what is a Design pattern ? There are many definitions and variations of Alexander's (Christopher Alexander is the architect who first studied patterns in buildings and communities and developed a "pattern language" for generating them) original definition . But what I liked or prefer to recollect as definition is the following:

"A Pattern is a named description of a problem and solution that can be applied to new contexts; ideally, it provides advice in how to apply it in varying circumstances, and considers the forces and trade-offs. Many patterns provide guidance for how responsibilities should be assigned to objects, given a specific category of problem."

In simpler terms, A pattern is a reusable solution that can be applied to commonly occurring problems and not code solutions which could be used directly. Design Patterns are templates, when applied, solve commonly occurring design problems through proven solutions.

MVC (Model-View-Controller) : Out of the many Design patterns observed in Smart UI, MVC (actually a variation) is the most important one and without understanding it , if you start designing/coding in Smart UI then you are really asking for trouble. MVC addresses separation of concerns and decouples Business/Domain data (Model), Presentation layer (Views) and the interactions(Controller) among various parties (User Input, Model Changes/Updates, View Changes/Updates) . But why this decoupling is required or what does it help ? It actually reduces Spaghetti code, reduces dependencies, allows separate development of User Interface, Business data objects and the Data flow Handling, minimizes the impact of code or logical changes among the different components. More importantly it helps code resuse . While the Model represents the data in an application, a View is the visual representation of the Model and a Controller controls the communication by updating the views when data (Model) Changes and updating the models when a View changes though some user input\interaction.

There is a variation of MVC pattern, called MVP (Model-View-Presenter) which further decouples the Presentation logic from views and this acts a Controller.

Smart UI neither applies pure MVC nor a MVP design pattern. There are no controllers in Smart UI (though context is a Marionette Controller, it is not the MVC's controller) There are no Presenters as well. All the Business data in Smart UI is represented by Backbone Models and the presentation layer is implemented through Marionette Views. The Views in Smart UI play the role of MVC's Views and also the Presenter's role in MVP.

Command: The menu actions (Inline or Table Header) in Smart UI are implemented through Command Design Pattern. The main idea behind the command pattern is that it provides you a means to separate the responsibilities of issuing commands from anything executing commands, delegating this responsibility to different objects instead. To achieve this separation, the designer creates an abstract base class that maps a receiver (an object) with an action (a pointer to a member function). The base class contains an execute() method that simply calls the action on the receiver. The core implementation of Copy /Move/Reserve/Initiate Workflow etc are done through Command Design pattern. These Copy/Move/Reserve Actions are actually concrete Command implementations. So the function menus in the Classic UI, are now encapsulated as Commands.

Mediator: The heart of all the Smart UI components (from my perception) is a Context object. If we dig more into the definition of this module, anyone would surely get a shocker of his life. The declaration says it is Marionette Controller. Now if you get to the latest Marionette library code or the documentation, you would not find any information about this controller, It is actually deprecated. With all the MVC knowledge, the inference would be that it could represent Controller in MVC. But it actually has nothing to do with MVC and is indeed an application of Mediator pattern. Mediator pattern defines an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Factory: Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface. Most of the models and Collections in smart UI are created through factories.

Observer : Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The Breadcrumb panel is the observer and gets updated as the current folder\container changes. Similarly the filter panel is the subject and whenever a filter is changed the browse widget observes it and shows filtered data as response.

Decorator: This pattern adds responsibilities to individual objects dynamically and transparently, that is, without affecting other objects. For Example the Perfect Scrolling or Infinite Scrolling behavior can be added to a view or widget without actually writing the code in the View definition. This helps code reuse and decorates the view with the behavior.

There are more Design patterns observed in Smart UI but the intention of the article is actually not to list everything or show case my knowledge of Design patterns. It is about sharing my journey and inspiring others.