Monday 24 November 2014

An important Software Design Property - Context Independence

We could start by asking what Context really means in terms of Software Design and why having Context Independence is good? Firstly, lets define Context:

Context -  it is  everything that needs to be set in order to use a given data structure (i.e a Class). This is mostly about its relationships and their dependencies.

Basically the Context of a given structure is what it needs to be functional, so without Context you can't use It. In other words, this is something that you can't avoid, you need to deal with it when designing your software. BTW, there are some very known design issues that follow  Data Structures with Heavy Context. Some of them are:
  • Make them hard to test;
  • Make them hard to use/reuse and extend;
  • Deal with this kind of structures is always hard, so it'll naturally make the them hard to change and maintain
Lets look to an example, Consider the following classes relationship:


Here are them exchanging messages:


AS far we can see, Class B, Class C and Class D have their own Context. This something they need in order to make their job. Class A is using them, and also it dealing with their contexts, as soon it needs to initialize them.  Here is where problems get started. What about the effort needed to test Class A? Avoid dealing with each individual Context  would be something desirable by any  Class which needs to the those classes. The property we are looking forward here is Context Independence.

A technique that can be used on this case is Dependency Injection. DI can make Class A free from the Context Initialization. By consequence it will also be flexible and make the design more susceptible to changes. This is how  it could looks like:



Now Class A is Context Free once it does not deal with all details with Context from other classes. Implementation on Class A will be more clear, testable and easier to extend and change.

Another technique that can be used in order to be sure if a given Structure is Context Free is checking how it is communicating  with other Structures. If it is asking other Structures How to things instead of What,  it means you are on the wrong. You probably have a Structure that knows too much about others  and it is probably dealing Contexts you should avoid.

Context Independence is a technique that can help you to keep the healthiness  of your design. It works pretty well with SOLID principles. I am actually not able to see them work separately  in a more complex solution.




Monday 10 November 2014

Building Changeable Software - The new Bridge Metaphor

In a Software Engineer daily job, there are several situations where a complete redesign needs to take place in order to make things work as they ideally need. The reasons to that happen (sometimes often than we'd like to see) can be many. I'll try to list some of them, but i can be missing some:

  • As developers we make mistakes - this one is obvious, knowledge about the domain  will come with time, the same is also valid for engineering techniques and principles. Until there we are gonna make mistakes and lack of  Code Review and design sessions  can just potentialize it.
  • Pressure to deliver - there are scenarios where we just need make things as faster as we can. Issues in Production that affecting the user experience can be damaging to business. So on this scenarios there is few space to huge refactorings  and redesigns and that is reasonable. The problem start when people start use this excuse to put pressure on anything we do, even it is not Production specific.
  • Fear to touch on production code - lack of test coverage can make it worst.
  • A mix between all them.
Understand the reasons why it happens and learn how deal with them is important for a Software Engineer also. Given the frequency it is scenario is presented to us, know how to deal it sometimes is the key in order to start introduce changes.

The new Bridge Metaphor

Let's say there is a bridge over a river. It lets people go here and there with their cars, but it is becoming too old. It's maintenance is becoming expansive and it is no long supporting the traffic volume. A new solutions needs to take place, otherwise users will suffer on the next years with the problems the current bridge is gonna present.
Ok, what about rebuild the current bridge in order to attend the new demands? The idea looks promising in terms of costs, but in the end of the day, it'll represent the bridge unusable during days or even weeks, which is unacceptable. Does not matter what happens, people needs to be able to keep using it.
Well, what could be done then? An alternative is keep the old bridge working and build a new one. At some point, when the new bridge is ready, the whole traffic can be switched to the new and fresh bridge disabling the old one.
Even more expansive, this is the most feasible thing that can be done once the other approach would bring several headaches to the users

Ok, but what it is the relationship with software development? I'd say it is all.
Business needs to keep moving, most part of the time there isn't much space to stop deliver functionality to make big redesigns. Try to sell this approach to business usually does not work. Moving things little by little is much easier to sell once it can be conciliated with functionality being delivered to production. This is like keep the old bridge working while new one is being  built, as far you can see on the picture.

As a Software  Engineer, I usually spend most part of my time maintaining software rather than working on green field projects  On such scenarios i have been following this approach in order to delivery good software and keep things moving. It also fits pretty well when dealing with legacy software.
The downside when following this metaphor is that at some point you will need to accept some code replication and some "ifs" on the code being delivered while the new bridge isn't done.