• [ << ]
  • [ 0 ]
  • [ 1 ]
  • [ 2 ]
  • [ 3 ]
  • [ >> ]
Feb '05
01

Object Spaghetti : Patterns bieden uitkomst?

Men zegt dat object georiïnteerde (OO) systemen vele voordelen kennen ten opzichte van traditionele procedurele systemen. Zo zouden OO systemen flexibeler en beter onderhoudbaar zijn. In de praktijk valt dat nogal eens tegen. Een van de oorzaken is het niet of onvoldoende scheiden van de objecten - Object Spaghetti - Neem een object en de rest zit er aan vast. Naast hoe je het niet moet doen beschrijft en illustreert dit artikel de mogelijkheden die je als Java Programmeur hebt om deze ellende te omzeilen.

Door Erik Hooijmeijer

Wat is het probleem nou eigenlijk?

Een object georiënteerd systeem bestaat uit klassen die elkaar diensten verlenen. Om elkaar diensten te kunnen verlenen moeten ze elkaar kennen (naar elkaar kunnen refereren) Bijvoorbeeld een object dat koffie drinkt (ik!) en een KoffieZetApparaat. Als ik koffie wil drinken heb ik een referentie nodig naar het KoffieZetApparaat en ben ik er dus van afhankelijk. Het betekent ook dat als je de KoffieDrinker wilt compileren je altijd de KoffieZetApparaat klasse nodig hebt. En wat nu als je een keer Espresso wilt? Dan zul je heel je programma moeten aanpassen en opnieuw compileren.

CoffeeDrinker --- CoffeeDevice

Leuk, zul je zeggen, maar daar hebben we in Java interfaces voor. Interfaces maken het mogelijk een onderscheid te maken tussen wat een object kan (zijn methoden) en zijn daadwerkelijke implementatie. Een interface kan dus worden geïmplementeerd door twee verschillende objecten die helemaal niets met elkaar te maken hebben, echter door de interface kunnen ze wel uniform benaderd worden.

Laten we een interface CoffieProducer maken die werkt als scheiding tussen mij en het Koffie Zet Apparaat (CoffeeDevice) - zodat we de implementatie kunnen wijzigen zonder dat ik dingen moet leren over andere soorten KoffieZetApparaten (stel je voor!). In UML :

CoffeeDrinker --- << CoffeeProducer >> --- CoffeeDevice

Helemaal goed! Behalve dan de vraag van hoe komt de CoffeeDrinker aan zijn CoffeeProducer? Dat is lastig want je kunt geen object maken van een interface - daar voor heb je een klasse nodig. Wel verdorie, en we waren net zo goed bezig.. Laten we gewoon eens wat proberen :

                
 public class CoffeeDrinker {

 private CoffeeProducer myCoffeeProducer;
 
 public CoffeeDrinker() {
 myCoffeeProducer=new CoffeeDevice();
 }
 	
 public void drink() {
 System.out.println(
 "Drinking "+
 myCoffeeProducer.getCoffee()
 );
 }
 
 }

                

Of in UML :

CoffeeDrinker refereert naar CoffeeProducer maar maakt zelf het CoffeeDevice....

In dit voorbeeld wordt de CoffeeProducer aangemaakt in de constructor van CoffeeDrinker. Deze oplossing werkt, maar uiteindelijk schiet je er niets mee op, want de CoffeeDrinker heeft nog steeds een harde (statische) afhankelijkheid met het CoffeeDevice. Dat wil zeggen als je CoffeeDrinker compileert heb je nog steeds de CoffeeDevice klasse nodig, terwijl de bedoeling nou net was om dat te voorkomen. Zucht..

  • [ << ]
  • [ 0 ]
  • [ 1 ]
  • [ 2 ]
  • [ 3 ]
  • [ >> ]