Optionally the best

Lets talk for a while about a feature in Java 8 that I am really happy exists. Its called “Optional” and I think it is a massive step in the right direction. So what does it do?

Essentially you can mark any variable as “Optional”. So instead of:

Pet getPet();

You can have:

Optional<Pet> getPet();

In this example, people can have 0 or 1 pets. Under the first code, what do you return if the person has no pet? One normal answer would be: “A Null Pointer”. The problem is that the line has no method of describing that a Null is a possible return value. Therefore a non-cautious caller could get a Null pointer exception. I am sure at this point all of the lovers of defensive programming will jump up and say “Well you should always check for Nulls!”. The problem with this is that it leads to many many checks that in the normal course of things are just not needed. Also, nothing from the function prototype forces you to check.

A second answer could be “well maybe it should throw a ‘PersonOwnsNoPet’ exception”. In my eyes this is a corruption of what an exception is. The normal flow of a program should be without exceptions, and exceptions should be used to catch when things have gone wrong. No one in their right mind would do the following:

ArrayList<String> someArray= new ArrayList<String;
....
try{
   int i = 0;
   while(true){
      System.out.Println(someArray.get(i));
      i++;
   }
} catch (ArrayIndexOutOfBoundsException e){
  //do nothing
}

Because it is using the exception to handle the normal flow of data (in this case that you have printed the whole array). So therefore having a ‘PersonOwnsNoPet’ exception seems foolish.

However, one look at the line:

Optional<Pet> getPet();

Tells you have this person might have a pet. More importantly it forces the caller to deal with the case that they do not. This can only lead to better quality programs.

With optional the following becomes possible:

Optional<Pet> personsPet = person.getPet();
System.out.println(personsPet.orElse("No pet"));

“orElse” returns the value in the Optional, or the value supplied. Therefore in this example this will either print the pet’s “toString” method or the string “No pet”.

Advertisements
Posted in Uncategorized | Leave a comment

It’s not what you know

A question that sometimes get asked, but never really answered is “which programming language should I learn?”. I’ve heard all sorts of answers to this, range from “Java” (It’s widely used) to “C++” (you really understand what is going on under the hood!) and “Python” (It’s beginner friendly.)

I’m going to make a bold statement here. It does not matter. If you want to learn to program, just pick a language that sounds cool to you go and for it. If you have a book on Visual Basic and want to start there, brilliant!

What is far more important that which languages you know is that you understand the concepts of whats going on. The basic principles are always the same. If you have to do something a number of times, then it is likely that you will need a loop. If you need to choose between two outcomes, then it is likely you need an “If” statement. Understanding the concepts behind what is going on if far far far more important that being about to recite every keyword in a language.

OK OK, there are some languages that don’t make for ideal learning (lolcode anyone?), but even in this mad syntax you will find the same basic concepts.

If you can understand the concepts of:

  • Sequence
  • Selection
  • Iteration

Then more complex things will become much easier. I may do additional blogs on these concepts at a later date.

Incidentally, the three languages I mentioned at the start of this post all have their downsides: Java is obnoxiously object orientated (which is not something you want to start learning until you understand the basic concepts), it is possible to get into a massive mess with C++ and python has an odd way of handling private member variables on classes.

Posted in Uncategorized | Leave a comment

Mutable vs Immutable

Before we begin, all of the examples that I will use in this post will be Java based, but this is a concept of object orientation and can be applied to any such language.

What is meant by a mutable object? Simply put it is any object that can have it’s state changed. An immutable object is one that can not. The classic example in Java is that Strings are immutable. So once you have something like:

String test = "Testing String";

Then the value of “test” can not be changed. I know what you are thinking right now. It’s something along the lines of “But Tech – Lobster, what about if I write something like:

String test = "Testing String";
test = "Another String";

Its very important to know what is happening here. You are not changing the value of the first object, rather two string objects are created and the variable “test” moves to reference the second one. The first string, with the value of “Testing String” will be collected by the garbage collector in good time.

An example of a mutable object is a Java.util.Date object. Example:

Date myDate = new Date();
myDate.setTime(0);

In this example code, only one Date object is created. Its initial value is the current time (as specified by its default constructor), however when the setTime() method is called the value of myDate changes to be the start of the Epoc (or January 1, 1970 00:00:00 GMT). It’s state is mutated though its life.

Time for a very important point, why does any of this matter? After all most developers will use Dates and Strings all the time without any worry. A major advantage of an immutable object is that it will always been in a consistent state. No matter what order the methods are called on it, the answer will always be the same. I am sure that a few people will have suddenly realized what this means, but just in case: It means that a Mutable object can be shared between threads without having to worry about synchronization or mutex locks are it will always be in a valid state.

Lets create an immutable object, just for fun. This object will have a Date and a String. A first pass at trying this might result in:

public class Widget(){
  private final String myString;
  private final Date myDate;

  public Widget(String myString, Date myDate){
    this.myString = myString;
    this.myDate = myDate
  }

  public String getString(){
    return this.myString;
  }

  public String getDate(){
    return this.myDate;
  }
}

Looks good to start with. There are no “set” methods so therefore there is no way that someone can change the values in myString and myDate, and in any case they are declared “final” so we are all happy right? No quite.

Consider this:

Date date = new Date();
Widget widget = new Widget("String", date);
date.setTime(0);

What will happen is that the private variable “myDate” will be modified by the call to setTime() as well as the variable “date” as they both reference the same instance of the Date class. This means that the widget object is not currently immutable!

Lets change just the constructor to the following:

public Widget(String myString, Date myDate){
   this.myString = myString;
   this.myDate = new Date(myDate.getTime());
}

By changing the second line of the constructor, the Widget now gets its own Date object. The problem outlined above will not happen. If you were to run the code setting the time on the variable “date” it would only change the variable “date” and not effect the internal workings of the “widget” object. There is however another problem. Take a moment to see if you can spot it.

Here is the example of the code that will break the immutability on the Widget class:

Date date = widget.getDate();
date.setTime(0);

The call to “setTime” will effect the internal workings on the widget object. Luckily the fix is simple. By changing the getter for Date to the following:

public getDate(){
  return new Date(this.myDate.getTime());
}

A new date object is created and returned. This eliminates the issue outlined above.

You have likely noticed that it is much easier to build an immutable object using other immutable objects. For all of the issues I have just outlined with the Date object, the String object had no issues as it is immutable. I would recommend trying to make as many objects immutable as possible in your code as it will help issues before they arise.

However, don’t just make things immutable for the sake of it. If there is a valid reason for an object to be mutable it still should be. For example if you are keeping track of library books it would be a little odd to create a brand new object every time its location changes. All I am saying is that if it is possible to make an object immutable, then it should be done.

Posted in Uncategorized | Leave a comment

Comments are not the answer

I know what you are thinking “Tech Lobster, you have gone mad! Comments are our friends and are awesome”. Well indeed they can be. However I think that we have all missed something here. We have all been in code reviews and said “this code needs more comments”. I’ve said it and I’m sure you have. However I am going to share some comments that I have seen in code and why I think that they could safely be removed.

First up:

//Add 1 to X
x++;

This is an example of a comment that is completely pointless. I’ve lost count of the number of times I have seen something like this. All that is happening is that one line of code is taking up two lines. This could be totally removed and no one would be the worse off.

Next up:

//Add 1 to X
x = x + 2;

Although this is a simple example, I’ve seen this several times with more complex code. This is where the comments directly contradict the code. The reader of the code has no idea if the comment was correct and the code has been implemented incorrectly or if the code is correct and there is a typo in the comment.

Another of my favorites is pointless Javadoc:

/**
* Getter method for number of cakes. 
* Will return the number of cakes 
* @return int number of cakes
*/
public int getNumberOfCakes(){
  return numberOfCakes;
}

If you are writing a public accessible API for a library then this might be necessary. However in the vast majority of cases it should be quite obvious that “getNumberOfCakes” will tell you how many cakes there are.

I’ve heard people say that comments are needed if you have things that look like the following:

public int update(){
  //code
}

public int update2(){
  //different code
}

However this points much more to a poor design that requires you to have two methods called “update” that are only different in that one has a 2 on the end. This is not an example where comments will make things clearer, it is an example of code that needs a rewrite.

Here is another example of a comment that is really out of place:

/* Number of cakes currently stored in the system*/
int numberOfCakes;

The comment does nothing to inform the reader of anything that they could not work out by reading the code itself. While this is not too bad on its own, if you were to have 5 member variables then the number of comments would be well over the top. Comments should not be so commonplace that they are ignored while reading code.

So what is a good comment?

Good comments explain why something is happening, not how. For example:

/*
 * Start i at 1 as the first value in 
 * the array does not need to be processed
 */
for (int i = 1; i < array.size(); i++){
  //Some code
}

In my opinion, Code should be written so that comments are not needed to explain how something is happening.

Posted in Uncategorized | Leave a comment

There is always time for Pizza

It is now time to talk about something that every programmer loves. Pizza! No I have not decided to do a cooking blog rather than my coding one, but Pizza is very useful when talking about the Decorator Pattern. Shall we start at the beginning? A Design Pattern (of which Decorator is just one) is a common solution to a common problem. Patterns save us poor software engineers having to solve the same problem over and over again in different ways. Not every program needs Patterns, and certainly I have never seen an instance where you would use all of them (apart from trying to show off to new employers of course), but they are valuable additions to your programming skills.

So what is the Decorator Pattern and what does it have to do with Pizza? Lets for a moment assume that our programmer friend Fred (from a couple of posts ago) is now trying to represent lots of kinds of Pizza in his system. A sensible interface might look like:

abstract interface Pizza{
  public String getDescription();
  public float getPrice();
}

This is a great starting place. We know that all our pizzas will have a description (such as Pepperoni Thin Crust) and a price. It might have more methods in the end, but this is a good starting point. Fred now goes ahead an makes his thin crust and deep pan pizza classes

class DeepPanPizza implements Pizza{
   public String getDescription(){
      return "Deep pan"
   }

   public float getPrice(){
      return 1.50f;
   }
}

and

class ThinCrustPizza implements Pizza{
   public String getDescription(){
      return "Thin Crust"
   }

   public float getPrice(){
      return 1.30f;
   }
}

All good stuff so far. However, does Fred now have to create a subclass of each of these for each different type of pizza? That would mean a lot of classes. Fred would have a Pepperoni Thin Crust, a Pepperoni Deep Pan, a BBQ chicken Thin Crust and so on. Every time a new pizza got added to the menu then it would require a new class. This does not sound like a good idea!

What would be awesome is if Fred could represent the toppings as classes and then just build the pizza out of existing classes. This would also mean that people could have exactly what they want on a pizza (and I am a big fan of having what I want on a pizza!).

In steps the part that makes the decorator pattern awesome. Fred firstly creates an abstract class:

abstract class Topping implements Pizza{
   protected Pizza pizzaToBeTopped;
   public Topping (Pizza toBeTopped){
      this.pizzaToBeTopped = toBeTopped;
   }

   public String getDescription(){
      return this.pizzaToBeTopped.getDescription();
   }

   public float getPrice(){
      return this.pizzaToBeTopped.getPrice();
   }
} 

The burning question on everyone minds is : How does this help anything? Lets just take a quick look at it. The Topping has a reference to the pizza it is … well being a topping for, and as such can delegate any method calls to the underlying object. But more importantly it also implements the same interface, meaning that Fred can now “layer” his toppings!

Lets say we have two wonderful toppings of:

public class PepperoniTopping extends Topping{
  public PepperoniTopping (pizza toBeTopped){
     super(toBeTopped);
  }

  public String getDescription(){
    return "Pepperoni " + this.pizzaToBeTopped.getDescription();
  }

  public float getPrice(){
    return 0.50f +  this.pizzaToBeTopped.getPrice();
  } 
} 

and

public class OnionTopping extends Topping{
  public OnionTopping (pizza toBeTopped){
     super(toBeTopped);
  }

  public String getDescription(){
    return "Onion " + this.pizzaToBeTopped.getDescription();
  }

  public float getPrice(){
    return 0.20f +  this.pizzaToBeTopped.getPrice();
  } 
} 

It is now possible to write code that looks like this:

Pizza fredsPizza = new DeepPanPizza();
OnionTopping topping = new OnionTopping(fredsPizza);
PepperoniTopping secondTopping = new PepperoniTopping(topping);

If Fred was to call “get description” on the second topping, it would return “Pepperoni Onion Deep Pan Pizza”, and the price would be 2.20. What is even more clever is that is Fred decides he wants more Pepperoni (and who does not like MORE pepperoni!) he could just do:

PepperoniTopping thirdTopping = new PepperoniTopping(secondTopping);

In fact any combination of any of the Decorators will work. A new type of Pizza (lets say … stuffed crust) would instant work with all of the Decorators. This makes the code VERY easy to extend. Adding a new topping requires only one new class rather than having to change lots.

Posted in Uncategorized | Leave a comment

Not all code starts out great

Sometimes as programmers we are very lucky. We get to see code that is amazingly simple, easy to maintain and does something complex. We look on in wonder and think “I will never write code this good.” However there is a hidden secret to that code and that is that it did not start out like that. The first iteration of that code was likely very hard to read, impossible to maintain and has useless data flows throughout.

The impossible task of moving from one to the other is best done via small steps. Lets take an example. Suppose as part of some class data must be read from disk and stored in an ArrayList (one String per line). To start with it is likely that it will simply be part of some massive function that performs all of the logic in the class. For example:

class someClass{

 String fileLocation
 List<String> list = new ArrayList<String>();

 public void performActions(){
    ------snipped code----------
    try{
      FileReader fileReader = new FileReader(fileLocation);
      BufferedReader reader = new BufferedReader(fileReader));
      String fromDisk = reader.readLine();
      while (fromDisk != null){
        list.add(FromDisk);
        fromDisk = reader.readLine();
     }
     reader.close();
   }catch(IOException e){
      ------snipped code----------
   }
   ------snipped code----------
 }
}

Hopefully it is clear why this is a bad idea. The code for reading data from the disk is mixed up in all of the other business logic of the class. A first solution that might spring to mind is to move the code to a separate function within the same class. Therefore it would look like:

class someClass{

 String fileLocation
 List<String> list = new ArrayList<String>();

 public void performActions(){
    ------snipped code----------
 }

 protected void readFromDisk(){
     try{
      FileReader fileReader = new FileReader(fileLocation);
      BufferedReader reader = new BufferedReader(fileReader));
      String fromDisk = reader.readLine();
      while (fromDisk != null){
        list.add(FromDisk);
        fromDisk = reader.readLine();
     }
     reader.close();
   }catch(IOException e){
      ------snipped code----------
   }
 }

}

This is a good first improvement. However the class “someClass” has to know all sorts of things about where to read data from the disk, what it is using to read the data from the disk and so on. This naturally leads to using a separate class.

class stringReader{
 String fileLocation
 List<String> list = new ArrayList<String>();

 public void readFromDisk(){
 try{
      FileReader fileReader = new FileReader(fileLocation);
      BufferedReader reader = new BufferedReader(fileReader));
      String fromDisk = reader.readLine();
      while (fromDisk != null){
        list.add(FromDisk);
        fromDisk = reader.readLine();
     }
     reader.close();
   }catch(IOException e){
      ------snipped code----------
   }
 }
}

While this is not massively different from the last example, it is possible to see that at each level of re-factoring the code is being moved to enable more re-use. In the first example the code to read from the disk could only be used in that one function. The next layer enabled re-use within the same class, and the third time enabled re-use in other classes. So is this the point to stop at?

No. The reason for that is that the function is still performing lots of actions. It is doing exception handling, resource handling (in the form of BufferedFileReaders) and actually reading from disk. Firstly, lets separate out the exception handling:

class stringReader{
 String fileLocation
 List<String> list = new ArrayList<String>();

 public void readFromDisk(){
 try{
     this.getFromDisk();
   }catch(IOException e){
      ------snipped code----------
   }
 }

 protected void getFromDisk() throws IOException{
   FileReader fileReader = new FileReader(fileLocation);
   BufferedReader reader = new BufferedReader(fileReader));
   String fromDisk = reader.readLine();
   while (fromDisk != null){
     list.add(FromDisk);
     fromDisk = reader.readLine();
   }
   reader.close();
 }
}

Notice how the logical flow of the class is getting easier to understand. The readFromDisk function handles any errors that happen in the rest of of class. There is yet more to do however:

class stringReader{
 String fileLocation
 List<String> list = new ArrayList<String>();

 public void readFromDisk(){
 try{
     this.getFromDisk();
   }catch(IOException e){
      ------snipped code----------
   }
 }

 protected void getFromDisk() throws IOException{
   FileReader fileReader = new FileReader(fileLocation);
   BufferedReader reader = new BufferedReader(fileReader));
   this.readFromBuffer(reader);
   reader.close();
 }

 protected void readFromBuffer(BufferedReader reader) throws IOException{
   String fromDisk = reader.readLine();
   while (fromDisk != null){
     list.add(FromDisk);
     fromDisk = reader.readLine();
   }
 }
}

Now something interesting has happened. the readFromBuffer method simply takes a BufferedReader object and reads each line from it. This method does not care how the BufferedReader is created. This is very important as BufferedReader can be created with a StringReader, meaning that it does not actually require a file to read from disk. This means that unit testing is simplified and much less likely to go wrong.

There is more that could be done to this class (it is currently tied to the concrete class BufferedReader after all). But that is enough for one day.

Posted in Uncategorized | Leave a comment

Why everything is fast for small values of X

or Why you should test with large amounts of data

I am sure this is something that we have all experienced. You spend a good amount of time writing some code to do something, lets say sort a list. It works fine when you test it (well after you have ironed out a couple of bugs) and it goes live. Everyone is happy and the world is just fine. But after a short while everything starts to slow down. You have no idea why. Customers get sad as their awesome functionality that worked so well is now so slow that it is unusable. So what happened?

Lets take a fairly simple example. Imagine a programmer called … Fred. (Sorry to any Fred’s reading this, but Fred is very easy to type). Fred has been told that there is an array of data that really should be sorted in the project he is working on. Fred being the good programmer that he is goes away and looks up how to sort an Array. He quickly finds a simple algorithm called “Bubble Sort”. It’s really quick to write (in fact it’s less than 10 lines!). Fred writes this into this program and gives it an array of 7 things to sort. It correctly sorts it and Fred is happy. Just to check he tries it with 10 items, 20 items and 50 items. Every time it works just fine and Fred can’t believe how quick and easy it is to do this.

I am sure that the eagle eye’d out there have spotted Fred’s error. If you have not, go and have a quick read of the above paragraph and see if you can spot it. I’ll wait here. So did you get it? Well if you are having a slow day I’ll let you in. Fred never asked how many items would be in the Array he needed to sort. In this case, it was going to be 1,000,000 items. For those in the know, bubble sort performs far too slowly over this many items.

Therefore, I find it best to test with at least twice the number of items that it will need to operate on in production.

A question that leaps to mind immediately is, “why did the bubble sort slow down”? As a simple rule, the more items that something needs to operate on, the slower it will go. Therefore with any implementation there will be a point where it is “too slow”. I find it very important to identify where this point is. As programmers, we have a valuable tool to aid us in doing so. This is called “Big O” notation, and tells us how well an algorithm will scale.

Lets take a look at the Big O notation for a bubble sort. Simply put it is : O(n2)

Which is excellent, but what does it mean? Well the “O” is saying that it is in the “Big O” notation, and the n refers to the number of items that the sort will operate on. The answer to the calculation gives us the number of operations that will occur. So if there is 5 items, the number of calculations is 52 = 25. There is a quick table of the values that Fred used, some other values, and the actual value of items that he needed it for:

Number of items Number of operations
7 49
10 100
20 400
50 2,500
1,000 1,000,000
1,000,000 1,000,000,000,000

As you can see, the number of operations grows very quickly. With only a thousand items in the Array, it would take a million operations to sort them.

Compare this to a Merge Sort, which has a Big O notation of: O(n log n)

Number of items Number of operations
7 5.91
10 10
20 26.02
50 84.95
1,000 3,000
1,000,000 6,000,000

It`s important to note that these are “average” numbers of operations needed, which is why there are decimals.

As it is plain to see, when the number of items that need to be sorted is low, then the number of operations is always going to be low, even for bubble sort. However, as the number of items in the array grows, the number of operations grows rapidly for Bubble sort, where as for merge sort it grows much slower.

It is therefore very important to know how much data code needs to operate on, how it is likely to grow in the future, and if it matters long it takes to run.

For example, a method to alphabetically sort Windows Operating System release names will have its data set grow slowly, whereas a method to sort employees names could grow much faster.

Posted in Uncategorized | 2 Comments