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

How to Balance Resources?

Most of the time, the resource usage in a system follows a specific pattern: we allocate resources, use them and then deallocate it. But many developers have no consistent plan for dealing with resource allocation. So, here is a simple tip:

Finish What You Start…

This means that the routine or object which allocate the resources is also responsible for deallocating it.

Nested Allocation

When the routines require more than one resource, consider the following two suggestions:

1. Deallocate resources in the opposite order in which we allocate them. If one resource contains reference to another, this will ensure that no orphaned resources are there in the system.
2. When we allocate the same set of resources at different places, always allocate them in the same order. This will reduce the possibility of deadlocks happening in the system.

Objects and Exceptions

Classes can be used for allocating and deallocating resources. We can encapsulate resources in a class. When we need a particular resource type, instantiate an object of that class. When an object is created, the constructor allocates the resources. When the object goes out of scope, or is reclaimed by the garbage collector, the object's destructor then deallocates the wrapped resource.

This approach is particularly useful while working with languages like C++.



- summary of How to Balance Resources, from The Pragmatic Programmer: from Journeyman to Master

When to use Exceptions?

Checking for errors at every part may lead to developing ugly code. That is where exceptions come into handy. But the problem with exception is, we need to have a clear idea of when to use them. Exceptions should be reserved only for unexpected events.

For example, consider this scenario. If our code is trying to open a file for reading and that file does not exist, should we raise an exception? It depends. If the file should have been there, but we cannot find them, then it is exceptional. But imagine that we have only the filename. We don’t know where exactly the file is and we cannot find them, then an error return will be more appropriate.

Programs that use exceptions as a part of their normal processing suffer from readability and maintainability problems. These programs break encapsulation as their methods and their callers are tightly coupled via exception handling.

Use Exceptions for Exceptional Problems



- summary of When to use Exceptions, from The Pragmatic Programmer: from Journeyman to Master

The Art of Simplicity (Part 2)

Most of the time, we never realize why some concepts are simple until we think about them. Just consider this example. Have you ever wondered why manholes are round in shape? We could have made them in many other shapes, say squares or real artistic ones.

Not many people had an answer when Venkat asked this question to the audience. For shapes other than round, there is a greater chance for its lid to fall into the hole. But with a round lid, we don’t face this problem. It can also be easily moved by rolling. Also, at the end of a long tiring day, the workman doesn't have to worry in which direction the lid has to be placed to close the hole properly. See how a very simple design helped in solving many issues that could have happened.

Have you ever given a thought why Mona Lisa is considered to be a masterpiece? Along with the fact that it was painted by the famous artist, Leonardo Da Vinci, it is simplicity that always attracts people towards it.

The essence of this keynote was this: Never complicate things too much.

He concluded the session with a very nice story based on Richard Feynman’s quote...

• • • 

Once, I was giving lectures to a bunch of students in the college. I was teaching the same stuff from past one decade. But, for the first time, something strange happened. All the students had nothing to say, after an hour long lecture , other than-

“Sir, we didn't understand anything!”

I was puzzled. I didn't know what had happened. I went back home. I kept  thinking and thinking about it. Then, I went back to read the same topic.

Slowly and surprisingly, I started understanding better. I uncovered many aspects and by the end of  that night, I got a clear picture about the entire concept.

Next day, I went to the same class and started with the same lecture, but with a new insight. Within five to ten minutes, I could make out that every student understood the concept clearly. All students were happy and they exclaimed-

“Sir, why couldn't we understand this yesterday? It is really very easy. ”

“It is simple. I hadn't really understood what I was teaching till yesterday. But now I know.”

• • • 

- summary of the keynote, The Art of Simplicity, by Dr. Venkat Subramaniam (Agile Kerala 2013)


Thanks to +Vaishnavi M K, +Arun Prakash and +Rohit Kumar for your suggestions and proofreading.. :-)