« October 2004 | Inicio | December 2004 »

November 27, 2004

New category: J2ME

It's time to add a new category to this blog: J2ME. Don't expect to find anything specially brilliant here ( well, you know, if you've read the other categories you actually know that you can't expect anything brilliant here ).

Anyway, as I'm actually focusing a bit more on J2ME, and devices in general, I'll try to post about the things that I might find of interest.

I'll start with a collection of links ( many of them for my own future reference ).

Devices manufacturers:

Nokia forum
Siemens developer portal
Sony Ericsson developer world

Java resources:

Mobility resources at java.sun.com
J2ME package listing
J2ME Java Forums
J2ME.org forums
JGuru J2ME faq
Jason Lam
MIDP Programming with J2ME
J2ME Resources

More to come!

J2ME Open Source Software Directory

UPDATED 21/12/2004
MIDP 2.0 games

November 16, 2004

OT: Tindersticks

Saturday, November the 20th, at Divino Aqualung ( Madrid )


November 08, 2004

Inner classes in AS2?

ActionScript does not support the creation of inner classes, at least, not in the way that Java does.

Manuel de la Higuera has made an interesting post about how to implement inner classes in ActionScript, and the effect they have on performance. I think it's worth to be checked.

Design patterns considered harmful?

An interesting discussion about the "over designed" systems. Does the use of design patterns encourage over-engineering?.

In this discussion at the c2 wiki, you could find the opinions of people supporting the use of design patterns, and people that thinks that they should not be used always. And also, a lot of links to very interesting resources. A must read.

So, here's the link:

Design patterns considered harmful

Favour composition over inheritance ( and III )

But there are more heavy weight reasons to favour composition over inheritance.

First, inheritance doesn’t allow to change the implementations of the subclasses at run time, and breaks encapsulation, because the implementation of the superclass is visible through the subclasses.

However, composition is usually made at run time, so all objects must have a good knowledge of the other objects’ interfaces ( and only of the interfaces ), which favours encapsulation.

But there’s also another advantage in composition. If we rely more on composition that on inheritance, our programs will be more like a puzzle made of a lot of different pieces, each one responsible of a little task. So, our class hierarchy won’t be a huge dinosaur, hardly flexible, and hard to maintain. But also, the application behaviour will change easily at run time, and won’t be constrained by the code we’ve written in a class.

We’ll try to illustrate this with another example. Suppose we are working on an application for a football ( or soccer ) club. One of the modules of this application must show a list of the club’s members, that is loaded form a XML file.

We can implement a class that extends XML, and that loads and parses the file, and returns an array of objects, each one containing the data of one of the club’s members.

What if the rest of the program changes, and now we won’t need an array of objects, but another data structure?. Well, we could write another class, that also extends XML, but with a different parser.

But we could have also solved our problem follwing the puzzle example. We could develop a class that loads the XML file, and returns an XMLNode containing the XML firstChild, and delegate the responsibility of parsing and building a data structure to the class that is going to need and use those data. Why?. Because, if we do everything in a unique class, that class will need to know about the data, and the ussage of that data by the rest of the program. But if we separate the responsibilities, everything will be more flexible, and we also have a component ( a class that loads a XML and return a XMLNode ) that can be used in all our projects. And we also decouple the data from the service to obtain it, of course.

So, it seems that composition is the perfect solution for everything. Well, not everything. There are also some points about composition that must be considered. First of all, we said that building our systems using little piezes favours flexibility, but it also makes our program more difficult to debug. And also, the performance of the code based on composition is a bit slower than the performance of the code based on inheritance ( which can be very important in Flash ).

In fact, we should use both techniques mixed. For instance, back to the example of the XML, both the class that loads the XML file could ( in fact, should ) extend XML The class that parses the data should extend an abstract class ( or implement an interface ) with the parser method.

Inheritance is not evil, at least when be use it to solve our problems, not as a "design imposition". But, in general, our problems can be easier to solve if we favour composition over inheritance. Don't you agree?

Favour composition over inheritance ( II )

What happens if our class hierarchy is extremely deep?. Any change in any of the superclasses will mean that we’ll have to make a lot of changes in many different parts of our program.

Let’s go one step beyond. Suppose that there’s a method in HumanBeing like this one:

public function pay( ammount: Number ): Coin { return new Coin( ammount ); }

So any human being that has to make a payment, does it giving a coin of the given ammount. All developers and truckdrives extend HumanBeing, so they will implement this method. And any class that interacts with a developer or a truckdriver should accept coins as a payment method.

But, what happens if we need to change the payment method?. What happens if now, instead of giving coins, everybody should pay using a credit card?.

Any little change in the superclass interface will affect the subclasses, and can affect our program in many different places ( for instance, we cannot pay a bus ticket with a credit card, although we can pay for a meal at a restaurant using a credit card ).

But suppose we delegate the responsibility of payments in a different class, titled PaymentManager:

class PaymentManager { var actualFunds: Number; function PaymentManager( ){} public function init( initFund: Number ) { this.actualFunds = initFund; } public function pay( ammount: Number ): Coins { this.actualFunds-= ammount; return new Coin( ammount ); } }

Now, Developer and TruckDriver will look like this:

class Developer extends HumanBeing { var paymentManager: PaymentManager function Developer( ) { this.paymentManager = new PaymentManager( ); this.paymentManager.init( 100 ); } public funtion pay( ): Coin { return this.paymentManager.pay( 100 ); } }

If we need that the developer pays using a credit card, we’ll only have to change the Developer class implementation:

public function pay( ): CreditCard { return new CreditCard( this.paymentManager.pay( 100 ) ); }

Well, maybe this is not the best example possible, but I hope it helps to understand the concept.

But, also, if we’ve relied on inheritance only as a way of reusing code, we can find the opposite problem. We could need to change the interface of one of the subclasses, so we’ll have to change the interface of the superclass, which will introduce some changes in the rest of the subclasses. Let’s try again to show an example:

If the base class ( HumanBeing ) implements the following method:

public function getSocialSecurityNumber( ): String { return this.socialSecurityNumber; }

both Developer and TruckDriver will implement that method. But what if the developer’s employer asks him for his Social Security Number, but encrypted?. We’ll have to change the superclass, and that will change the TruckDriver class. You can argue that, well, that method could be overwritten ( in the Developer class ). But, then, there was not need to make that method part of the superclass. Why?. Because the implementation is not the same for all the subclasses, although the interface ( the name of the method ) is the same. So everything could have been implemented using a common interface.

Favour composition over inheritance( I )

Inheritance is a powerful tool. I can´t imagine my work without it. But it's not good to rely only on inheritance. Composition can be a better solution for many of our problems.

A few weeks ago, someone told me that the discusion about inheritance vs composition was like the discusion about PC vs Mac. But I don't think so. I believe that there are many points that suggest that we should favour composition.

Inheritance allows us to build a class using another class. Let’s try to see an example:

class HumanBeing { function HumanBeing( ) { } public function eat( ){} public function sleep( ){} public function speak( ){} } class Developer extends HumanBeing( ) { function Developer( ){} } class TruckDriver extends HumanBeing( ) { function TruckDriver( ){} }

Both the truck driver and the developer are human beings, some there will be some behavoiurs that are common to both of them ( for instance, eat, sleep, and speak ), and those behaviours are common to both of them just because they are human beings, and all the human beings eat, sleep, and speak. Well, so there we’ve found the two main concepts behind inheritance.

First, inhertiance allows to reuse code. When we need many different classes, that implement some common methods, we can implement that code into a base class, and make the other classes extend that base class. So, we can save us from having the same code in a lot of different places ( which can be a hell to maintain ).

Second, inheritance also allows us to group classes by the concepts they represent. In our example, both the truckdriver and the developer are human beigns, so it seems logical that both entities extend the HumanBeing class. In fact, that’s the most well-know rule to decide when a class must extend another one: the "is-a" relationship. The developer "is-a" human being, the truck driver "is-a" human being, so, both of them must extend the HumanBeing class.

There’s also another advantage of inheritance. And it is polymorphism. We can use any variable typed as HumanBeign to store a reference to any TruckDriver or Developer instances ( so, a variable typed as the base class – also called superclass - could store a reference to an instance of any of the subclasses ).

Composition, on the other hand, is a relationship that makes a class own another ( a class uses instance variables that are references to other classes ). Let’s see it with an example:

class Developer extends HumanBeing { var pet: Pet; function Developer( ) { this.pet = new Pet( ); } }

The developer has a pet. That’s the keyword to define a composition relationship: "has-a"

Until now, it seems clear when you should use inheritance and when you should use composition. So, why is this post titled "favour composition"?. Is there any doubt about when to use one or the other approach?

Yes, there are seriuous doubts about the benefits of inheritance under certain conditions. We’ll try to see some examples of inheritance relationships that are not the best of the available solutions.

First of all, we’ll go back to the first example. But now, we are going to build a class ( "Worker" ), that will implement all the behaviours of a working person, and that will extend the HumanBeing class ( a worker "is-a" human being ).

class Worker extends HumanBeing { function Worker( ){} public function doWork( ){} }

So now, the Developer and TruckDriver classes will be:

class Developer extends Worker { } class TruckDriver extends Worker { }

Now, both the developer and the truckdriver will inherit the methods of HumanBeing and the methods of Worker.

So, we have a superclass ( HumanBeing ). Worker extends HumanBeing( a worker "is-a" human being ), and both the developer and the truckdriver extend Worker ( a developer "is-a" worker, and a truckdriver is also a worker ). Right?

Hmmmmmmmmmm. Not at all. A developer is not always a worker. In fact, after work, some of them like to go out with their friends, or practice any sport ( for instance ). So a developer is not always a worker. And so, the Developer class should not extend the Worker class, because the behaviour of a developer will not always be the behaviour of a worker. In other words, the "is-a" rule should be "is-a, and only a, and always a".

In this case, for instance, the solution could be to make the functionallity of a worker be part of an interface, that both the Developer and the TrcukDriver class could implement, or even better, both the Developer and TruckDriver class could have an instance variable that could be an instance of the Worker class.

class Developer extends HumanBeing { var workerBehaviour: Worker = new Worker( ); public function doWork( ) { this.workerBehaviour.doWork( ); } }

This solution has another advantage. If we must change the interface of Worker, that change will only affect Developer and TruckDriver, because all the other classes that interact with Worker, will do it through Developer or TruckDriver. So, refactoring will be easier.

There will be more in the next post.