Ich starte ein Schulgruppenprojekt in Java mit Swing. Es ist eine unkomplizierte grafische Benutzeroberfläche der Database Desktop App.
Der Professor gab uns den Code aus dem letztjährigen Projekt, damit wir sehen konnten, wie er die Dinge macht. Mein erster Eindruck ist, dass der Code weitaus komplizierter ist, als er eigentlich sein sollte, aber ich stelle mir vor, dass Programmierer dies oft denken, wenn sie sich Code ansehen, den sie nicht nur geschrieben haben.
Ich hoffe Gründe zu finden, warum sein System gut oder schlecht ist. (Ich fragte den Professor und er sagte, ich würde später sehen, warum es besser ist, was mich nicht zufriedenstellt.)
Um eine Kopplung zwischen seinen beständigen Objekten, Modellen (Geschäftslogik) und Ansichten zu vermeiden, wird grundsätzlich alles mit Zeichenfolgen ausgeführt. Die persistenten Objekte, die in der Datenbank gespeichert werden, sind Hashtabellen von Zeichenfolgen, und die Modelle und Ansichten "abonnieren" sich gegenseitig und stellen Zeichenfolgenschlüssel für die "Ereignisse" bereit, die sie abonnieren.
Wenn ein Ereignis ausgelöst wird, sendet die Ansicht oder das Modell eine Zeichenfolge an alle Abonnenten, die entscheiden, was für dieses Ereignis zu tun ist. Zum Beispiel in einer der Listener-Methoden für Ansichtenaktionen (ich glaube, dies setzt das bicycleMakeField nur auf das persistable-Objekt):
else if(evt.getSource() == bicycleMakeField)
{
myRegistry.updateSubscribers("BicycleMake", bicycleMakeField.getText());
}
Dieser Aufruf ruft schließlich diese Methode im Fahrzeugmodell auf:
public void stateChangeRequest(String key, Object value) {
... bunch of else ifs ...
else
if (key.equals("BicycleMake") == true)
{
... do stuff ...
Der Professor sagt, dass diese Art, Dinge zu tun, erweiterbarer und wartbarer ist, als wenn die Ansicht einfach eine Methode für ein Geschäftslogikobjekt aufruft. Er sagt, dass es keine Kopplung zwischen den Ansichten und Modellen gibt, weil sie nicht von der Existenz der anderen wissen.
Ich denke, dies ist eine schlechtere Art der Kopplung, da Ansicht und Modell die gleichen Zeichenfolgen verwenden müssen, um zu funktionieren. Wenn Sie eine Ansicht oder ein Modell entfernen oder einen Tippfehler in einer Zeichenfolge machen, werden keine Kompilierungsfehler angezeigt. Es macht den Code auch viel länger, als ich denke, dass es sein muss.
Ich möchte dies mit ihm besprechen, aber er nutzt seine Branchenerfahrung, um jedem Argument entgegenzuwirken, das ich als unerfahrener Student vorbringe. Hat sein Ansatz einen Vorteil, den ich vermisse?
Um dies zu verdeutlichen, möchte ich den obigen Ansatz mit der Tatsache vergleichen, dass die Sichtweise offensichtlich an das Modell gekoppelt ist. Sie können beispielsweise das Fahrzeugmodellobjekt an die Ansicht übergeben und anschließend die "Marke" des Fahrzeugs ändern:
vehicle.make = bicycleMakeField.getText();Dies würde 15 Codezeilen, die derzeit NUR verwendet werden, um die Marke des Fahrzeugs an einer Stelle festzulegen, auf eine einzige lesbare Codezeile reduzieren. (Und da diese Art von Operation hunderte Male in der gesamten App ausgeführt wird, wäre dies meiner Meinung nach ein großer Gewinn für die Lesbarkeit und Sicherheit.)
Aktualisieren
Mein Teamleiter und ich haben das Framework mithilfe der statischen Typisierung so umstrukturiert, wie wir es wollten, den Professor informiert und ihm schließlich eine Demo gegeben. Er ist so großzügig, dass wir unser Framework nutzen können, solange wir ihn nicht um Hilfe bitten und wenn wir den Rest unseres Teams auf dem Laufenden halten können - was uns fair erscheint.