Jan Willem Tulp’s blog

Last week 2 colleagues of mine and myself gave a Scala workshop at Logica. One of the participants was asking whether getDate was a function or not. His question led to an email discussion today about what functions are, and how they relate to the Command Query Seperation (CQS) principle. The definitions coined in Eric Evans book about Domain Driven Design were helpful in defining the definitions.

After several exchanging several emails, we finally came to the following definitions:

• Query Functions: functions that retrieve information about the system. They are not pure functions, because applying these kinds of functions to its arguments may result in different values. GetDate() would be a Query Function, because everytime it is applied, a different value is returned.
• Command Functions: functions that alter the state of the system. They should not return a value (void in Java, or Unit in Scala). setName(String name) in Java would be example of a Command Function. Command functions therefore have side-effects.
• Pure Functions: functions that always return the exact same value for the exact same input. These are mathematical functions and don’t have side-effects. In Scala the following function is a Pure Function: def inc(x: Int) : Int = x + 1. For the input 4, this function will always return 5, no matter how many times you invoke it, and it doesn’t change the state of the system.

  What’s your opinion about these definitions?

  • 

Most Java developers know static code analysers like Checkstyle, Findbugs, or FXCop for the .Netters amongst us. And these tools are extremely helpful for pointing out the spots in your code that may need some improvement.

However, people must be motived to use such tools, and in real-life this is not always the case. After all, quite often people are not really interested in code quality. Especially since for most non-programmers code quality is something that happens ‘behind the scenes’. “We will worry about code quality when we have time for it… now we’ve just got to get our app up and running, right?”. Wrong!

Quality matters, it will make you a happier programmer both in the short run and in the long run. You will spend less time working on high quality code than on low quality code. It makes your application more durable. Software that lasts, that is easy to understand, flexible to use. But not everybody has this high quality bling-bling mindset. So, how do you motivate people to care about quality?

The answer is: let emotion kick in!

The lessons that can be learned from good presentations, enjoyable movies, and successful marketing strategies is that emotion makes people care. Remember your greatest movie. Isn’t it true that you can really identify with the main characters? Didn’t you forget the time when you were watching that great presentation? Read for example Made To Stick to learn about 6 elements of why some ideas survive and others die.

So, how to make code quality emotional? Should we all be crying? Laughing? Perhaps… but there are more options…

One of the things that works extremely well on the project I am currently working on is using competition. We use Hudson as our continuous integration server. Hudson allows you to use plugins to enhance the capabilities of Hudson. One of these plugins we use is the “Continuous Integration Game plugin“. This plugin gives you positive scores for successful builds, passing unit tests, fixing problems, etc., and it awards you negative points for breaking the build, failing unit tests, introducing warnings etc.

Since we have been using this plugin all team members want to win! They want to get the highest scores, so everybody is looking for opportunities to improve the code, to fix that warning before checking in, or get rid of that duplicate code. And of course, getting the highest score may seem to be the goal for some people, at least a very positive side-effect of this emotional involvement is that code quality does actually get better and better! It is also very good for the team spirit, believe me, lots of laughs!! And you may be wondering, how is this emotional? Well, since all team members get personally involved and are praised personally for high scores, people are emotionally involved.

So my advice: try to use some emotional aspects like a competition in your team so that people really do get motivated to work for example on quality. And even though people may be far more interested in the score, you still have the side-effects of lots of fun and producing high code quality in your team.

Every now and then I run into code where use of abstract classes are not always as optimal as can be. The thing at hand here is reuse of common functionality. There are at least two common ways to reuse common functionality:

1. calling methods in an abstract superclass
2. calling methods that are delegated to some other class (not a superclass)

Even though both options may have the same final result, I believe that one option is better suited for some situations, and the other for other situations. Notice that when you are calling methods in an abstract superclass, the direction is up: from the subclass to the superclass. In many cases the subclass does the heavy work, and reuses some common functionality from the superclass.

Now the power of abstract super classes is to use the Template Method design pattern. Instead of doing the heavy work in subclasses, you do the heavy work in the abstract class itself, you define some abstract methods that must be implemented by subclasses. These abstract methods are the specifics that differ for each subclass. This way, the direction is more or less down: from the abstract class you want to get something from a subclass that is specific for this subclass, even though the abstract doesn’t have to be aware of the exact subclass. The subclass just has to comply with the signature of the abstract methods defined in the abstract class.

When you just need some reusable functionality, I prefer using delegation instead of using an abstract class. This way the classes become more loosely-coupled, and the class with the delegated functionality can be used by more classes than just a subclass of some abstract class.

So, recap:

• let abstract classes do the heavy work, and have subclasses implement specifics that will be used by an abstract class
• delegate common behavior to a separate class if you just want to reuse some functionality

Tip: a ‘code-smell’ that may indicate that you’d better use delegation instead of an abstract class: if your abstract class does not contain any abstract methods, your abstract class is probably only there so that subclasses can reuse its functionality. In that case: use delegation!

One of the recurring patterns I find myself doing that successfully help in creating flexible component based application, is using technology as a driver for my component subdivisions. I usually try to create a domain model component that is completely technology agnostic. By technology agnostic I mean that my domain model should not know anything about HTTP, Web Services, LDAP, Databases, HTML, etc. It should be just an implementation of the business domain (only POJO’s or POCO’s). And usually I end up with a lot of interfaces and abstract classes in my domain model, so that components that are technology-aware are able to implement these interfaces. The important thing here is that the domain component is unaware of any technology or any of its implementors.

Then I have some technology aware components that implement the interfaces of my domain model. So for instance, I have an LDAP component that implements some interface of my domain model, using LDAP technology to fulfill it’s goals. This way the implementation of my domain becomes swappable, so that I am free to replace this component with another implementation, for instance with a SQL implementation. The power of this approach is that my domain model contains the business logic of my application, and requires some information or processing from it’s implementors, but it is unaware ‘how’ this is done. This will give you enormous freedom and flexibility.

Then usually I need final component that wires up everything together. This final component is aware of both the domain model and its implementors. This final component is responsible for wiring up the domain model with the correct implementations. A dependency injection framework could be used for this, or just hard-coding the wiring my also be an option (compile-time validation of your configuration may be a benefit here).

Another benefit of this approach is that you are creating a durable application. I have seen numerous situations where software applications are rebuilt from scratch because the legacy application is to complex to modify, extend or improve. So quite often the decision is made that it is cheaper to rebuild it than continuing working on the current application.

By creating the right dependencies, the right modules or components, you create durable software. Although the there will probably be changes in the business domain through time, in general you business domain can now outlive the implementations it uses. Upgrading to a new technology that is incompatible with the current technology you’re using for a certain implementation now only means creating a new implementation component, re-wiring the application with the new component, and everything keeps working. No need to trash the entire application.

The important principles to keep in mind:

• create technology agnostig domain model components
• create technology aware components that implement implement the domain
• use a single component that wires up your entire application
• think of composing your application from small components instead of one big moloch that does it all, so: composition