Java server socket?

1 Antwort

Also ich versuche mal zu deuten, was du eigentlich möchtest. Ein wenig mehr Hintergrund wäre schon hilfreich gewesen.

Es gibt einen Server und du willst eine Verbindung zwischen deiner App, die einen Client darstellt, und dem Server aufbauen. Hierfür verwendest du Sockets. Ich gehe nehme jetzt mal TCP an. Die App (dein Client) ist in Java geschrieben. Den Server schreibst du wahrscheinlich auch selbst - vielleicht nimmst du hier auch Java, aber ist eigentlich auch egal. Ich gehe jetzt mal von so einem einfachen "Echo-Szenario" aus, wo du irgendwas von deinem Client zum Server schickst und der Server schickt es dir zurück. Falls du noch kein Szenario hast, dann bau doch sowas nach. Im Internet findest du haufenweise Guides zu solchen Sachen, d.h. da findest du genug Inspiration. Ich versuche jetzt eher auf die "grobe Strategie" einzugehen - also eine Art Lösungsentwurf. Ich werde auch vom Level eines "Hobbylernprojekt" eines eher Anfängers ausgehen, daher halten wir es einfach. Ich hab schon länger kein Java mehr gemacht, aber ein paar Tipps kann ich dir ggf. geben.

Zunächstmal hast du gesagt "... müssen viele verschiedene Klassen auf die Serververbindung zugreifen, da nicht jede Klasse ihre eigene Server Verbindung halten soll". Dass nicht jede Klasse Ihre eigene Verbindung halten soll, finde ich erstmal gut.
Eigentlich ist es aber (eher) eine Instanz der Klasse ("ein Objekt"), die die Verbindung zum Server halten würde, aber ich bin sicher, dass du das meinst. Man könnte die Vorgehensweise als gut verstehen, weil es "etwas mit der Verantwortung" gibt, dass sich mit der Verbindung beschäftigt (und ggf. mit wenigen Sachen "drumherum"). Aber jetzt zum Thema "... müssen viele verschiedene Klassen auf die Serververbindung zugreifen". Naja eigentlich müssen das nicht viele machen. Gegebenenfalls reicht es, wenn es genau einen gibt, der "das Ding" benutzt.
Angenommen du hast eine Klasse, die die Main-Methode implementiert.
In dieser Main-Methode könntest du doch dein Client-Objekt instanziieren, d.h. du könntest bspw. einmalig einen "EchoClient" erzeugen. Dieser Client bietet beispielsweise eine "SendMessage"-Methode an, die du dann aufrufen kannst. Die Methode könnte als Ergebnis die Antwort vom Server als String zurückgeben.

Falls dir das noch nicht genug ist: Der EchoClient könnte ein Interface implementieren, dass den Kontrakt vorgibt. D.h. hier wird den implementierenden Klassen auch die genannte "SendMessage"-Methode vorgeschrieben. Wenn du in deiner Main-Methode das Objekt instanziierst, dann kannst du auf "der linken Seite" das Interface verwenden und auf "der rechten Seite" verwendest du den Konstruktor der Klasse. Jetzt könnte es eine weitere Klasse geben, die vielleicht Nachrichten senden soll und diese auch auf der Konsole loggt. D.h. dieser Klasse könnte in ihrem Konstruktor das Interface des "EchoClient" erwarten. In der Main-Methode erzeugst du also zuerst den EchoClient. Im Anschluss erzeugst du eine Instanz der anderen Klasse und übergibst ihr den EchoClient. Deren Methode "SendAndLog" kannst du dann z.B. aus der Main-Methode verwenden. Die "SendAndLog"-Methode kann ihrerseits dann die "SendMessage" aus dem "EchoClient" verwenden und das erhaltene Ergebnis einfach nur loggen. (Sie hat also die Verantwortlichkeit das Senden via "EchoClient" zu "steuern" und das Ergebnis zu loggen.)

Es gäbe auch "...einen Weg von überall auf dieses Objekt zugreifen zu können", aber das ist ziemlich sicher etwas, was du eigentlich nicht machen möchtest. Natürlich könntest du den besagten Echoclient als statisches Feld der Main-Klasse deklarieren (und einmalig instanziieren) und von beliebig vielen Klassen darauf zugreifen. Wenn du es testen willst, dann probier es aus, aber die Lösung ist nicht optimal. Schau dir in Zukunft auch mal an, wie man sich per "Dependency Injection" Abhängigkeiten übergeben lässt. Das Beschriebene wird durch die Verwendung von (modernen) Frameworks vereinfacht. Im gleichen Atemzug schau dir auch mal das "Single Responsibility Principle" an, dann wird vielleicht auch klar, warum man nicht alles von überall machen können sollte (auch wenn es technisch vielleicht ginge).