Subscribe to my email list now at http://jauyeung.net/subscribe/

Follow me on Twitter at https://twitter.com/AuMayeung

Many more articles at https://medium.com/@hohanga

Even more articles at http://thewebdev.info/

To make our code robust and maintainable, we got to make our code flexible so that our code can easily be changed without breaking things.

In this article, we’ll look at how to keep our code flexible with a few principles.

Decoupling and the Law of Demeter

Our code should be shy. They shouldn’t reveal ourselves to others and they should interact with the other parts too much.

We can divide our code into cells to make sure that they’re mostly isolated from each other.

Minimize Coupling

Modules that know too much about each other are going to be a problem. We don’t want duplicate interaction and we don’t want tight coupling.

Traversing relationships between objects can easily lead to a combinatorial explosion of dependency relationships if we just let any module interact with any other module.

Therefore, we’ve to use the Law of Demeter to design our methods and functions.

The Law of Demeter attempts to minimize coupling between modules in any given program.

It prevents us from reaching into deep implementations of an object to interact with them directly.

A number of functions directly invoked by methods of the class are more prone to error than classes that call a smaller number of methods from another class.

Therefore, we have to write a code where there’s one method that delegates the calling of the underlying methods to minimize the number of methods that we need to call.

This means that we have to write wrapper methods that calls other methods that shouldn’t be calling in our code.

However, this may be too slow for some situations. But this should be rare in today’s world since computed resources are adequate for most applications.

Therefore, we shouldn’t have to concern ourselves with the details of every function by referencing them everywhere.

Configure Rather Than Integrate

We should have metadata that should tell us how our app should run in different environments.

This may come in the form of a database or a configuration file or something else that isn’t part of the program itself.

This way, we don’t have to hard code anything in our code to get them running correctly in different environments.

We want to be able to drive more of our app from external metadata rather than putting them all in our code.

This allows us to decouple our design to make our code more flexible and adaptable.

It forces our program to have a more robust, abstract design by deferring the details of the program.

If they’re outside the program, then we can change our program without compiling it.

Metadata can also be expressed in a manner that’s closer to the problem domain rather than a general-purpose programming language.

This can be achieved with our own language used for configuring our program if necessary.

It might even be possible that we just use the same code to build different programs but with different metadata.

Business Logic

Since business policies are more likely to change, we probably want to move them outside our code so that instead of changing the code, we can just change the configuration to adjust the business rules.

We may want to encode them in some kind of rule-based system embedded within our program.

Then we can configure our program instead of changing our code to change business logic.

Configuration Should Be Stored in Plain Text

Plain text is much portable and easy to deal with than binary files, so we should store our configuration in plain text so that we don’t have to deal with binary files.

We can just open a plain text file change them right away.

On the other hand, we probably special programs to change binary files, so it’s much harder to deal with binary files.

Cooperative Configuration

We may want to adapt our software to handle different versions of a configuration. This way, it’s even more adaptable to new requirements that come up at any time.

We can go back and forward with our configuration if we want them to go back and forth.

Conclusion

We should make our app by making it configurable by reading the configuration from outside our app.

The configuration can be stored in a database, a text file, or some other plain text resource outside our app.

The most important thing is that we’ve to read them from outside our app.