#implementationpatterns

[nedyaj-blog]

Implementation Patterns: Guard Clause and Exceptions

In most programming languages, a sequence of instructions are executed one by one. As such, it is important to clearly express the behavior of a program in order to make the code more understandable. In this next chapter of Implementation Patterns, Beck discusses several patterns to achieve this task, but we'll just be talking about the patterns that I found most interesting: guard clauses and exceptions.

Programmers generally think of a main flow of control for their programs in which processing starts here, and ends there. The computation has a linear path to follow; however there can be conditions and exceptions along the way. These little bumps on the "main flow" path should be expressed clearly, but they should not take the spotlight away from the main flow of your program. It's not to say that exceptions and conditions are unimportant, it's just that focusing on clearly expressing the main flow of the computation is much more valuable. In order to do so, it's best to use guard clauses and exceptions to express unexpected or error conditions.

Guard Clause

According to Beck, a guard clause is a way to express simple and local exceptional situations with purely local consequences by utilizing early returns. Let's take a look at this small snippet of code:

void initialize() { if(!isInitialized()) { ... } }

and compare it with:

void initialize() { if(isInitialized()) return; ... }

When looking at the first version, you immediately start looking for an else clause while you begin looking within the block of the if statement. This becomes a distraction while you are reading the body of the if statement. When compared to the second version, within the first two lines of the code it is clear that the receiver hasn't been initialized.

A guard clause is appropriate for expressing a situation in which one of the control flows is more important than the other. In the example above, it is clear that the important flow is what happens when the object is initialized. It keeps the focus of the program on the important flows and eliminates unnecessary distractions.

Exceptions

Beck states that exceptions are useful for expressing shifts in the flow that span levels of function invocation. While you may reasonably deal with a problem lower on the call stack that has occurred earlier, it is best to throw an exception at the point of discovery and catching it where it can be handled. In this way, the code is not cluttered with explicit checks for possible exceptional conditions that cannot be handled appropriately.

[nedyaj-blog]

Implementation Patterns: Eager vs Lazy Instantiation

Initialization is the process of putting variables into a known state before they are used. However, issues can arise depending on when the initialization occurs within the program. For example, if a particular variable is costly to initialize, it will degrade the performance of the system if it is initialized with declaration. In this case, it will be more beneficial to initialize this variable after it has come into existence. In Kent Beck's Implementation Patterns, Beck discusses two initialization patterns: eager and lazy instantiation.

Eager Instantiation

One flavor of initialization is to initialize the variable as soon as it is declared or when the object in which it lives in is created (declaration or constructor). An advantage of eager instantiation is that you can be assured that the variables are initialized before they are used. Another advantage of initializing variables within its declaration is that it makes it easier for readers to understand the actual type of the variable. Take a look at the simple example below.

class Library { List members = new ArrayList(); ... }

Had we initialized members somewhere else, we wouldn't have known that the actual type of the variable is List instead of its declared type of ArrayList. This may sound trivial as both types are Lists, but it is good to be able to easily find its actual type when it's close together to its initialization.

Lazy Instantiation

Eager instantiation works when we aren't concerned about the cost of computing a variable's state as soon as it has come into existence. When performance is compromised or you'd like to defer the cost because a variable may not even be used, it's better to utilize lazy instantiation. In cases like this, create a getter method and initialize the field when the getter is first called. Let's look at the example provided by Beck below.

Library.Collection getMembers() { if (members == null) members = new ArrayList(); return members; }

Lazy initialization used to be a more common technique; however with the advancement of technology, limitation in raw computing power is less of a common issue than it once was. This initialization pattern is still very important when computational power is a limited resource. A drawback to this kind of initialization is that the reader has to look at least two places to understand the implementation type of the field. This may not be a huge deal with smaller programs, but it can be a bit difficult to find within a large system.

Conclusion

There are use cases for both types of initialization patterns. If you are more concerned about the performance of the system and the cost that incurs when initializing objects upon declaration, stick to lazy instantiation. However, because limitation in computing power is less common nowadays than it was in the past, lazy instantiation is not as commonly used as it once was. In most cases, you'll see yourself using eager instantiation as it is easier to read and understand the implementation type of the variable or object.

[nedyaj-blog]

Implementation Patterns: Versioned Interfaces

In object-oriented programming, a class is like a blueprint for a house. It is important for communication because a class describes many specific things about how a particular object behaves and what it does. Because communication is one of the important values in programming, it's essential that we design classes that correctly express their relationships with one another. In Kent Beck's Implementation Patterns, Beck provides a list of class-level patterns to aid in the design of clean classes. In this post, we'll be discussing a pattern that I ended up having to use in my most recent project.

Versioned Interface

An interface is an abstract class without implementations. It specifies the signatures of related methods that classes which will implement the interface must have. It is a technique to group similar classes together and ensure that each class implements the same methods. So what happens if we have hundreds of classes that implement this interface and we want to add another feature or operation? It'd be incredibly time consuming to open up each individual class and modify them to add this feature. What we can do however, is declare a new interface that extends the original interface and add the new feature there. Any class that needs the new method can implement this new interface, and all classes that implement the parent interface will remain oblivious to the existence of this new interface. Let's take a look at this example below.

public interface Response { public byte[] getResponse(HashMap<String, String> serverRequest); public String getContentType(); public int getStatus(); }

This example is taken from a Java server that I had to write. Response is an interface that all server response classes implement. I use this interface to serve up responses to requests that are received by my server. As I was adding more responses, I noticed that I needed another operation to be able to return a HTTP response header and value with the content. None of the responses that I had previously written needed to implement this new feature, so instead of re-opening these classes and force them to implement a method that they do not need, I extended the interface and created a new interface like the one below.

public interface ResponseWithHeader extends Response { public String getHeaderName(); public String getHeaderValue(); }

With this new interface, I was able to retain the logic that I use to serve up responses and simply add a few lines of code to get the new type of responses up and running within my ResponseBuilder.

... stuff ... String requestURI = request.get("URI"); Response response = serverRoutes.get(requestURI); setContent(response.getResponse(request)); setStatus(response.getStatus()); setContentType(response.getContentType()); if (response instanceof ResponseWithHeader) { String headerName = ((ResponseWithHeader) response).getHeaderName(); String headerValue = ((ResponseWithHeader) response).getHeaderValue(); setHeader(headerName, headerValue); } ... more stuff ...

Existing instances of Response still work as before and instances of ResponseWithHeader work anywhere a Response is expected. To use this new operation, I had to write a conditional if-statement to check if the response is an instance of the new interface, and then downcast the object. While the usage of instanceof does reduce the flexibility of the code by tying it to specific classes, it may be justified because it enables the evolution of interfaces.

[nedyaj-blog]

Programming Values

In Kent Beck's book, Implementation Patterns, Beck states that there is no list of patterns that can cover every situation in programming. He claims that each pattern contains a bit of theory and that there are more pervasive forces at work in programming than are covered in individual patterns. These concerns have been divided into two types: values and principles.

Values

Values are the overarching theme and should dictate every decision ever made in programming. There exists three values: communication, simplicity, and flexibility.

Communication

Communication is possibly the most important value in programming. As mentioned in a previous post, we have the responsibility for communicating well with potential readers. If good code is clean code, then clean code should read well and be easy to understand. Because developers work in teams, it is crucial to think of others as we code. Think to yourself, "How would someone else see this?" when writing code. This gives yourself a fresh perspective and you'll feel as though you are thinking clearer because you think of others as you program.

There is also an economical aspect to good communication. Because the majority of software costs are incurred after the software has been deployed (maintenance phase), you can cut costs by taking some time to write code that is easy to read so that you don't have to spend more time reading existing code to add value to it.

Simplicity

Eliminating excess complexity allows those who are reading, using, and modifying programs to understand them much more easily. While some complexity is acceptable given the complex nature of the specific problem at hand, it is best to remove excess complexity that does not add much value to the software. Communication and simplicity go hand in hand. The simpler the design of the system, the easier it is to read and understand. The more you focus on communication, the easier it is to see the excess complexity in parts of the system. In other words, "Keep it simple, stupid."

Flexibility

As addressed in the discussion regarding communication, the bulk of the cost of software is incurred after it is first released. Not only should code be easy to read, it should also be easy to change. Often times though, flexibility can come at the cost of increased complexity. Beck includes an example of this case by discussing user configurable options. The options provide flexibility, but it adds the complexity of the need of a configuration file. This extra layer of complexity needs to be considered when deciding whether the importance of software flexibility outweighs simplicity.

Principles

Understanding principles can provide general motivation or explanation behind a pattern, and as a guide when coming across novel situations. Below is a list of principles behind implementation patterns.

Local Consequences

When designing a system, it is best to structure code so that any changes to a particular module will only have local consequences. Code that only affects its neighbors communicates well as it can be understood without having to understand the system as a whole.

Minimize Repetition

Minimizing repetition contributes to the principle of keeping consequences local, as changes to one copy of the code will require a change in more than one place. Duplicate code is not the only form of repetition though. According to Beck, parallel class hierarchies are also repetitive, which breaks the principle of local consequences. In order to eliminate duplication, a good method is to break the program into many small pieces as large pieces of logic tend to be made up of parts of other large pieces.

Logic and Data Together

Another principle that ties into local consequences is to keep logic and data together. By keeping these two entities near one another, changes will be kept local because changes in logic are often parallel to the changes in data.

Symmetry

Symmetry in code is where the same idea is expressed the same way everywhere it appears in the code.

Symmetry is also an important principle to uphold when programming. Identifying and expressing symmetry clearly makes code easier to read. As readers understand one half, it becomes easier to understand the other half if these two halves are symmetrical.

Declarative Expression

As another principle, declarative expression states that you should be able to read what the code is doing without having to understand the entire execution context. Here's an example below from the book using an old version of JUnit.

public static junit.framework.Test suite() { Test result = new TestSuite(); ... complicated stuff ... return result; }

What tests is this test suite running? At a quick glance, we wouldn't be able to tell unless we expand the "complicated stuff" section and dive deep into the code to fully understand what's going on. Beck states that JUnit 4 uses the principle of declarative expression to solve this issue, and includes the solution below.

@RunWith(Suite.class) @TestClasses({ SimpleTest.class, ComplicatedTest.class }) class AllTests { }

If it's known that tests are being aggregated using this method, then we just need to look at @TestClasses to understand which tests are expected to run in the suite. Not only does the TestClasses annotation provide flexibility for running tests than the code produced from the older version of JUnit, it makes the code much easier to read.

Rate of Change

The final principle is to put logic or data that changes at the same rate together and separate those that change at different rates. Let's look at this code snippet below.

setAmount(int value, String currency) { this.value = value; this.currency = currency; }

Hypothetically, if a financial instrument can have its value and currency change together, it would be better to join the two fields together and express these entities as a helper object.

setAmount(int value, String currency) { this.value = new Money(value, currency); }

Which can then be further reduced as:

setAmount(Money value) { this.value = value; }

The rate of change principle is an application of the symmetry principle; however it is a form of temporal symmetry as these two fields change at the same time. Expressing this symmetry by making a helper Money object communicates the relationship of these fields to readers, and it can help prevent duplication and aid in consequence localization later down the road.

Conclusion

The values provide motivation for patterns while the principles aid in the translation of these values. This post has introduced the theoretical foundations of the implementation patterns that will be discussed in future posts. Stay tuned!