Projekt Realisierung

[CrashKurs]

Hey Leute,

ich und ein paar Freunde von mir wollen ein Doppelkopf-Projekt in Java realisieren.
Ein paar Gedanken dazu haben wir uns schon gemacht:
-Das Spiel soll im Netzwerk/über Internet spielbar sein
-Die Ergebnisse jeder Spielrunde sollen in einer externen Datenbank gespeichert werden
-Der Server regelt die meisten Berechnungen/Anfragen etc.
-Der Client stellt alles graphisch dar und übermittelt Benutzeraktionen zum Server

Nun stehe ich vor zwei Problemen, und zwar:
1. Wie erstellt man ein solches, etwas größeres Projekt, sodass der Aufbau gut strukturiert ist?
(Ich arbeite bei einer größeren Firma, dort habe ich sehr viele abstrakte Klassen und Vorimplementierungen gesehen, wäre das der richtige Weg? Ich würde mich über ein paar Denkanstöße freuen)
2. Sollen die Hauptklassen als Singleton implementiert werden, sodass man sie überall über eine Utility-Klasse ansprechen kann. Meine Idee sah bis jetzt in etwa so aus:

public class DokoHelper {

    public static void init()
    {
        controller = new ControllerImpl().getInstance();
    }

    private static ControllerImpl controller;

    public static ControllerImpl getController()
    {
        return controller;
    }
}

public class ControllerImpl extends AbstractController {

    private static ControllerImpl controller = new ControllerImpl();

    public static ControllerImpl getInstance()
    {
        return controller.getInstance();
    }
}

Hier soll man dann über die Methode DokoHelper.getController() das Objekt ansprechen. Wäre das so am Besten oder gibt es andere Wege, wie man das realisieren könnte?

Freue mich über jede Hilfe, danke schonmal im vorraus!

Viele Grüße,
Crashkurs

 

[DarXun]

Guten Morgen,

zu deiner ersten Frage:

Es gibt keine tatsächliche "Lösung" wie man so ein Projekt strukturiert, das muss man selbst wissen.
Hier auch schon auf abstrakte Klassen oder Implementierungen einzugehen ist allerdings der falsche Ansatz. Es geht ja mehr um das Projektmanagement und die herangehensweise, nicht um die tatsächliche Implementierung.
Bei einem Projekt dieser Größe empfinde ich ein richtiges Projektmanagement aber eher als Overkill, einfach drauf los programmieren ist aber auch fast nie die richtige Lösung.
Meiner Meinung nach ist es sinnvoll, zuerst alle Bestandteile/Komponenten eurer Anwendung zu identifizieren (Ihr habt z.B. Clients und Server) und sich dann Gedanken darüber zu machen, wie diese Komponenten zueinander in Beziehung stehen.
Danach kann eine Softwarearchitektur geplant werden. Wie werden die verschiedenen Komponenten aufgebaut? Welche Technologien (Sprachen, Systeme) nutze ich für welche Komponenten? Und und und...

Wenn man das geschafft hat kann man sich auch wirklich Gedanken darüber machen, wie die Sachen implementiert werden sollten.

Es gibt aber nie DIE EINE BESTE Lösung, wie Ihr das machen solltet. Jede (Projekt-)Gruppe hat da eigene Ansätze und Herangehensweisen.


Zu deiner zweiten Frage:

Ich persönlich bin kein Fan von Singletons.
Viele Singletons zu nutzen zeugt eher von einer schlechten Architektur und stellt meiner Meinung nach einen "Schritt zurück" dar, da man damit ja von der Objektorientierung in Richtung prozedurale Programmierung geht. (Ist nur meine Meinung, will da niemandem ans Bein pinkeln..)

Abgesehen davon..
Wieso solltest du deine Hauptklassen als Singleton implementieren, sie DANN aber über Utility-Klassen ansprechen lassen?
Sprich: Welchen Mehrwert bringen dir die Utility-Klassen.

Dein Codebeispiel ist nicht wirklich nützlich und macht im Übrigen auch (Code-technisch) nicht viel Sinn.

 

[CrashKurs]

Hey,

erstmal Danke für deine Antwort, wir werden das dann wohl intuitiv machen, wie wir es für am Besten halten ;-)

Der Sinn hinter den Singletons war für uns eher, dass wir quasi keine Observer benötigen, um Änderungen in untergeordneten Objekten nach oben "bubbeln" zu lassen.
Die Utility-Klasse hat den Mehrwert eines Adapters, sodass wir dauerhaft die Methode DokoHelper.getController() verwenden können und nicht ControllerImpl.getInstance(), sodass man, falls die Klasse erweitert wird oder eventuell eine andere Klasse dafür eingebaut wird, nicht den gesamten Code ändern muss, sondern nur die Methoden im DokoHelper anpassen muss.
Kam uns zumindest recht schlüssig vor, dass so zu verwenden

Grüße,
Crashkurs

 

[DarXun]

Aber ein Observer ist doch total gut.
Da hat man eine klare Zugriffsstruktur und nicht so eine starke Kopplung.
Mit den vielen Singletons machst du ja genau das Gegenteil zu dem, was du mit den Utility-Klassen vor hast; da willst du ja eine lose Kopplung schaffen.
Mit den Singletons und dem nicht nutzen der Alternative (Observer/Observable) sind die Komponenten dann aber wieder stark gekoppelt.

Das mit dem Adapter kann ich wohl nachvollziehen. Wenn du aber schon sagst, dass es möglich sei, dass sich konkrete Implementierungen in Zukunft ändern können (ControllerImpl wird z.B. durch ControllerImpl2 ersetzt), dann würde ich aber auch entsprechende Schnittstellen vereinbaren und dann nur noch über die Interfaces darauf zugreifen (Eine Schnittstelle hast du ja mit AbstractController, du referenzierst aber immer nur ControllerImpl).

 

[CrashKurs]

Da hast du schon Recht, nur haben wir beispielsweise beim Server eine Klasse NetworkManager, die für jeglichen Autausch Server<->Client zuständig ist. In dieser Klasse haben wir eine Liste mit allen verbunden Clienten, jeder Client hat einen Thread fürs Nachrichten senden und einen fürs Nachrichten empfangen und empfangene Nachrichten sollen an eine andere Klasse (Controller) weitergeleitet werden, die diese Nachrichten dann aufs GUI oder auf die Datenbank anwendet.
Hatten uns das dann besser vorgestellt über Singletons, da wir ja sonst bei Observern eine Aufrufhierarchie hätten, die in etwa so aussieht: Controller->NetworkManager.setObserver->Client.setObserver->Empfangender Thread.setObserver

stattdessen haben wir im empfangenden Thread nur:
DokoHelper.getController().receiveMessage() bei ankommenden Nachrichten

Haben wir etwas übersehen, wodurch die Observer-Konstruktion besser wäre? ???:L

LG und danke für die Hilfe!
Crashkurs

 

[KSG9|sebastian]

Abgesehen davon das Singletons nicht für das gedacht seid für das ihr sie verwenden wollt ist dein Code dazu auch "kaputt".

Rufe ich 5x Controller#init auf habe ich 5 Instanzen davon. Zwar komme ich nur an die letzte ran, trotzdem existieren die anderen 4 unter Umständen noch irgendwo oder werden irgendwo referenziert.

Du willst Singletons einsetzen um von überall auf alles zugreifen zu können - genau das macht eine Architektur kaputt. Wenn Klassen miteinander kommunizieren dann mach das über Oberserver, Events (Listener - Publisch/Subscribe) o.ä. aber nicht über Singletons die dazu mißbraucht werden.

 

[DarXun]

Stimme meinem Vorredner vollkommen zu.

Ich verstehe halt auch nicht, wie du das ganze Konstrukt dem Observer/Observable-Pattern vorziehen kannst.
Denn, seien wir mal ehrlich, dass deine Aufrufhierarchie dadurch "lesbarer" erscheint(!), ist kein Grund die Architektur anders zu bauen. Ist ja auch nicht so, dass eben diese Aufrufe oft programmiert würden.

 

[fastjack]

Du brauchst dafür keine Singeletons. Was Du beschreibst ist ja eigentlich MVC und so müsst ihr es auch umsetzen. Habt ihr schonmal über Spring nachgedacht?