Forward Thinking

In continuation of my latest post regarding easily maintainable systems, I will start by writing about the benefits of Functional Design.

A functional design assures that each modular part of a computer program has only one responsibility and performs that responsibility with the minimum of side effects on other parts. Functionally-designed modules tend to have low coupling as concrete side-effect and more importantly, they scale much better than other types of designs.

The advantage for implementation is that if a software module has a single purpose, it will be simpler, and therefore easier and less expensive, to design and implement.
Systems with functionally-designed parts are easier to modify because each part does only what it claims to do.

Since maintenance is more than 3/4 of a successful system’s life, this feature is a crucial advantage. It also makes the system easier to understand and document, which simplifies training. The result is that the practical lifetime of a functional system is longer.

In a system of programs, a functional module will be easier to reuse because it is less likely to have side effects that appear in other parts of the system.

The Standard way to assure functional design is to review the description of a module. If the description includes conjunctions such as “and” or “or”, then the design has more than one responsibility, and is therefore likely to have side effects. The responsibilities need to be divided into several modules in order to achieve a functional design.

To perform Functional Design is quite easy, you can start by defining packages/namespaces based on Use Cases as can be illustrated by the following package definition:

com.hello.usermanagement.createUser

The package above would then contain all the classes which makes up the concrete use case implementation. In the case of a Flex application it would contain at least the Command and Event, but depending of the lines drawn in architecture – possibly the forms and UI objects as well.

This should be seen in contrast to having the Command in a namespace called Commands and the Event in a namespace called Events.

Functional Design has one limitation, and that is that you need an underlying set of baseclasses which implement all your Boilerplate code and thus faciliate that your concrete namespaces dont need to be to highly coupled to other parts of the system on the same level.

A frequent question is why we as developers prefer to make quality code and why we hate to hack together a system in order to meet a business objective, typically a unreasonable deadline or an unreasonable amount of time allocated to a project.

The answers is pretty simple, us developers spend apr. 3/4 of our working life maintaining systems – not defining them.
This is the reason why quality in application design becomes desirable at the cost of immediate productivity.

I will address this issue in a series of blogposts where I try to define what I consider to be the constitution of a well implemented system design and what defines an easily mantainable system…

A frequent question is when should I use a mock object framework ?
However, if you have to ask “when”, the answer is probably “not now”. I feel that mock object frameworks are something you have to evolve into.

First, we can talk about mocks in general. Some people have a misconception that mock objects are only useful if you need to simulate interaction with a resource that is difficult to use in unit tests – like an object that communicates with an SMTP server. This isn’t true.

* The real object has nondeterministic behavior
* The real object is difficult to setup
* The real object has behavior that is hard to trigger
* The real object is slow
* The real object is a user interface
* The real object uses a call back
* The real object does not yet exist

If we were to step back and generalize this list, we’d say test doubles are useful when you want to isolate code under test. Isolation is good. Let’s say we are writing tests for a business component. We wouldn’t want the tests to fail when someone checked in bad code for an auditing service the business component uses. We only want the test to fail when something is wrong with the business component itself. Providing a mock auditing service allows us to isolate the business component and control any stimuli the component may pick up from its auditing service. When you start feeling the pain of writing numerous test doubles by hand, you’ll know you need a mock object framework.

Mocks aren’t just about isolation, however. Mocks can play an important role at any time if employed correctly. Mocks can be powerful technique for identifying types in a system based on the roles that objects play … In particular, we now understand that the most important benefit of Mock Objects is what we originally called interface discovery.

Using a mock object framework allows a continuous, top-down design of software. But Aren’t Mock Object Frameworks Complex?

This is another question I’ve been asked recently. Mock object frameworks are actually rather simple and expose a small API. There is complexity, though, just not in the framework itself. As I said earlier, I think there is a path you can follow where you evolve into using mock object frameworks. The typical project team using a mock object framework is experienced with inversion of control containers. Trying to get up to speed on all these topics at once can be overwhelming.

There is also some complexity in using mocks effectively. In Mocks and the Dangers of Overspecified Software, Ian Cooper says:

“When you change the implementation of a method late in the implementation process, mocks can break because you now make additional or different calls to the dependent component that is being mocked. … The mocks began to make our software more resistant to change, more sluggish, and this increased the cost to refactoring. As change becomes more expensive, we risked becoming resistant to making it, and we risk starting to build technical debt. A couple of times the tests broke, as developers changed the domain, or changed how we were doing persistence, without changing the test first, because they were frustrated at how it slowed their development. The mocks became an impedance to progress.”

Mock object frameworks make interaction based testing easy, but can also lead to the problems Ian outlines. Here a couple more reads on this topic:

* Guidelines to Using Interaction Based Testing
* Why Mock Frameworks Suck

In summary – mock object frameworks aren’t for everyone. You’ll know when you need one!