[Java] Verantwoordelijkheden van klassen

[Gerco]

Ik zat eens na te denken over een probleem wat een kennis van mij aan me voorlegde. Hij moet voor school een applet maken met een stoplicht en een auto. Het stoplicht moet van kleur veranderen en de auto moet stoppen als het rood is.

Al met al is dit niet bijzonder boeiend, ik bedacht me dat je dat mooi kon doen met 2 threads (1 stoplicht en 1 auto) die dan elk bijhouden wat hun state is enzo.

Nu loop ik tegen het volgende probleem aan: Welke klasse doet het tekenwerk? Doen de auto en stoplicht klassen dat op een canvas wat ze door de applet wordt doorgegeven? Zit wat in, aangezien ze dan beiden netjes apart werken, maar tekeken 'op een canvas wat niet van mij is' komt op mij wat vreemd over, want waar teken je dan? (je x en y dus)

Een andere mogelijkheid is om de applet het tekenwerk te laten doen en daarbij de x en y positie van de auto en kleur van het stoplicht op te vragen, maar dat zit me ook niet lekker omdat de applet in principe helemaal niets te maken moet hebben met hoe een auto of een stoplicht eruit ziet.

Een andere vraag is weer hoe je de communicatie NETJES doet. Momenteel doet hij het met een variabele in de Applet die dan gezet wordt door het stoplicht en opgevraagd door de auto, maar dat lijkt mij beter kunnen al zou ik niet weten hoe.

Al met al een paar leuke vraagjes voor de javahova's hier lijkt me zo. Het is niet moeilijk, maar ik vind het toch best interessant om eens over na te denken.

[Verwijderd]

code:

public interface TrafficLightListener
{  public void lightChanged(int light); // event??
}

public interface Car extends TrafficLightListener
{  public void startMovingOn(Road road);
   public void notifyOfRedTrafficLight();
}

public interface Road
{  public void addCarListener(CarListener cl);
   public void removeCarListener(CarListener cl); 
   public void markPosition(CarPosition cp);
}

public interface CarListener
{  public void carReachedPosition(CarEvent evt);
   public void carStopped(CarEvent evt);
}

public class CarEvent
{  private Car car;
   private CarPosition position;

   private Carevent(Car car, CarPosition position)
   {  this.car = car;
    this.position = position;
   }

   public Car getCar()
   {  return car;
   }

   public CarPosition getPosition()
   {  return position;
   }
}

public class TrafficLight implements CarListener
{  public static final int RED_LIGHT = 0;
   public static final int ORANGE_LIGHT = 0;
   public static final int GREEN_LIGHT = 0;

   private int state = GREEN_LIGHT;

   public TrafficLight()
   {
   }

   public void setState(int state)
   {   this.state = state;
   }

   public void placeOn(Road road, CarPosition position)
   {   road.addCarListener(this);
     road.markPosition(position);
   }

   public void carReachedPosition(CarEvent evt)
   {   if (state == RED_LIGHT)
        car.notifyOfRedTrafficLight();
   }

   public void carStopped(CarEvent evt)
   {  // ...
   }
}

uhm... ik ga weer eens aan m'n werk

[ACM]

Op dinsdag 25 juni 2002 11:42 schreef websjwans het volgende:
uhm... ik ga weer eens aan m'n werk

Is dat jouw manier van discussieren?
Gerco kan dat prima zelf maken, als ie dat al wilde hoor

[Verwijderd]

Daar heb ik ook alle vertrouwen in

Ik wou alleen ff een voorbeeldje maken, maar het was wat uit de hand gelopen

[whoami]

Op dinsdag 25 juni 2002 11:42 schreef websjwans het volgende:
uhm... ik ga weer eens aan m'n werk

Ja, ik snap het ook niet hoor. Gerco vroeg gewoon een ontwerp advies, hij vroeg geen kant en klare oplossing. Het is trouwens niet de bedoeling van P&W om kant en klare code te posten bij ieder probleem. (Al mag dat wel).

[Gerco]

Op dinsdag 25 juni 2002 11:46 schreef websjwans het volgende:
Ik wou alleen ff een voorbeeldje maken, maar het was wat uit de hand gelopen

Da's prijzenswaardig, maar het voorbeeld is niet interessant. Wat echter WEL interessant is: "Waarom heb je voor dit ontwerp gekozen en niet voor 1 van de andere mogelijkheden?"

Dat het zo kan weet ik ook wel, om alles te gaan opnoemen in mn eerste post is een slecht idee want dan had ik volgende week nog niet klaar geweest met tikken

Bovendien negeer je in jouw voorbeeld dat een trafficlight ook op een bepaalde road zou moeten staan. Anders gaan auto's stoppen omdat er aan de andere kant van de stad een light rood is

Maar goed, daar ging het niet over, het ging mij meer over het tekenen.

[Verwijderd]

Goed, ik zal het in het vervolg wat korter houden. Waarschijnlijk is het een beetje overkill waar ik in m'n voorbeeld een begin mee _probeerde_ te maken, maar het komt erop neer dat ik de werkelijkheid zo goed mogelijk wou modeleren (net Mathematisch Modeleren & Simuleren geleerd, vandaar ).

In ieder geval zou die auto gewoon de weg moeten gaan volgen tot hij over een 'sensor' komt. In mijn voorbeeld gaat de event dan naar het stoplicht die de auto laat zien dat het licht op rood staat. In feite is dit weer niet goed als je de werkelijkheid zo goed mogelijk zou willen simuleren, maar hoe het IMHO wel zou moeten zal ik jullie maar besparen

[Gerco]

Dat idee met die 'sensor' klopt niet helemaal volgens mij. Stel dat de auto over de sensor rijdt en nadat hij er overheen is wordt het licht rood (we houden even geen rekening met eventuele remwegen en meer van dat soort leukigheden), dan zal de auto toch niet stoppen.

[Alarmnummer]

Je kan inderdaad het beste via MVC werken. Met mvc maak je een scheiding tussen je objecten die alle interessante informatie bezitten. Zoals:

code:

public class Auto{
   int xPos;
   int yPos;
   float dir;
   float speed;

   public void setXPos(int xPos){
    this.xPos = xPos;
   }
   ....
}

Zoals je zit heeft auto dus geen visualisatie mogelijkheden. Een class zoals Auto (die dus alle logica en data bezit die voor die auto belangrijk is) wordt een Model object genoemd. Maar je wilt natuurlijk je model ook gaan visualiseren. Dit doe je mbv een View object. Dit is een object die alle (of een aantal) eigenschappen van de model weer geeft.

code:

public class AutoPanel extends JPanel{
   public AutoPanel(Auto auto){
     //teken een auto plaatje ofzo..
   }
}

Maar hoe gaat er nu communicatie plaatst vinden tussen je model en je view? Dit gebeurt dus mbv Events. Als er iets in de model gebeurt dan geeft hij dat door aan iedereen die luisterd, en toevallig luisterd je View daarna mbv een Controller.

vb.

code:

public class Auto{
final static public String XPOS = "xPos";

   int xPos;
   int yPos;
   float dir;
   float speed;
   PropertyChangeSupport pcs = new PropertyChangeSupport(this);
   public void setXPos(int newXPos){    
    int oldXPos = xPos;
    xPos = newXpos;
    pcs.firePropertyChange(XPOS,oldXPos,newXPos);
   }

   public void addPropertyChangeListener(String property, PropertyChangeListener l){
    pcd.addPropertyChangeListener(property,l);
   }
   ....
}

Als je nu de xPos gaat aanpassen, dan ga je dus een propertychange event versturen.

Maar hoe moet nu je view hier naar luisteren?

code:

public class AutoPanel extends JPanel{
    public AutoPanel(Auto auto){
     auto.addPropertyChangeListener(Auto.XPOS,new XPosListener());
    }   

    class XPosListener implements PropertyChangeListener{
      public void propertyChange(PropertyChangeEvent e){
        //hier kan je verandering komen te staan.
      }
    }
}

Zoals je zit luisterd de autopanel nu naar de XPos van de auto dmv de XPosListener. Je kan de XPosListener beschouwen als je controller. Want hij vertaald je event van de model, naar de View. Op deze manier heb je dus een MVC ontwerp.

Als je grotere projecten gaat maken, dan zul je niet onder mvc (Model View Controller) uitkomen. Omdat ten eerste je objecten veel eenvoudiger blijven, en ook alle logica bij elkaar staat ipv dat model objecten met view objecten gemixed.

[Verwijderd]

*kuch* ik zal maar weer verder gaan leren

[Gerco]

Aha, dat is inderdaad min of meer wat ik in gedachten had, voor het rood worden van het licht geldt natuurlijk precies hetzelfde. Dan moet natuurlijk nog de afstand tot het licht bekeken worden enzo, maar dat is allemaal niet zo spannend.

Wat ik me nog wel afvraag: Welk object bepaalt de xPos van de Auto? Een Auto heeft een snelheid, dus die xPos zal weleens veranderen, maar hoeveel verandert die (verschillende resoluties bijvoorbeeld), en welk object is daar verantwoordelijk voor?

Het lijkt me dat de Auto verantwoordelijk is voor zijn positie in de 'virtuele wereld' en dat de AutoPanel dan verantwoordelijk moet zijn voor het tekenen van het object in de 'schermwereld'. Moet het model dan ook de coordinaten in de virtuele wereld omrekenen naar het scherm? Of moet de auto dat zelf doen?

Mij lijkt het eerste (het modelobject rekent om), aangezien de auto dan in de virtuele wereld echt een auto is, niets meer en niets minder).

[Alarmnummer]

Op dinsdag 25 juni 2002 12:25 schreef Gerco het volgende:
Aha, dat is inderdaad min of meer wat ik in gedachten had, voor het rood worden van het licht geldt natuurlijk precies hetzelfde. Dan moet natuurlijk nog de afstand tot het licht bekeken worden enzo, maar dat is allemaal niet zo spannend.

Wat ik me nog wel afvraag: Welk object bepaalt de xPos van de Auto? Een Auto heeft een snelheid, dus die xPos zal weleens veranderen, maar hoeveel verandert die (verschillende resoluties bijvoorbeeld)

Die auto mag niets met een visualisatie te maken hebben, dus een resolutie (visuele eigenschap) hoort ergens anders thuis. Ik zou dit gewoon in de view doen.

Het lijkt me dat de Auto verantwoordelijk is voor zijn positie in de 'virtuele wereld' en dat de AutoPanel dan verantwoordelijk moet zijn voor het tekenen van het object in de 'schermwereld'. Moet het model dan ook de coordinaten in de virtuele wereld omrekenen naar het scherm?

De model mag niets met de view te maken hebben, want misschien wil je wel meerdere views over 1 model. Je view die moet inderdaad maar omrekenen hoe het er gaat uitzien.

[whoami]

Op dinsdag 25 juni 2002 15:21 schreef idriaan het volgende:
nee, volgens mij lukt dat niet

Jij hebt een mail gekregen ivm je postgedrag, ik hoop dat je er wat aan doet. Tech posts scoren om HK toegang te verkrijgen is not done.
Edit: post getrashed.

[Alarmnummer]

Op dinsdag 25 juni 2002 15:31 schreef whoami het volgende:

[..]

Jij hebt een mail gekregen ivm je postgedrag, ik hoop dat je er wat aan doet. Tech posts scoren om HK toegang te verkrijgen is not done.
Edit: post getrashed.

Ik vind het goed dat je die vent zijn mail hebt getrashed, en van mij part geef je hem een permanente ban.

Maar eigelijk is het wel een beetje paradoxaal. Mensen van Programming & Webscripting komen over het algemeen minder bij e huiskamer (nivo is daar nogal extreem laag). Maar als je eerst bij dat lage nivo wilt komen dan zul je je eerst moeten verhogen tot dit nivo en daarna heb je geen zin meer om bij de huiskamer te komen.