T-Rex: Konfiguration, OOP² oder doch nur Rad² ?

Beitrag lesen

  1. In einem anderen Posting hast Du den Erfahrungswert erwähnt, dass meist zu viele Methoden in einer Klasse wohnen. Darf ich das pauschal auf die Lösung mehr Klassen mit weniger Methoden münzen?

Mal von Getter und Setter Methoden abgesehen sollte eine Klasse an die 7 Methoden haben. Eine Methode wiederum sollte an die 4 Parameter haben.

Gerade wenn ein Projekt wächst ist man leicht dazu geneigt seine Klassen explodieren zu lassen. Früher oder später wird man jedoch mit Wartbeikeitsproblemen zu kämpfen haben. Um dem entgegen zu wirken gibt es für diverse Fälle eben Software Patterns. Eine davon ist die von Sven vorgestellte Dependency Injektion.

  1. Gehen wir mal von einer hinreichend komplexen JavaScript-GUI aus. Die Situation scheint mir hier wg. der Benutzerinteraktion / Events / Browserunterschieden zunächst schwieriger. Zentrale Bestandteile lassen sich dann nur über Fernsteuerungen wie z.B. Selenium automatisiert testen?

Ob Javascript, PHP, C++ oder Java das vorgehen ist immer das selbe. Durch die OOP zerlegst du dein System in kleine kompakte und wenn möglich in sich abgeschlossene Häppchen. Diese kannst du dann bequem mit diversen Unittests testen. Im Falle einer Browserweiche würde das ganze vielleicht so aussehen:

  
if(IE)  
{  
   objObjekt.method(IEstuff);  
} else {  
   objObjekt.method(OtherStuff);  
}  

IEtuff und OtherStuff sollten den gleichen Wert liefern. Dass könnte z.b. die Mauszeigerposition sein (da haben IE und z.b. FF unterschiedliche Methoden die aus zu lesen?). In die Methode wird aber nur der Wert an sich übergeben. In der "method" darf dann keine Browserweiche mehr vorkommen, dann kann man diesen Part unabhängig vom Browser testen.
Denkbar wäre hier die von Sven bevorzugte Dependency Injektion:

  
if(IE)  
{  
   objObjekt.method(objObjectIE);  
} else {  
   objObjekt.method(objObjectFF);  
}  

die Method selbst würde dann so aussehen:

  
method(objObject)  
{  
var something = objObject.getSomething();  
//--- do something  
}  

Du testest erst ob bei den Objekten objObjectIE und bei objObjectFF in beiden Fällen der gleiche wert aus der getSomething Methode kommt (eventuell auch per Unittest). Dann kannst du bei den Unittests dich auf ein Objekt versteifen.

Falls du das "if" an mehreren stellen brauchst, kannst du es wiederum in eine Funktion oder in eine Methode packen.

Wie man sieht hat Dependency Injection seine Berechtigung. Auf das Thema DI und Defaultwerte gehe ich jedoch nicht nochmal ein ;).

Gruß
Guy Fawkes lächelnder
T-Rex