SOLID: principles with an acronym

SOLID is a set of five principles for object oriented program design. The principles are carefully selected to result in a cool acronym.

Single Responsibility Principle

Every class should have a single responsibility. Many have realized this. One put a name on it.

Open Closed Principle

Classes should be open for extension but closed for modification. Originally this meant that new functionality should be put in new classes that inherit from older classes. However, since this is likely to cause a mess the principle was redefined. It now refers to some sort of design pattern involving abstract classes.

Liskov Substitution Principle

If you create a derived class from a base class the derived class should be able to stand in for the base class in all existing code. This means that if you create a car that teleports to the moon when you turn left you probably shouldn’t go around calling it a car. This principle is always explained by giving examples of where it isn’t applied.

Interface Segregation Principle

Clients shouldn’t have to depend on interfaces they don’t use. This is almost the same as the single responsibility principle but it refers to interfaces instead of classes. If you are creative it is possible to violate one but not the other.

Dependency Inversion Principle

High-level modules should not depend on low-level modules, both should depend on abstractions. The ubiquitous example of this is Dependency Injection where you pass a dependency to a dependent module instead of letting the module create it itself. When taken to its extreme you get an IoC Container.

E-mail address validation ad nauseam

Validating e-mail addresses is kind of a bike shed problem. If you search for a solution on the Internet you will find endless amounts of regular expressions and discussions. For example: [1] [2] [3] [4] [5] [6] [7] [8] [9]

There are three reasons I can think of for why we want to validate an e-mail address. We want to catch users who:

  1. Input malicious data
  2. Don’t want to give us their real e-mail address
  3. Make mistakes

E-mail addresses falls under the same category as all other user inputted data. You cannot trust it. You should check whether your SMTP client will handle it properly or if you need to sanitize the input beforehand.

If we have users who doesn’t want to give us their real e-mail address we should consider whether to require an e-mail address at all. However, if we do need it the only way we can be sure is to send an e-mail to the user with a unique verification URL that they can visit.

Sending verification e-mails is also the only way to make sure users haven’t made mistakes when they enter their e-mail address. Since it is possible to mistype an e-mail address in such a way that the result is a valid e-mail address. For example, if you mistype johan@example.com as john@example.com it is still valid even if it is wrong.

Finally we have the scenario where a user mistypes his e-mail address in such a way that the result is not a valid e-mail address. This is the only situation where it is helpful to validate that the string a user has entered is a valid e-mail address.

This simple problem can easily take up way too much of your time. There will always be a tradeoff between accepting invalid e-mail addresses and rejecting valid e-mail addresses. Complex regular expressions are hard to debug. Using proper libraries to parse the address is better but may not be available both client and server side.

I suggest doing something simple that takes little time to implement, little time to debug, accepts all valid e-mail addresses and still rejects the input if the user misunderstands and puts in his postal code or shoe size. I suggest this:

if (email.indexOf("@") != -1)

And the bike shed should be purple.