Temporal Coupling (Part 2)

Workflow

In all projects, we would like to know what all things can happen at the same time, and what must happen in a strict order. This is why we need to know users’ workflow. One way for recording this is to use UML Activity Diagram.

Activity Diagram consists of rounded boxes, representing actions. An arrow from one action leads to another action, which can start after the first action. It also contains a thick line called Synchronization Bar. Once all the actions leading to a synchronization bar are complete, we can then proceed along any arrows leaving the bar. Also, an action can be started at any time if no arrows are leading into it. Activity diagrams can be used for achieving parallelism.

Analyze Workflow to Improve Concurrency


- summary of Workflow, from The Pragmatic Programmer: From Journeyman to Master

Temporal Coupling (Part 1)

Temporal coupling, as the name indicates, is related to time. In software development, we think about time schedules or deadlines. But time should always be a design element of the software. Usually we don’t approach programming with this aspect in mind. Normally, during development or architectural stage, things are always linear. We have plans like - do this after doing that, or method A should be called before calling method B.

This approach is not very flexible, and not very realistic

We should allow concurrency in our programs. Always think about decoupling and ordering dependencies. This helps us to gain flexibility and reduce any time-based dependencies in many areas of development.

- summary of Temporal Coupling, from The Pragmatic Programmer: From Journeyman to Master

Metaprogramming (Part 2)

Metadata-Driven Applications

Metadata can be used for configuring and driving the applications. Our goal is to create highly dynamic and adaptable programs. For this, we adopt a general rule: program for the general case, and put the specifics somewhere else—outside the compiled code base.

Put Abstractions in Code Details in Metadata

The benefits of this approach are:

1. Helps us to decouple our program, resulting in a flexible and adaptable program.
2. Helps us to create a robust, abstract design by deferring details out of the program.
3. We can customize our applications without recompiling it.
4. Metadata can be expressed in a manner that's much closer to the problem domain than a general-purpose programming language might be.
5. We can implement several different projects using the same application engine, but with different metadata.

The next important question is, when to configure?  Most of the applications read the configuration only during start up. In this case, most of the times, we have to restart the application for applying the configuration.  A more flexible approach is to write programs that can reload their configuration while they're running.


- summary of Metaprogramming, from The Pragmatic Programmer: From Journeyman to Master

Metaprogramming (Part 1)

We want to make our systems highly configurable. It includes not only colors or fonts, but also the choice of algorithms, database products, middle-ware technology and user interface style. These items should be integrated as configuration options, not through integration or engineering.

Configure, Don't Integrate

We can use metadata to describe configuration options. Metadata is data about data. Some examples are data dictionary and database schema. A schema contains data that describes fields (columns) in terms of names, storage lengths, and other attributes. Web browsers and many other applications use metadata for storing configuration options in files.

- summary of Metaprogramming, from The Pragmatic Programmer: From Journeyman to Master

Decoupling and the Law of Demeter (Part 2)

The Law of Demeter for Functions

The law of demeter for functions helps to reduce coupling between modules. The law states that any method of an object should call only methods belonging to:

• itself
• any parameters that were passed into the method
• any objects it created
• any directly held component objects

Writing shy code which obeys this law helps us to achieve our objective:

Minimize Coupling Between Modules

Using the Law of Demeter will make our code more adaptable and robust.


- summary of Decoupling and the Law of Demeter, from The Pragmatic Programmer: From Journeyman to Master

Decoupling and the Law of Demeter (Part 1)

Spies and revolutionaries are often organized into small groups called cells. They might know the people in the same cell, but not from other cells. This ensures that when one cell is discovered, details about other cells will remain protected. This principle can be applied to coding as well. We can organize our code into modules and limit the interactions between them. If one module got replaced or compromised, other modules should continue to work.

Minimize Coupling

Modules knowing each other is not as paranoid as spies or revolutionaries! But we should be careful about how many modules we interact with and how we came to interact with them. 

Imagine that we are building a house. We hire a General Contractor to get the work done. The contractor may or may not do the construction personally. He can hire a number of subcontractors, split the work and assign to them. As clients, we don’t need to interact with these subcontractors. All the headaches related to these subcontractors are isolated from the clients.

Similarly, while writing modules, instead of having one module which depends on many other classes, we can have a hierarchy of classes. In this case, each class need to be concerned about only one other class. This makes it easier when a change happens to some class. We need to modify only the class which uses this changed class and not the entire module. This also helps reduce the dependencies among classes.

Systems with many unnecessary dependencies are very hard to maintain, and they are highly unstable.

- summary of Decoupling and the Law of Demeter, from The Pragmatic Programmer: From Journeyman to Master

When You Can't Balance Resources

There are cases when the basic resource allocation pattern is not applicable. This usually happens in programs which use dynamic data structures. When there are top level structures and inner level structures, some resources are allocated to the top level and some are allocated to inner levels. If there are multiple levels of structures, the resource allocation is done for each level separately.

What happens when we deallocate the top level structure? We have three main options:

1. The top level structure is also responsible for deallocating the substructures. There substructures again recursively deallocates its substructures.
2. The top level structure is simply deallocated, thereby making all its substructures orphans
3. The top level structure refuses to deallocate if it contains any substructures.

The choice depends on each individual data structures and their circumstances. In languages like C, where data structures themselves are not active, we can write a module for each major structure that take care of standard allocation and deallocation.

Checking the Balance

It is always a good idea to build code that checks if the resources are freed properly. For most of the applications this means producing wrappers for each resources that keep track of allocations and deallocations.

At a lower, but no less useful level, you can invest in tools that check your running programs for memory leaks.


- summary of When You Can't Balance Resources, from The Pragmatic Programmer: from Journeyman to Master