How to Become a Web Developer. Part 3 Object Oriented Design

Before we move on to server side programming, there are a few Object Orientated Design Principles you should be aware of.

These principles are not the kind of thing you fully understand until you have spent some time practicing them. I am covering them now since most of the server side languages that are popular today (including JavaScript) have at least some OO features.

These principles are universal when dealing with an OO programming paradigm. For fully functional languages like Haskell, these will be less relevant.

For the other posts in this series on how to become a web developer, have a look here and here.

Buckle up and let's dive in.

Object Design: SOLID+D

Let's start with how you design your classes.

There are traditionally 5 core principles you should try and adhere to (I like to include a 6^th):

1. Single Responsibility (SRP)
2. Open/Close
3. Liskov’s Substitution
4. Interface Segregation
5. Dependency Inversion
6. Law of Demeter

Each of these principles is fairly complex to explain but are key to grasp if you want to become a web developer. Below, I have included a short summary with links to papers and articles that do a fantastic job of explaining the nuances.

If you struggle with these concepts, don’t lose heart.

Like I said before, these can take some time to fully grock especially when you are new to programming. If you would like more information, then go to resource for OOAD principles in this article by Uncle Bob.

This book also covers the topic in depth:

Single Responsibility (SRP)

A class should have one, and only one, reason to change.

If a class has more than one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

Open/Close

You should be able to extend a classes behavior, without modifying it.

When a single change to a program results in a cascade of changes to dependent modules, that program exhibits the undesirable attributes that we have come to associate with “bad” design. The program becomes fragile, rigid, unpredictable and unreusable. The open-closed principle attacks this in a very straightforward way.

It says that you should design modules that never change. When requirements change, you extend the behavior of such modules by adding new code, not by changing old code that already works.

Liskov’s Substitution

Derived classes must be substitutable for their base classes.

The importance of this principle becomes obvious when you consider the conse-
quences of violating it. If there is a function which does not conform to the LSP, then that function uses a pointer or reference to a base class, but must know about all the derivatives of that base class. Such a function violates the Open-Closed principle because it must be modified whenever a new derivative of the base class is created.

Interface Segregation

Make fine grained interfaces that are client specific.

This principle deals with the disadvantages of “fat” interfaces. Classes that have “fat” interfaces are classes whose interfaces are not cohesive. In other words, the interfaces of the class can be broken up into groups of member functions. Each group serves a different set of clients. Thus, some clients use one group of member functions, and other clients use the other groups.

The ISP acknowledges that there are objects that require non-cohesive interfaces; however it suggests that clients should not know about them as a single class. Instead, clients should know about abstract base classes that have cohesive interfaces. Some languages refer to these abstract base classes as “interfaces”, “protocols” or “signatures”.

Dependency Inversion

Depend on abstractions, not on concretions.

This principle deals with the direction of dependency flow in your design. High level modules should drive change in lower level modules. Not the other way around. If low level modules drive change into higher level modules a simple change cascades throughout your application. This is never a good thing.

Law of Demeter

Each unit should only talk to its friends; don’t talk to strangers.

The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents), in accordance with the principle of “information hiding”.

Packaging Principles

Next, we go one level higher and take a look at how you group your classes together into larger components. This will form the macro structure of your solution and will have an impact on reusability and easy of deployment.

The 2 most important factors when designing your packages are cohesion and coupling:

• Cohesion speaks to how closely related all the classes in a package are.
• Coupling deals with the dependency flow in your packages.

Package Cohesion

The first three package principles are about package cohesion, they tell us what to put inside packages.

Reuse-Release Equivalence Principle (REP)

The granule of reuse is the granule of release.

This principle helps us to decide which classes should be placed into a package. It states that classes that tend to be reused together belong in the same package. Classes are seldom reused in isolation. Generally reusable classes collaborate with other classes that are part of the reusable abstraction. The CRP states that these classes belong together in the same package.

Common-Reuse Principle (CRP)

Classes that change together are packaged together.

This principle helps us to decide which classes should be placed into a package. It states that classes that tend to be reused together belong in the same package. Classes are seldom reused in isolation. Generally reusable classes collaborate with other classes that are part of the reusable abstraction. The CRP states that these classes belong together in the same package.

Common-Closure Principle (CCP)

Classes that are used together are packaged together.

The CCP is an attempt to gather together in one place all the classes that are likely to change for the same reasons. If two classes are so tightly bound, either physically or conceptually, such that they almost always change together; then they belong in the same package. This minimizes the workload related to releasing, revalidating, and redistributing the software.

Package Coupling

The last three principles are about the couplings between packages, and talk about metrics that evaluate the package structure of a system.

Cyclic-Dependencies Principle (ADP)

The dependency graph of packages must have no cycles.

The dependencies in an application must be a Directed Acyclic Graph. In other words, there must be no cycles in your dependency structure. Most typed languages will detect this and raise an error but it’s good to be aware of why this may be a problem.

Stable-Dependencies Principle (SDP)

Depend in the direction of stability.

Any package that we expect to be volatile should not be depended upon by a package that is difficult to change! Otherwise, the volatile package will also be difficult to change. By conforming to the SDP, we ensure that modules that are designed to be instable (i.e., easy to change) are not depended upon by modules that are more stable (i.e. harder to change) than they are.

Stable-Abstractions Principle (SAP)

Abstractness increases with stability.

This principle sets up a relationship between stability and abstractness. It says that a stable package should also be abstract so that its stability does not prevent it from being extended. On the other hand, it says that an instable package should be concrete since its instability allows the concrete code within it to be easily changed.

Conclusion

These principles might seem very technical and can be a bit hard to grasp in the beginning. It’s well worth the effort to learn them as they are critical for any web developer who wants to progress past trivial applications.

Do you have a colleague who could benefit from this article? If so, please forward it on to them.

Good luck and please feel free to leave a comment below with any questions.

The post How to become a web developer. Part 3 Object Oriented Design appeared first on Aesthetic IO.