Opinionated Software :Good or Bad

Today I was reading about Angular JS and came across a new term "Opinionated Software". Out of curiosity, I explored more and tried to put my understanding in this blog.

What is opinionated Software?

Opinionated Software has restrictive features and well defined approach. It guides the developers to perform task in specific manner with only given set of features.

It has a vision and holds an opinion, that if used in prescribed manner it makes the task simple and easier but any deviations from actual approach is going to result in complexities.

Examples of opinionated Software:

Angular JS is opinionated as it forces the MV* structure.

Examples of un-opinionated Software:

PHP comes under this category. It offers developer with flexibility choose its own code structure and design that fits its requirements and adheres to best development practices.

.NET Framework also comes under this category.

Opinionated Software: Good or Bad?

It is debatable topic, If we go by majority, their vote goes for "Opinionated Software" and in their support they say it has both vision and approach which are integral part of good software.

But there also exists a group of people who don't consider it as a good option as it imposes its fixed approach and is not flexible. Also it offers only limited set of features and ignores new features request.


References:

https://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php

Introduction to Design Patterns

Introduction

My first post is for all beginners’ keen to learn the concept of design patterns. I tried to cover all the questions that I had during my first interaction with design patterns. If I have missed on something, please post your comments and queries to me. I will try to address your concerns as soon as possible. 

As a beginner, design pattern may be a totally a new world to you. In order to learn ABCs of it, we need to explore the basic questions “What, Why, When, Where,…” of design pattern.

So let us proceed, getting familiar with few important terms and answering all the basic questions.

Important Terms

• Gang of Four

In software field, authors of book "Design Patterns: Elements of Reusable Object-Oriented Software" are referred as "Gang of four" or "GoF" .These four authors ("Authors : Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides") has clearly defined 23 design patterns for object oriented programming.

• Scalable System

A system is said to be scalable if it satisfies any of the below conditions:

1. It works efficiently when subjected to large situations like large number of users using application concurrently or large input/output data has to be processed etc.
2. It works properly and utilize the full benefits in terms of performance when its size or volume is increased by adding resources to manage the increased load or user needs.

• Maintainable System

Software system in which issue resolution, changes, modifications, extension and enhancements activities can be done with minimum effort and time is termed as Maintainable System.

• Loosely Coupled System

In object oriented system, coupling defines the level of interdependency among modules or classes. Low degree of interdependence implies loose coupling, which in turn facilitates change in one class without affecting the other classes of system.

• Highly cohesive System

In object oriented system, cohesion is defined at class level and is measure of logical relationship that exists among the members of the same class. High cohesion implies variables and methods of class have strong logical relationship with each other. A class, as a whole, should work as a unit and does only few logically related jobs. To conclude, highly cohesive systems are the ones which consist of classes with high cohesion.

Now coming back to the main topic,

What is Design Pattern?

As a software developer, you are assumed to implement the best practices in an application and design pattern is one step in that direction. If we get similar kind of problem or situation in software design, first thought which we get is to look for some generic or reusable solution to these similar recurring scenarios. Design Pattern is that generic or reusable solution for recurring scenarios or problems in software design.

At an implementation level, it’s important to understand that design pattern is not an application design but aids in its creation. To emphasize, design patterns are just the guidelines to create the actual design of an application and in no way replace the design phase of software cycle. Talking in object oriented terms, design patterns only explains at high level how in general the objects or classes of any application implementing it should interact and communicate with each other, but it’s the application design that transforms that idea into final objects or classes.

Design patterns has special place in both functional programming and object oriented programming. As per the thumb rule, design pattern should result in loosely coupled and highly cohesive system. This in turn facilitates high maintainability and writing automated unit test cases.

Are they Language Independent?

It’s partially true. Baring few patterns from list of Gang of Four, rest are language specific or language dependent and need implementing language support.

Also most of the objected oriented patterns are not suited for functional programming. Take an example of visitor pattern; it can be helpful in object oriented system but not functional programming.

It has been very clearly and precisely explained by author Norman Ramsey on stackoverflow.

Why we need them?

Need of design patterns arise from the underlying benefits they provide. By now, we know that the design patterns are already tested, proven, reusable and an effective solution to commonly recurring problems in software design. Intelligent approach is to reuse these existing proven solutions rather than spending precious development time in re-inventing.

Besides being common solution, design pattern offers re-usability, scalability, maintainability and helps in communication. Software’s designed using design patterns are loosely coupled and high in cohesion, which in turn offers maintainability. The high maintainability facilitates bug fixes and addition of any new feature. 

Design pattern also plays an important role in an effective communication at several levels of development. Whether it is client presentation or Knowledge transfer session, the common standard terminologies of design patterns makes the task easy. Now instead of explaining each line of code, simply mention about the design pattern implemented and rest is done.

for e.g. developers use many general terms like inheritance, encapsulation or polymorphism while explaining their application to peer members or client without even bothering to explain them. Reason being, these terms forms basic foundation on which object oriented world stands and all developers are assumed to be aware of them. In a similar manner, design patterns carry their standard terminologies and name of any specific pattern itself explains the code structure of an application. So instead of explaining the code flow of an application in detail, its preferable to only mention the names of patterns implemented. This makes the technical discussion short, precise and easier to understand. Take "Singelton" pattern for reference, everybody familiar with it knows that the object of a class is created only once during the entire life cycle of an application with this pattern. So we can say “singleton pattern is implemented in the application" instead of  “application code creates the object of a class only once during the entire lifecycle of the application”.

When and where to apply them?

There is no set algorithm to apply design patterns. Applying them needs craftsmanship with visualization powers and proper mind set. First and foremost thing to understand is that the design patterns are not only the solutions to current application issues but also the precautionary measures to avoid or reduce the effort needed for future application enhancements or extensions. 

If any changes or additions to an application come after initial development, they can be handled in two manners. First is to rewrite your code to accomplish required changes or additions and other is to code your application in such a manner that future changes or issues can be handled with minimum effort and few code changes.  The later approach refers to applying precautionary measures named design patterns to your application code. 

It’s the design stage of software cycle at which the decision of suitable design patterns for an application is taken. Being at initial stage of software cycle, developer is only aware of the present requirements and has no idea of issues, extension or enhancements that can come in future. So the real challenge is to make the correct judgment and select design pattern that can resolve application issues and accommodate future changes with minimum effort. This judgment can either come through years of development experience or by simply studying several applications with same design pattern. For e.g. to learn adapter pattern, pick some of the applications that implements adapter pattern and try to figure out the problems adapter pattern resolves in those applications and under which scenarios they can come. Ones you have gained this knowledge, it’s easy for you to design any application similar to the ones you studied. Reason being, at that point you are already aware of the problems or scenarios the resultant application has to manage and the solution to them is adapter pattern.

Also it is worth mentioning here, that each architectural layer can have more than one design pattern implemented thereby implying that an application can have one or more than one design pattern. Other important point to note down is that never try to enforce some design pattern on your code just for the sake of implementation rather try to figure out which pattern is optimum and best fit for your application.  Correctly chosen design patterns can lead to the path of success whereas wrong choice can prove an application disaster.

For more clarity, let us try to understand this with an example

Suppose IT Company A gets project from Medical Insurance Company B to develop an application for processing their medical claim. Though at this stage, requirement is to develop this application for company A. But looking from business angle, it is not hard to anticipate same requirement coming from other Insurance vendors.  So instead of making separate applications for each vendor in future, optimum approach is to make generic application using facade design pattern for company A and reuse it for other vendors.

How can we classify or group them?

Design patterns have evolved over the time but base reference is still GoF. As per GoF guidelines, their 23 design patterns can be grouped in three categories.

• Creational patterns

They define the ways single object or group of objects can be instantiated.
The Gof patterns which come under this category are:

1.  Abstract Factory
2. Builder
3. Factory.
4. Prototype
5. Singleton

• Structural patterns

These patterns define relationship between classes or objects.
The Gof patterns which come under this category are:

1. Adapter 
2. Bridge
3. Composite
4. Decorator
5. Facade
6. Flyweight
7. Proxy 

• Behavioral patterns

Patterns falling under this category define the ways classes or objects communicate.
The Gof patterns which come under this category are:

1.  Chain of responsibility
2. Command
3. Interpreter
4. Iterator
5. Mediator
6. Memento
7. Observer
8. State
9. Strategy
10. Template method
11. Visitor

What's Next?

My next post is going to be a lab for above concepts and we are going to create an application using design patterns.