The Wizard Design Pattern

We all love wizards.... (Software wizards I mean). We are always happy to jump on those ''Next" buttons like we were dancing the funky chicken on our… well you get the point. So today we bring you your beloved wizard into your coding experience. Let's jump right into an example.
Say you want to design a ConservativePerson class.

   1: import java.util.List; 

   2: class ConservativePerson{ 

   3:  

   4:  

   5:     private boolean isVirgin; 

   6:     private boolean isMarried; 

   7:     private List<String> children; 

   8:  

   9:     ConservativePerson(boolean virgin, boolean married, List<String> children) { 

  10:         this.isVirgin = virgin; 

  11:         this.isMarried = married; 

  12:         this.children = children; 

  13:     } 

  14:  

  15:     public boolean isVirgin() { 

  16:         return isVirgin; 

  17:     } 

  18:     public boolean isMarried() { 

  19:         return isMarried; 

  20:     } 

  21:  

  22:     public List<String> getChildren() { 

  23:         return children; 

  24:     } 

  25: } 

As such it has some constrains.

• He must be married before he can be... well, not a virgin.
• He can't be a virgin before he can have children (as far as we know).

In the old days, which is basically all days until today..., you would probably define all kinds of modifiers methods for this class which will throw an exception in case of invariant invalidation such as NotMarriedException and VirginException. Not anymore.

Today we will do it by using the Wizard Design Pattern. We use a fluent interface style and utilize the power of a modern IDE to create a wizard-like feeling when building a ConservativePerson object. We know, we know, stop talking and show us the code... but before we will present the wizard code we will show you it usage so you will get a grasp of what we are talking about...

   1: public class Main { 

   2:     public static void main(String[] args) { 

   3:         ConservativePersonWizardBuilder wizard = new ConservativePersonWizardBuilder(); 

   4:         ConservativePerson singlePerson = wizard. 

   5:                 createConservativePerson(). 

   6:                 whichIsSingle(). 

   7:                 getObject(); 

   8:         ConservativePerson familyManPerson = wizard. 

   9:                 createConservativePerson(). 

  10:                 whichIsMarried(). 

  11:                 andNotVirgin(). 

  12:                 andHasChildNamed("Noa"). 

  13:                 anotherChildNamed("Guy"). 

  14:                 lastChildName("Alon"). 

  15:                 getObject(); 

  16:     } 

  17:  

  18: } 

Now, it may look just like an ordinarily fluent interface, but the cool thing here is that a method is available for calling only if the current object state allows it. This means you will not be able to call the method andNotVirgin if you haven't called the method whichIsMarried.
See the following set of screen shots:



and after we state he is married we can:



Here is the wizard code. I urge you to copy/paste it to your IDE and give it a try by building an object with it.

   1: import java.util.ArrayList; 

   2: import java.util.List; 

   3:  

   4: public class ConservativePersonWizardBuilder { 

   5:     private boolean isVirgin; 

   6:     private boolean isMarried; 

   7:     private List<String> children = new ArrayList<String>(); 

   8:     

   9:     public SetMarriedStep createConservativePerson(){ 

  10:         return new SetMarriedStep(); 

  11:     } 

  12:  

  13:     class SetMarriedStep { 

  14:         public SetVirginStep whichIsMarried(){ 

  15:             isMarried = true; 

  16:             return new SetVirginStep(); 

  17:         } 

  18:  

  19:         public FinalStep whichIsSingle(){ 

  20:             isMarried = false; 

  21:             return new FinalStep(); 

  22:         } 

  23:     } 

  24:  

  25:     class SetVirginStep { 

  26:         public AddChildrenStep andNotVirgin(){ 

  27:             isVirgin = false; 

  28:             return new AddChildrenStep(); 

  29:         } 

  30:         public FinalStep butStillAVirgin(){ 

  31:             isVirgin = true; 

  32:             return new FinalStep(); 

  33:         } 

  34:     } 

  35:  

  36:     class FinalStep { 

  37:         public ConservativePerson getObject(){ 

  38:             return new ConservativePerson(isVirgin, isMarried, children); 

  39:         } 

  40:     } 

  41:  

  42:     class AddChildrenStep { 

  43:         public AddChildrenStep andHasChildNamed(String childName) { 

  44:             children.add(childName); 

  45:             return new AddChildrenStep(); 

  46:         } 

  47:         public AddChildrenStep anotherChildNamed(String childName) { 

  48:             children.add(childName); 

  49:             return new AddChildrenStep(); 

  50:         } 

  51:         public FinalStep lastChildName(String childName){ 

  52:             children.add(childName); 

  53:             return new FinalStep(); 

  54:         } 

  55:     } 

  56: } 

As you can see the wizard consists of several steps. Each step is represented by a dedicated inner class. Each step reveals the legal available operations by its methods. Each method will then return a new step according to the change it has made. This way an attempt to create an illegal object will be detected at compile time instead of runtime.

This pattern is actually being used in our production code. One example that comes to mind is the MediaJob class. This class describes a manipulation on some media files. In order to submit a job to the system, one has to create a MediaJob object. The problem is that this object has many parameters that could be assigned with contradicting values that create an illegal object state. By using the Wizard pattern, one can easily build a legal job without the need to know the entire (and complicated…) set of constrains.

That is all for now. Hope you'll give it a try..... We plan to write a more formal description of it (GOF style) in the near future.

Intellij vs. Eclipse

Choosing the right IDE can make you or break you as a coder. Most developers would be lost without the comfort of their preferred IDE, which takes care of classpath, make files, command line arguments, etc. The problematic dependence on the IDE, while very beneficial, is off topic and a discussion for another post. We concentrate on 2 main platforms, Eclipse and Intellij Community Edition, comparing them, mainly in the Java SE context. Disclosure: Nadav uses Intellij on a regular basis, and Roi uses Eclipse.

Walking through history lane, Eclipse is around since 2001, while the real major release was Eclipse 3.0 in 2004. It began as an IBM project, but current members of the Eclipse Foundation range from Oracle to Google. Current release is Eclipse Indigo 3.7, and it is licensed under the Eclipse Public License. Intellij is part of the JetBrains, which was founded in 2000 as a private company. Intellij for Java was first released in 2001, and the Community Edition supports Java, Groovy and Scala, and its free and open source under the Apache 2.0 license.

We use Java as our main development language. Each developer chooses its own IDE. War between the IDE’s is waging around us, starting from our school days and University, and extends to our current workplace. While each side is certain in his righteousness, we believe there is no right or wrong answer, but rather choosing the right platform for your needs and challenges, taking into account the kind of programmer you are. We would like to share our own experience on when to use each. So here we go:

• Plugins: Eclipse marketplace offers 1,276 plugins, and the Intellij Plugin Repository offers 727 plugins. This difference is not to be taken lightly, since plugins for new technologies will usually be developed mainly for Eclipse (e.g. Android, Drools, Activiti, etc). Moreover, Eclipse is easier to extend. When working on a specific technology most chances are that if a plugin exists, it will be an Eclipse plugin.

• Multiple projects: This is an Eclipse winner for sure. It has the ability to open multiple projects in the same window, giving the coder control over dependencies and relations. Intellij has an option to open one project with multiple modules, but we found it to be cumbersome, and in times a little buggy. If you are going to use a lot of projects together and hate to switch windows, Eclipse is your choice.

• Multiple languages: We have stated that we will only examine the Intellij Community Edition that supports Java, Groovy and Scala. However, if you plan to create a Python server, combined with Ajax & Html, joint with a java web server, or any other exotic language combinations, than Eclipse is your choice.

• Code completion & inspection: While Eclipse has the ability to add plugins such as checkstyle, this one definitely goes for Intellij. The default code completion and assistance in Intellij is faster and better. If you are a rookie developer, Intellij can improve your code.

• Usability: Intellij user experience is much easier to grasp. The learning curve in Intellij is by far faster. It seems using Intellij makes developing easier and more natural. Dropdowns, code completion, quick view, project wizards, etc, are all possible both in Eclipse and Intellij, but the experience in Intellij is much more satisfying.

• Performance: The more plugins are installed on the IDE, the more heavy it is for your computer. However, saying that, Eclipse handles very large projects faster. Moreover, both of the IDE’s seems to be RAM junkies. Projects usually open faster in Eclipse, as Intellij indexes the entire project on startup, but while working on an existing project, Intellij works smoother. For example we have a huge SOAP project, which is impossible to work on with Intellij, so some of us even learn Eclipse just for that.

• Repository integration: Both of the IDE’s have SVN\GIT\etc plugins. No doubt Intellij’s plugin is more reliable, has better GUI and easier to use.

• GUI builder: We found that the built in Intellij GUI builder is more comfortable, and as mentioned above, usability wise its easier to learn, and more enjoyable to develop.

For a conclusion, a programmer should be able to find the right tool given a specific task. This means that one should be acquainted with both of the IDE’s, in order to face the challenge with the right tool.

Effective Unit Testing - Not All Code is Created Equal

Unit Testing is one of the most adopted methodologies for high quality code. Its contribution to a more stable, independent and documented code is well proven . Unit test code is considered and handled as an a integral part of your repository, and as such requires development and maintenance. However, developers often encounter a situation where the resources invested in unit tests where not as fruitful as one would expect. This leads us to wonder, as in any investment, where and how should resources be invested in unit tests?

Current metric used to assess the quality of unit testing utilize the notion of code coverage. Code coverage describes the effectiveness to which the source code of a program has been tested. In an ideal world every method we code will have a series of tests covering it’s code and validating it’s correctness. However, usually due to time limitations we either skip some tests or write poor quality ones. In such reality, while keeping in mind the amount of resources invested in unit testing development and maintenance, one must ask himself, given the available time, which code deserve testing the most? And from the existing tests, which tests are actually worth keeping and maintaining? We will try to answer those questions today.

We believe that not all code is created equal. There are certain code sections that are harder to test than others. Other code sections are more important than others. We suggest a few guidelines which will help determine in what code sections to invest in Unit Testing first, and maintaining as well:

1. Usages of code – when code is used frequently, it is important to unit test it.
2. Code dependencies – similar to (1), when other code is heavily dependent on the examined code, the more important it is to unit test it. On the other hand, when the examined code is greatly dependent on other code, it is harder to test and the chances to catch a fault is smaller.
3. I\O dependency – code which is dependent on I\O (DB, Networking, etc), is harder to test, as it requires creating mock objects which simulate the behavior of the I\O components. This mock objects require developing, maintenance and are vulnerable to bugs on their own. Moreover, writing mock objects that will simulate the exact behavior of any given I\O, such as faults is not trivial at all.
4. Multithreaded code –multithreaded code behavior is unexpected and as such harder to test.
5. Cyclomatic complexity – this metric is used to indicate the complexity of your source code. The higher the complexity, it is more important to test the code.
6. Code accessibility – this measure is related to the number of people that are acquainted with the source code in question. The bigger the accessibility is the less testing is needed, since problems will be identified and handled more rapidly.

Regarding the latter question presented above, we suggest a new approach for managing Unit Tests. This preliminary idea defiantly needs some polish, and we only present a rough outline.

After taking all the above into account, the real bother is maintaining the tests. We suggest thinking on a single unit test as a stock. We can keep track on each test unit, treating them as dynamic objects that have initial value that can change over time. According to the above points, we can give each test a preliminary value, indicating its importance. Note that most of the attributes above, can be determined automatically. The change in value over time is related to our profit from the test. Each time a test fails and catches a real bug, its value increases and each time you invest in fixing the test itself, while not catching any real bug in your business logic, its value decreases. Moreover, each time you need to change the code of a test, as a result of change in your business logic, its value stays the same.

The above model is not complete, as we only wanted to give a general idea on effective unit testing. There is the question of how each value for our suggested points is computed? how will the preliminary value for each test will then be determined? and how much should we increase/decrease over time? This questions can be answered, for example, by using machine learning techniques, but it is out of the scope of this post.