I’ve bought a new laptop last week, a Mac !!

I’ve had some trouble getting used to it, but once you get used to the keyboard, it’s alright :)
I’ve found the most problems with the keyboard during programming, because you need a lot of special characters wich a normal user might not need that often But all’s good now, and I’m loving the little machine :)
Below are the specs of the laptop :

Intel 2ghz core 2 duo
2Gb ram
120 Gb harddrive

It’s been a while, and I’m pretty busy at the moment, so I don’t have a lot of time to post that often, but quieter times are ahead, so stay tuned :)

While searching the net for a wallpaper I stumbled upon a funny Access Denied message from our firewall. The funny thing was that I was searching for a wallpaper with a penguin in it and the first result I clicked on Google produced this error message

I don’t see the link between the categories, but I’m convinced that our firewall is a pervert ! penguins, Intimate apparel/swimsuit and software downloads shouldn’t be on one page together : )

Today I will be discussing the decorator pattern. This pattern is used to add responsibilities to your objects at run-time rather then at compile time. You can find some examples of the decorator pattern by looking at the Java I/O API or the swing table API. Below is a small example of the decorator pattern in action :

LineNumberReader lrdr = new LineNumberReader(new FileReader(filename));

As you can see we wrap the FileReader into the LineNumberReader which adds certain functionalities to the FileReader.
As always, we start with the UML scheme for this pattern :

As you can see in the scheme above, The decorator will hold a reference to the decorated object and delegate it’s methods to the object. In this way we create a chain which will go all the way into the most inner class of the pattern. Below is a use case diagram which shows you how it works :

Because most of the methods in the decorator just pass the call to the reference object, we can create an abstract class of the decorator which has a default behavior which is to delegate the call to his reference object.
Let’s take a look at a code sample for this pattern. Imagine a Textview widget. We might want the textview to have some nice borders. By implementing this with the decorator pattern, the textview object doesn’t have to be modified in any way, in fact, it doesn’t even have to know anything about the borders to function correctly.

public abstract class AView {
public abstract void draw();
}


next up, we have an implementation of the Aview :


public class Textview extends AView {
public void draw();
// draw the textview
}

Now we create the decorator, which is an abstract class :

public abstract class BorderDecorator extends AView {
public abstract void draw();
}


And now for the actual Decorators :


public class 3Dborder extends BorderDecorator {
private AView component;
public 3Dborder(AView compo) {
This.component = compo;
}
public draw() {
component.draw();
// code to draw the 3D border
}
}
public class BevelBorder extends BorderDecorator {
private AView component;
public 3Dborder(AView compo) {
This.component = compo;
}
public draw() {
component.draw();
// code to draw the bevel border
}
}


And now for the usage :


AView tv = new TextView();
Tv = new 3Dborder(tv);
Aview tv2 = new BevelBorder(new TextView());


I’ve stumbled upon a funny advertisement for Apple, not that I’m a real apple fan, but is really covers why I don’t use vista :)

Today I’ve been looking at the composite pattern, in order to use it in the project I’m currently working on. The composite pattern is mainly designed to create a uniform way to approach similar objects. Let’s start with a nice quote from the GOF :

Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

What this basically means is that with the composite pattern we can create a tree-like structure of objects where every object can either be a leaf or a composite. This allows us to create a structure with an indefinite depth of objects. Let me just point out that there are 2 different implementations for this pattern but I will discuss both of them so you can decide which want you want to use.

Let’s start with the UML scheme for this pattern.

As you can see in the scheme we start with creating an interface for our composite pattern, which we will use in our client classes. By Using this interface we’re allowing ourselves to access our objects without actually knowing whether this object is a leaf or a composite in our structure. The basic idea is to add all generic methods to the interface so that you can access them in the client class by using the interface. The composite implementations should delegate all these generic methods to his child objects. This way we can traverse the tree and preform an operation on all components of our tree.

Let’s have a look at some code now. We will create a component pattern for shape objects. By using the composite pattern we can have drawings which have an infinite number of shapes. First of all we create an interface for our component pattern :


public interface Component {
public void draw();
public void growSize(int size);
public boolean isComposite();
}

As you can see we created an interface for our component pattern which defines the methods that apply to all components in our structure. Our next step would be to create the implementations of this interface, we’ll start with the leaf :

public class Circle Component {public void draw() {
// actual implementation of our draw
}
public void growSize(int size) {
// increase the diameter of our circle
}
public boolean isComposite() {
return false;
}

Next up is another implementation of the component, but this time it will be a composite :

public class Rectangle Component {
private List children = new ArrayList();public void draw() {
foreach(component comp : children) {
// actual implementation of our draw
}}
public void growSize(int size) {
foreach(component comp : children) {
// increase the diameter of our circle
}
}public List getChildren() {
return children;
}public void addChild(Component child) {
this.children.add(child);
}public void removeChild(Component child) {
this.children.remove(child);
}public boolean isComposite() {
return true;
}
}
Now, as I mentioned at the beginning of this post, there are 2 implementations of this pattern. As you might already noticed, we use a method called isComposite() to determine if this object is a leaf or a composite, because at some point in our client classes we will probably have to know whether or not the object has children in order to access them directly. This is where our implementations of the composite pattern differ. This implementation uses the isComposite() to determine if it’s a composite and then preforms a cast in order to use the getChildren() removeChild() and addChild(). The other implementation has those methods in the interface, so you will be able to call them at any component ( leaf and composite ), the main advantage is that we don’t have to do the the check and the cast, but on the other hand, we have to implement the methods in our leafs as-well, which will be methods that just throw an exception.

More information on this pattern can be found at javaworld or wikipedia.

While looking into the code of our project I stumbled upon a part that I haven’t investigated before. The part is implemented with the strategy pattern, or so I was told because In fact the strategy pattern isn’t fully implemented. So I got curious about this pattern and found this nice definition by The gang of four :

Define a family of algorithms, encapsulate each one, and make them interchangeable. [The] Strategy [pattern] lets the algorithm vary independently from clients that use it.

In fact the strategy pattern can be used to avoid the use of big switch statements or if – elseif statements. What we do is, we create an interface and use this in our context class. This allows us to decouple the implementation and the usage for each other. The next step would be to create implementations of our strategies and and in order to use them we use a setter in the context class. Since explaining patterns is rather difficult without a UML scheme here it is :

Sorry for the poor drawing but I had to make this in Visio which really sucks. As for the actual implementation I will show you a few code fragments to actually demonstrate the usage in Java.

We’ll start with the Context class. We should define a private member which is an implementation of the ICalcul interface.

public class ContextClass {
 private ICalcul calcul = null;
 private double result = 0.0;
 .....
 public void setCalcul(ICalcul calc) {
  this.calcul = calc;
 }
public ICalCul getCalcul() {
  return this.calcul;
 }
public void calculate() {
  this.result = this.calcul.calculate();
 }
 ....
}

As you can see in the above code fragment we use the interface in the ContextClass this allows us to decouple the actual implementation of the calculation from the ContextClass. This is very useful since now we can create any sort of calculation we want and decide at run-time which kind of calculation we want to use.  All we need to do now is create an implementation of our calculation.


public class CalculA implements ICalcul {
 public double calculate() {
  return = 1.0/3.0;
 }
public void save() {
  // do something here
 }
}
There is our heavy calculation :) Now we can set the calculation we want in our application by doing the following

public class Calculator {
 .....
 public static void main(String[] args) {
  ....
  ContextClass cc = new ContextClass();
  ICalcul calc = new CalCulA();
  cc.setCalcul(calc);
  cc.calculate();
  ....
}
}

If you want more information on this pattern I suggest you take a look on wikipedia or simply search for it with google.

Found a nice presentation on Caché, an Object-oriented database. According to the presentation this database should boost your applications performance by 15% to 30%, which is a lot. And a reason for me not to thrust it, so I’ve download a copy of the framework, and a licence ( which appears to be free for personal use ) to test it tonight. After watching a few presentations about it, I think it’s a very nice framework, but I will try to post my personal opinion in a few days.

Watch the technology demo here and visit the homepage with this link

Received a link from a colleague today, Its a fragment from a French tv show called striptease. I guess the movie will explain the rest.

Enjoy !

Today, I received a mail from one of our team members in which he decided that we would have a competition. The winner will get a prize although we haven’t decided on what it should be. The competition is rather easy, the one who wrote the worst piece of code in the application gets the prize. Since not everybody thought this competition was a good idea, it think we should change it a little bit, the one who finds the worst code and corrects it, gets the prize. This way, we avoid criticism and the point and laugh situations and create a fun learning experience, although the possibility to have a competition like this proves that a lot of the code is in poor shape.

As you might have noticed from my previous posts, I’ve been put in charge of refactoring pieces of the application to “clean up” the code. Although I find it really interesting to do, it’s also a time consuming task which is hard to justify, because if the job was well done from the beginning, it wouldn’t have been necessary.

On the other hand, nothing is perfect, and I guess that a project of this magnitude is hard to maintain, especially if only two people are in charge of keeping an eye on all the code. So in a way it might be justifiable to have some code in a lesser shape :) And if everything would be perfectly written then we wouldn’t have a fun competition like this :)

Last week I refactored the database layer of our application. Since the layer was pretty poorly implemented, I did a complete rework, meaning that a lot of classes had to be rewritten and put in new packages. Now the cool thing about all this is that with the new implementation it will be possible to hotplug another db layer into the application without changing any of the code inside the application. I’ve used a Factory class wich in fact is a singleton class, this allowed me to instantiate an actual Factory of choice, right now the application has only one implementation of the db layer, but we could create a completly different one ( read as : get rid of the crappy toplink and use hibernate instead :) ) . Below is the the getInstance() method wich does the magic for us :


public static IPersistanceFactory getInstance() {
if (instance == null) {
logger.debug("Creating new IPersistanceFactory implementation : "
+ implementation);
Class clazz;
try {
clazz = Class.forName(implementation);
instance = (IPersistanceFactory) clazz.newInstance();
} catch (ClassNotFoundException e) {
logger.error("Class not found : " + implementation, e);
} catch (InstantiationException e) {
logger.error("Can not instantiate class : " + implementation,e);
} catch (IllegalAccessException e) {
logger.error("Illegal access for class : " + implementation, e);
}
}
logger.debug("Instance created !");
return instance;
}

The string with the implementation could possibly be in an application.properties file or something like that, this could allow us to externally decide wich db implementation we should use.

Since the application is rather huge, and exception handling isn’t something that has been taken into account when writing the drafts for JSF, it took me some time to find a decent way to implement exception handling. I came up with two possible solutions, but after further testing it turned out that only one of them actually worked. Sadly it was the one that I felt, was the worst scenario.

First I tried to delegate the Faces servlet and tried to catch any exceptions there. that would have been a nice solution, since all exception handling would have been centralized and I wouldn’t have to have to much boiler plate code inside my application. But, as it turned out, this solution didn’t work :( After carefully testing the mock-up I had to come to the conclusion that delegating a Faces servlet is not a good way to go, certainly not a good way if your using icefaces.

The second solution was rather nasty but, i went on with it anyway since I couldn’t find any better solution after searching the net. I let every exception get back to the event methods and catch it there. Once I had the exception there, I was able to pass it to an exception handler class, which would take care of the logging and displaying a nice pop up with some info for the user.

If you ever think of building a corporate application using JSF, don’t ! :) In my opinion it lacks some basic functionality and basically it isn’t ready for usage in real world applications yet. If you really want JSF then don’t use it as a stand-alone framework, I think it would be better to use it in combination with Spring or Struts.

Hi,

Started a blog again, I hope that this time I will be able to keep posting on it, because I have a tendancy to forget to actually post something on it :) Anyway, I hope I will be able to keep my readers ( that is you ! ) informed and to keep them entertained with my random rantings about work.

Stay tuned, maybe someday there well be something usefull on this page :)