Contextual Vs Composable design

Today at work, a colleague told me about a very interesting topic I never before thought about; Composable Vs Contextual software. I decided to read a bit more on the topic and just post some brief conclusions.

When designing new software, probably one of the most important questions we want to ask ourselves are:
-Who is going to use it?
-How is going to use it?

By talking to the future users of the solution, we can gather relevant information that will help us give answers to the above questions and therefore, determine if what we have to build has to be composable or contextual.

So what is composable and what is contextual then?
If you type in google "define:composable design" or "define:contextual design" you will get really good definitions(Just in case is not clear what I am about to say next). But I will also try to give a more reductionist definition with my own words:

-Composable: For me a composable system, is boundaryless in what regards the interactions the user can have with its components.

-Contextual: For me a contextual system is a system that defines constraints, flows, etc... to guide the user in a predefined way, when it comes to the interactions with its components.

Pros and Cons
So as I said before the important thing is, to understand who the user is and how is going to use the system, but is also good to be aware of some advantages and disadvantages of both designs:

Composable
Pro: Big flexibility.
Con: With great power comes great responsibility(It can be dangerous if in wrong hands).

Pro: Less maintainability
Con: May require training/mentorship for less experienced users

Pro: Generic/Multipurpose
Con: Non-Specific, could be used for the wrong purpose.

Pro: Fast for experienced users
Con: Slow for less experienced users

Contextual
Pro: Solves a problem
Con: Is limited to just that problem/Not reusable in other problems

Pro: Its easy to use
Con: Needs maintenance

Pro: Fast for less experienced users
Con: A constraint for experienced users

Pro: Does most of what you want fast and easy.
Con: Dietzler’s Law for Access(Does 80% of what the user wants easily, but does another 10% with difficulties and finally is unable to do the other 10%)

Just to complete this post, lets write some examples of Contextual vs Composable:

-GUI Vs Terminal
-Framework Vs Programmatical approach
-Wizard Vs copy&paste files into directories

As a conclusion, all I can say is that the decision on which design to go for, will depends on the type of user you are dealing with.

Resources:
-http://gigaom.com/2013/02/16/devops-complexity-and-anti-fragility-in-it-context-and-composition/
-http://nealford.com/memeagora/2013/01/22/why_everyone_eventually_hates_maven.html
-www.google/com

It's been a while. Glad to see you are back.

When doing certain tasks that are tedious, difficult or just we are to exausted to do them; we often whish there was an altruistic someone to give as a hand and make them easier. Sometimes in this situations we would be ready to accept help from anybody, even from an strange visitor...


Visitor is a behavioral design pattern that intends to add or remove functionality from a class without changing its original implementation. It can help leverage complexity and also allows to keep concerns separated. Also is non intrusive, since will be only the clients choice to either allow the visitor to come by and provide support or not, by just calling a method.

Let's have a look at a bit of UML:

 

The only modification needed in the original class it to add a method that accepts a visitor.
That method will be called only by the client and the visitor to visit that class will also be provided by the client. The visitor just have a visit method that takes a concrete implementation of the class that has to visit. If you used the Visitable interface as parameter in visit method is not wrong but you will restrict the visitor to just what sees in the interface(In occasions can be desirable).

Now lets have a look at an example.
Here the Visitable interface and a couple of implementations:

 public interface FormulaOnePitOperation {  
   public void perform();  
   public void accept(Mechanic visitor);  
   public int dangerLevel();  
 } 

 public class PetrolFilling implements FormulaOnePitOperation{  
   private int petrolLevels;  
   public void perform() {  
     System.out.print("Filling the tank as we always do...");  
   }  
   public void accept(Mechanic visitor) {  
     visitor.visit(this);  
   }  
   public int dangerLevel() {  
     return petrolLevels;  
   }  
 } 

 public class WheelsReplacement implements FormulaOnePitOperation{  
   private int presureIndicator;  
   public void perform() {  
     System.out.print("Changing the wheels as we always do...");  
   }  
   public void accept(Mechanic visitor) {  
     visitor.visit(this);  
   }  
   public int dangerLevel() {  
     return presureIndicator;  
   }  
 }  

As we see in the above code, the visitor is passed in the parameter of the accept method that is used to trigger the visit.

Lets now have a look at the visitor's side

 public interface Mechanic {  
   public void visit(FormulaOnePitOperation formulaOnePitOperation);  
 } 

 public class PetrolPumpMechanic implements Mechanic {  
  public void visit(FormulaOnePitOperation formulaOnePitOperation) {  
     System.out.print("You are doing well guys keep going, I am just keeping an eye on the pump here. I won't disturb you");  
     if(formulaOnePitOperation.dangerLevel() > 100)  
       System.err.print("STOP!!! CLOSE THE PUMP NOW!!!!");  
   }  
 } 

 public class WheelsMechanic implements Mechanic{  
   public void visit(FormulaOnePitOperation formulaOnePitOperation) {  
     System.out.print("Just supervising the wheels replacement operation! Not disturbing");  
     if(formulaOnePitOperation.dangerLevel()>45)  
       System.out.print("Be careful you are pumping them too much");  
   }  
 }  

In the visitor side, the functionality of the FormulaOnePitOperation can be modified without changing any of the original code. Also another thing to notice in the above example is that since we are using the interface as parameter, we may be limmited to only use what is defined on it. In occasions is just enough and there is no need to access the concrete classes, but note that the UML diagram encorages to use the concrete implementations(In my personal opinion, I think there is not a big difference since the methods on the concrete classes could not be exposed publicly)

Now finally just the client class:

 public class Pit {  
   public static void main(String[] args) {  
     FormulaOnePitOperation petrolFilling = new PetrolFilling();  
     FormulaOnePitOperation wheelsReplacement = new WheelsReplacement();  
     petrolFilling.perform();  
     petrolFilling.accept(new PetrolPumpMechanic());  
     wheelsReplacement.perform();  
     wheelsReplacement.accept(new WheelsMechanic());  
   }  
 }  

Not much to say about the client, it just uses the classes as usual with the only difference that as per need now can pass a visitor to help add certain tasks. I mentioned at the beggining that Visitor is a non intrusive pattern, by this what I want to say is that nothing mandates the client to call a visitor if he doesn't want to.


A little dissadvantage that this patter has, both methods accept() and visit() have hardwired dependencies in their parameters that can make them hard to unit test.


          It's been a while. Glad to see you are back.

 

Pair programmers in action