Framework vs Software developer's mindset

It has been 6 to 7 years (depending on how you count) since I started a career as a software engineer. Not even once in those years have I got the opportunity to design and develop a framework. After taking a course in design patterns and started to work on project to design a framework, I have come to realize that the mindset I had as a software developer is quite different from the new mindset I am acquiring from my framework design and development experience. In the course I have studied and exercised all 23 design patterns, starting from Singleton all the way up to Iterator and Visitor from the Gang of Four (find some of my examples here), and I was struck with how little I knew about design patterns.

As a software developer my mindset was always pointed towards how to accomplish the functional and nonfunctional requirements of the software, how to best design it for great flexibility and maintainability, higher performance, and how to appropriately handle potential concurrency issues etc. Now, when I try to understand what frameworks are and how they are designed, I was getting it mixed up with the meaning of libraries. But seriously what is the difference between a library and a framework? to my understanding, a library is a collection of functions and classes that one can utilize to facilitate building an application. Whereas a framework provides generic flow of control to custom written computer code or class using a design principle known as Inversion of Control (IoC). This design principle is often referred to as the Hollywood principle. In Hollywood, if a young actor who is struggling to start his career in the movie industry reach out to producers for a role in a movie, the tradition is that he will be told, “don’t call us, we'll call you when we need you!”. Generally, frameworks work in the same manner, by injecting services to custom designed developer classes at run time when they are needed. For this reason it’s usually challenging for developers to understand what frameworks are and how they function. On top of that in the traditional programming world, developers would refer to class libraries and function methods from their code when they need to use them, e.g a Java developer may call Java.lang.Math.pow(double a, double b) from his class method to calculate a to the power of b, therefore it’s obvious that the developer’s class is in control for the use of the library method. Frameworks works quite to the opposite, for instance let’s assume a developer is using a framework that is designed with IoC and Dependency Injection (DI) design principles.

In the usual programming practice below is how we would instantiate an object of the associated class Address inside a Person class.

1. public class Person {
2. private IAddress address;
3.    public Person() {
4.        address = new HomeAddressImpl();
5.    }
6. }

The problem with this is; in order to create an instance of Person class, the developer has to know the correct implementation of the associated IAddress interface and instantiate it using the new keyword.

Using Dependency Injection, which is a design principle that is widely used along with IoC to build frameworks, the code above could be improved like this:

public class Person {

1. private IAddress address;
2.    public Person(IAddress address) {
3.        this.address = address;
4.    }
5. }

This improvement doesn’t require the developer to specify the implementation of the Address class, as the framework will inject it to the Person class during instantiation at run time. This has a number of benefits; one it adds a great flexibility by enabling the developer to use different implementations of the Address class. Besides, it is much easier to test the Person class by passing a mocked object of the Address class.

Now, understanding how frameworks work was not easy, at same time trying to understand how to build one was a whole new level of challenge for me. In my effort to understand how to build a framework, here is an analogy that I found helpful:

Whenever I want to cook delicious and my favorite Ethiopian dish Injera with Tibse, I list down the things I need, which are first and foremost - injera, supplies such as beef, tomato, onions, garlic, oil, jalapeno and a spicy pepper called “berber”. I also need utensils such as a cooking pan, stove, and a knife. My knife was broken the other day and I went to the supermarket to get one. While on the way to the supermarket I told my friend that I am going to buy a ‘Cleaver’ knife because it is sharp, big and quite satisfying when I use it to chop onions and tomato. She suggested it is better to get a ‘Kitchen knife’, because it easy to use and appropriate for the kitchen, and she added that it’s called kitchen knife for a reason. She had a point there, and I immediately started to think of a solution that would satisfy both our wishes. The first solution that kicked in was, I should buy both types of knives and put them in the kitchen, but then I wondered what if my roommate, whom I enjoy living with and wouldn't like to make him feel uncomfortable under any circumstance, wants another type of knife. Do I tell him to go and get his own knife? for sure I can do that, but that wouldn’t be the ideal solution.

Wouldn't it be nice if we can go to Walmart and shop a machine that is designed to produces any kind of knife we want? Indeed that would be great, I am sure someone has thought of this before, but here are two reasons why I think this is not an attractive product for Walmart: The first is, since the machine is designed to make all kind of knives it will be difficult to configure and costly and complex to maintain. Second, it will be difficult to market it because not everyone needs all types of knives, generally people tend to like a machine that is designed to make one specific thing. So let's think how we can improve it; a much better idea would be to build a machine that produces another customized machine which will be making the specific kind of knives a person needs. The machine to produce another machines will be designed and built by experts so customers just need to input the list of knives they want, and a customized machine that can make those kind of knives will be built on a button click. Now, this is nice solution to the problem and I like to think of the machine as a real world analogy to a framework, a framework that can used to design and make knives. After sharing my thoughts with my friend, luckily she is also a software engineer and usually enjoys my fanatic talks like this, she said “it is a nice solution but can we also do the same to make cooking pans, because I don’t like the one we have in our kitchen”.

Oops! after all the framework I came up with for making knives, which might have costed me millions of brain cells, was not good enough for my friend. So I continued to think, an even more cooler framework would be to design a machine that let's the user choose the utensil type (e.g knife) and produce another machine that is designed to produce machines which in turn can make all kind of knives (e.g cleaver and kitchen knife). So we agreed with my friend the solution was to make a machine that makes a machine which again produces a machine that is designed to make the kind of knife one would want. This sounds a bit nested and not easy to understand, so I will try to come up with a simple Java realization of it using design patterns when I get the time.