Was bedeutet "Implementierung vor dem Client verbergen" bei Design Patterns?

[NefetsClaxon]

Hallo!

Ich habe mir gerade das Brücke-Pattern angeguckt. Da geht es ja, wenn ich es richtig verstanden habe, darum, dass ein Client eine Abstraktion verwendet, die dann wiederum auf die Implementierung zugreift, d. h. der Client greift auf Klassen zu, die ihm sagen, WAS er da verwendet und diese Klassen rufen wiederum andere Klassen auf, in denen das "Was" dann umgesetzt wird.

Vorteil soll sein, dass die Implementierung vollständig von dem Client verborgen bleibt.

Jetzt meine Frage: Dieses "verborgen" bleiben, bezieht sich immer darauf, dass eine Klasse A keine Methoden oder Felder einer Klasse B aufrufen kann, höchstens indirekt?

D. h. wenn ich eine Implementierung vor dem Client verberge, dann heißt dass, dass der Client die Methoden, in der die Verarbeitungslogik stattfinden, nicht direkt aufrufen kann?

Ich bin etwas verwirrt, weil hier der Client ja immer noch wissen muss, dass es die Klasse CDSpieler gibt, also muss der Client ja schon noch was von der Implementierung wissen...

 

[kaoZ]

Was bedeutet "Implementierung vor dem Client verbergen" bei Design Patterns?

Um mich auf deinen Thread zu beziehen, bedeutet es das Klassen nicht direkt miteinander Kommunizieren, sonder Schnittstellen ( Interfaces ) verwenden , so muss der Aufrufer ( Client ) nicht wissen wie etwas umgesetzt worden ist, sondern nur das , die gewünschte Methode eben durch das implementieren der Schnittstelle vorhanden ist.

Anhand von Abstrakten Klassen :
Angenommen du hast die abstrakte Klasse Medium ,von welcher als Spezialisierung z.B die Klasse CD abgeleitet wird, und nehmen wir weiterhin an die Klasse Medium bietet eine abstrakte Methode getInfo(); dann sind alle Spezialisierungen der Klasse Medium dazu gezwungen , diese Methode zu implementieren.
Wie dann die Implementierung in den einzelnen Spezialisierungen aussieht, kann dem Aufrufer vollkommen egal sein, insofern dieser mit der Abstraktion, und oder einer vorhandenen Schnittstelle arbeitet.

Anhand von Schnittstellen:
Angenommen du hast das Interface Medium, welches von der Klasse CD implementiert wird, dann weist du quasi der Klasse CD eine Rolle zu, ergo ist einen CD ein Medium, wenn nun das Interface Medium die Methode getInfo(); anbietet, muss die Klasse CD logischerweise diese Implementieren, wie dann die Implementierung aussieht, ist wie bei der Abstrakten Klasse vollkommen irrelevant, insofern der Client mit der Abstraktion , also Medium arbeitet.

Hier mal vollkommen rudimentär :

Medium.java

public interface Medium{
	String getInfo();
}

CD.java

public class CD implements Medium{

	private String title;

	public CD(String t){
		title = t;
	}
	
//	hier wird die implementierung geliefert
	@Override
	public String getInfo(){
		return title;
	}
}

Client.java

public class Client{

	Medium medium;
	
	
	public Client(){}
	
	public void setMedium(Medium m){
		medium = m;
	}
		
	public static void main(String[] args){
		 Client c = new Client();
		 
		 c.setMedium(new CD("hello world revival"));
		 
//		 hier mit default Zugriffsmodifizierer ! ACHTUNG KAPSELLUNG !
		 System.out.println(c.medium.getInfo());
	}
}

Hier arbeitet der "Client" mit der Schnittstelle "Medium", dem Client ist vollkommen egal ob das Medium nun eine CD, ein USB Stick oder ein HDD ist, alle diese ggf. vorhandenen Spezialisierungen liefern insofern sie die Schnittstelle Medium erfüllen eine eigene Implementierung der Methoden getInfo();.

D. h. wenn ich eine Implementierung vor dem Client verberge, dann heißt dass, dass der Client die Methoden, in der die Verarbeitungslogik stattfinden, nicht direkt aufrufen kann?

Das heißt konkret das der Client nicht wissen muss wie etwas geschieht, sondern nur das es möglich ist dies auszuführen.

Gern auch als "It's Magic" bezeichnet ^^

Ähnlich kannst du dir z.B das Movement bei einer Spieleengine vorstellen, dir ist egal wie dein Character sich letzten endes Bewegt, du weißt als "Client" nur was du aufrufen musst das er sich bewegt, wie das dann Implementiert ist ist dir / kann dir vollkommen egal sein .

 

[NefetsClaxon]

Super, vielen Dank schon mal!

Was mir noch nicht genau klar ist. Wann "kennt" eine Klasse zu viel von einer anderen? Ich meine, wenn ich von einer Klasse eine Methode aufrufe, dann weiß ich ja auch nicht, was da intern passiert. Ich wieß nur, die Klasse hat diese Methode und erwartet die und die Parameter.

Dass man abstrakte Klasse und Interfaces wegen der Austauschbarkeit verwendet, okay, aber das mit dem "die Klasse kennt das 'wie'" ist mir noch nicht ganz klar. Ich sehe ja eigentlich nie, was in einer Methode direkt passiert...