SOLID Object Oriented Principles And CSS: Part 2

Posted: 01 Apr 2013 05:30 AM PDT

How should you define the abstraction in a class? What should the class do? What responsibilities should it have? When you want to add something new to the class, should you modify it or extend it? These are some of the questions SOLID principles attempt to answer.

Last week I started to look at the five SOLID object oriented principles and how we might apply them to designing websites. So far we talked about the single responsibility principle and also the open/closed principle.

We still have three principles left to cover.

Scrabble tiles spelling the words solid state

The 5 SOLID Principles

As a reminder here’s a brief definition of all five SOLID principles.

Single Responsibility Principle — objects should have only a single encapsulated responsibility
Open/Closed Principle — objects should be open for extension, but closed for modification
Liskov Substitution Principle — objects should be replaceable with instances of their subtypes without introducing problems
Interface Segregation Principle — many client specific interfaces are better than one general purpose interface
Dependency Inversion Principle — objects should depend on abstractions and not concretions

As a further reminder about the first two principles here’s the gist.

Object oriented concepts have further convinced me that a modular approach to css development is a good idea

The single responsibility principle suggests we shouldn’t include properties of more than a single type in any class. For example instead of a single selector defining values for both type and color, we’d create multiple classes, one with type properties and another with color properties. The net result is more specific classes, each doing fewer things.

Once these base classes are set up other code in our project is going to rely on them. The open/closed principle suggests that if we need to add something to our base classes we should do so by extending the classes and not by modifying them as the latter could break dependencies.

With that short review behind us, let’s get to the rest of the principles.

Liskov Substitution Principle

The Liskov substitution principle tells us that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. In other words if a program expects a shape, you should be able to substitute the more specific rectangle without problem.

The idea we can take from this is that classes that extend a base class shouldn’t have a different behavior than the base class they extend.

If our base class follows the single responsibility principle and defines values for properties of type, then subclasses of it should also define only values for type properties. If the base class affects colors, then any class meant to extend it should also only affect colors.

If we swap classes on an element, everywhere type or color was covered by the first class is now covered by the second. Since subclasses in css usually don’t overwrite everything in the base class, we might instead suggest that adding a subclass to an element with our base class doesn’t cause conflicts.

The Liskov substitution principle might also suggest that modifier classes should probably be careful around anything layout related as layout changes are the most likely to cause a significant break.

Interface Segregation Principle

The idea with the interface segregation principle is that no element should be forced to implement an interface it doesn’t use. Better would be to use several more specific interfaces than one general purpose interface.

Say you have a div that’s going to enclose some content inside a border, but isn’t meant to get a background color different from its container. You wouldn’t want to use a class that also includes a background color even if it’s the same as the one on the parent, because you now force any html that gets the class to depend on it for something it isn’t using.

If the base class is allowed to be more general, it gets reused more so as not to repeat code. The problem is that it couples many elements together that should remain independent. Changing the background color affects them all even if only some should change.

It’s better to have multiple and specific base classes than one all encompassing generic one. Here we’d have one class defining borders and another defining backgrounds. Again if we follow SRP we should be ok here.

If you find you’re constantly redefining a lot of properties in sub classes then you might have too generic an abstraction in the base class and you’d be better with several base classes, each with more specific abstractions.

More specific and smaller classes will help reduce coupling, increase cohesion, and generally lead to more maintainable sites.

Dependency Inversion Principle

The dependency inversion principle is stated in two ways, though each essentially says the same thing. The idea is to depend more on abstractions than on concrete implementations.

High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend upon details. Details should depend upon abstractions.

This dependency inversion principle is about reducing the dependence of modules on one another. It’s about decoupling.

In the context of html and css, parent containers shouldn’t care how their children are styled and children shouldn’t care how their parents are styled, as long as neither breaks the other. We should be able to swap out the styles of the child without it affecting the parent and vice versa.

Both parent and child should depend on abstractions, which for us are classes. Descendent selectors therefore are a sign you might not be adhering to this principle, since descendent selectors add dependency between parent and child. Instead a new abstraction might be called for. Another class is preferable to a descendent selector.

As soon as I came across this principle it brought to mind Andy Hume’s presentation CSS for Grownups. One of the examples Andy walks through in the presentation involves changing hx selectors to classes.

Starting with the following css on hx elements.

1  2  3

h1 {font-size: 3em;}  h2 {font-size: 2.3em;}  h3 {font-size: 2.1em;}

The selectors are first changed to classes named after the hx tags.

1  2  3

.h1 {font-size: 3em;}  .h2 {font-size: 2.3em;}  .h3 {font-size: 2.1em;}

The class names are then changed to better describe what’s being styled.

1  2  3

.h-headline {font-size: 3em;}  .h-subhead {font-size: 2.3em;}  .h-byline {font-size: 2.1em;}

The original selectors rely on specific html as they are html element selectors. Changing them to classes removes this dependence. The final renaming of classes adds semantics for what each class is meant to style.

Summary

Please accept my usual disclaimer and apology if I’ve misinterpreted these principles in any way or if I’m suggesting they be applied to html and css in a way that doesn’t make sense. Again this is all a learning experience for me and I won’t be surprised to have gotten a few things wrong.

Also please don’t take anything here as me suggesting css or html are object oriented languages. They clearly aren’t, but how we use them to design websites might be able to take a few lessons from object oriented design.

Last year when I looked at development methods like OOCSS, SMACSS, and DRY CSS, it convinced me that a modular approach to development was a good idea worth pursuing. However, I’ve found the ideas challenging to put into practice as I often fall back on old habits.

This recent look at object oriented concepts has mainly been to help me better understand how I might incorporate modularity into my code.

As I mentioned last week, what I’m taking away most from these SOLID principles is that more classes are probably better than less and that those classes should generally be more specific about what they do. The danger is falling prey to classitis, though the more I look at these concepts, the less I’m convinced it’s the problem we used to think.

The post SOLID Object Oriented Principles And CSS: Part 2 appeared first on Vanseo Design.