Drlue: /* Multithreading */

2021-03-10T13:11:16Z

Multithreading

Drlue: Die Seite wurde neu angelegt: „'''Design Patterns''' oder '''Entwurfsmuster''' in der Softwareentwicklung sind Vorlagen für gewisse Problemstellungen. Sie geben keine konkrete Implementieru…“

2021-03-10T12:49:22Z

Die Seite wurde neu angelegt: „'''Design Patterns''' oder '''Entwurfsmuster''' in der Softwareentwicklung sind Vorlagen für gewisse Problemstellungen. Sie geben keine konkrete Implementieru…“

Neue Seite

'''Design Patterns''' oder '''Entwurfsmuster''' in der Softwareentwicklung sind Vorlagen für gewisse Problemstellungen. Sie geben keine konkrete Implementierung vor, sondern lediglich eine Beschreibung wie ein gegebenes Problem gelöst werden soll. '''Design Patterns''' sind formalisierte '''Best Practices''' die den Weg für die Lösung vorgeben.<ref>https://en.wikipedia.org/wiki/Software_design_pattern</ref>
'''Best Practices''', sind erprobte Lösungen. So löst man etwas am besten.
Folgender Inhalt bezieht sich weitestgehended auf <ref name='entwurfsmuster_von_kopf_bis_fuß'/>.
= Wichtige Entwurfsprinzipien =
Folgend sollen einige wichtige '''Designprinzipien''' erklärt werden. Werden diese angewendet, so kommt selbst ohne das Wissen über ein konkretes '''Design Pattern''' etwas ähnliches dabei raus.
==== Immer gegen eine Schnittstelle programmieren ====
Was bedeutet dies Konkret:
{{JML|code=
List<String> list = new ArrayList<>();
}}
Anstatt bei der Variable {{JSL|ArrayList<String>}} zu verwenden, wird das {{AL|Interface}} verwendet. Dies bietet später die Möglichkeit, die '''Implementierung''' der {{JSL|List<String>}} zu ändern, beispielsweise auf eine {{JSL|LinkedList<String>}}.
Wenn vom Programmieren gegen eine {{AL|Interface|Schnittstelle}} gesprochen wird, so kann es sich hierbei auch um eine {{AL|Abstrakte_Klasse|Abstrakte Klasse}} handeln, es muss nicht zwingend ein {{AL|Interface}} sein.

==== Komposition ist der Vererbung vorzuziehen ====
[[Objektorientierte_Programmierung#Has_A|Komposition]] ist '''viel flexibler''' als die [[Objektorientierte_Programmierung#Is_A|Vererbung]]. Dadurch ist es möglich das Verhalten zur Laufzeit zu verändern, dadurch bringt es mehr Flexibilität. 
'''Vererbung'''
{{JML|code=
public class Vehicle {
public void drive() {
System.out.println("I can drive");
}
}

public class Car extends Vehicle {

}
}}
In obigem Code ist ersichtlich, dass {{JSL|drive()}} zur Laufzeit nicht verändert werden kann. Dieser Code ist '''unflexibel'''. 
'''Komposition'''
{{JML|code=
public interface CanDrive {
public void drive();
}

public class DriveBehaviour {
public void drive() {
System.out.println("I can drive");
}
}

public class Car implements CanDrive {
private DriveBehaviour driveBehaviour = new DriveBehaviour();

@Override
public void drive() {
driveBehaviour.drive();
}

public void setDriveBehaviour(DriveBehaviour driveBehaviour) {
this.driveBehaviour = driveBehaviour;
}
}
}}
In genanntem Beispiel wurde nun {{JSL|drive()}} in eine eigene {{AL|Klasse}} {{JSL|DriveBehaviour}} ausgelagert. {{JSL|Car}} verwendet nun dieses Verhalten und es kann dynamisch getauscht werden.
Was hier ersichtlich ist, ist eigentlich eine Schmalspurvariante des '''Strategy Patterns'''

==== Offen für Erweiterung aber geschlossen für Veränderung ====
'''Code''' soll so geschrieben werden, dass er '''offen für Erweiterung''' ist, d.h. neue Funktionalität kann hinzugefügt werden. Gleichzeitig soll er jedoch '''geschlossen für Veränderung''' sein, das bedeutet, wenn neue Funktionalität hinzugefügt wird, soll so wenig wie möglich am bestehenden '''Code''' geändert werden müssen. 
Eine Schlussfolgerung die daraus getroffen werden kann:
Trenne Code der sich ändert, von Code der sich nicht ändert.

==== Lockere Kopplung ====
Wenn Objekte miteinander '''interagieren''' ist eine lockere Kopplung anzustreben. D.h. die interagierenden Objekte sind nicht fix miteinander verbunden und diese Verbindung kann zur Laufzeit geändert werden.

= Auswahl von Design Patterns =
Im folgenden wird auf eine Auswahl von '''Design Patterns''' eingegangen, wobei eines davon in Wirklichkeit überhaupt keines ist, nämlich die {{Link|Simple_Factory|Simple Factory}}.
== Observer ==
Das '''Observer-Muster''' definiert eine '''Eins-zu-viele-Abhängigkeit''' zwischen Objekten in der Art, dass alle abhängigen Objekte ('''Beobachter''') benachrichtigt werden, wenn sich der Zustand des einen Objekts ('''Subjekt - Beobachtetes Objekt''') verändert.
[[Datei:Observer.jpg|mini|ohne|600px|Beziehung zwischen Subjekt und Beobachtern<ref name="entwurfsmuster_von_kopf_bis_fuß"/>]]
Das '''Observer''' Pattern soll im Folgenden anhand des Beispiels einer Wetterstation veranschaulicht werden. Folgende {{AL|Klasse}} ist gegeben, welche die Möglichkeit bietet die Wetterdaten abzurufen. Diese könnten Beispielsweise aus einem '''S'''oftware '''D'''evelopment '''K'''it bzw. einer '''Bibliothek''' kommen:
{{JML|code=
public class WetterDaten {
public float getTemperature() { ... }
public float getLuftfeuchtigkeit() { ... }
public float getLuftdruck() { ... }
public void messwerteGeändert() {
//Wird aufgerufen wenn die Messwerte geändert wurden
}
}
}}
Es spielt im obigen Code Beispiel keine Rolle wie die Wetterdaten erzeugt werden, es ist nur sicher, dass die Methode {{JSL|messwerteGeändert()}} aufgerufen wird, sobald sich irgendein Wert geändert hat. Nun werden einige Anzeigen für die Wetterstation erstellt:
{{JML|code=
public class AktuelleBedingungenAnzeige {
public void aktualisieren(float temp, float humidity, float pressure) { ... }
}

public class VorhersageAnzeige {
public void aktualisieren(float temp, float humidity, float pressure) { ... }
}

public class StatistikAnzeige {
public void aktualisieren(float temp, float humidity, float pressure) { ... }
}
}}
In der {{AL|Klasse}} {{JSL|WetterDaten}} werden diese Anzeigen nun verwendet:
{{JML|code=
public class WetterDaten {
private AktuelleBedingungenAnzeige aktuelleBedingungenAnzeige = new AktuelleBedingungenAnzeige();
private StatistikAnzeige vorhersageAnzeige = new StatistikAnzeige();
private StatistikAnzeige statistikAnzeige = new StatistikAnzeige();

public float getTemperature() { ... }
public float getLuftfeuchtigkeit() { ... }
public float getLuftdruck() { ... }

public void messwerteGeändert() {
float temp = getTemperatur();
float feuchtigkeit = getLuftfeuchtigkeit();
float druck = getLuftdruck();

aktuelleBedingungenAnzeige.aktualisieren(temp, feuchtigkeit, druck);
vorhersageAnzeige.aktualisieren(temp, feuchtigkeit, druck);
statistikAnzeige.aktualisieren(temp, feuchtigkeit, druck);
}
}
}}
Der aktuelle Entwurf von {{JSL|WetterDaten}} weist im folgenden Abschnitt Probleme auf:
{{JML|highlight='1-3'|start=8|code=
aktuelleBedingungenAnzeige.aktualisieren(temp, feuchtigkeit, druck);
vorhersageAnzeige.aktualisieren(temp, feuchtigkeit, druck);
statistikAnzeige.aktualisieren(temp, feuchtigkeit, druck);
}}
* Dieser Teil kann sich ändern, wenn beispielsweise neue Anzeigen dazukommen, deswegen sollte der Code '''gekapselt''' werden. Siehe [[Design_Patterns#Offen_f.C3.BCr_Erweiterung_aber_geschlossen_f.C3.BCr_Ver.C3.A4nderung|Entwurfsprinzip]]
* Es wird gegen konkrete '''Implementierungen''' Programmiert nicht gegen eine '''Schnittstelle'''. Alle Anzeigen haben zwar die selbe {{JSL|aktualisieren(...)}} Methode, werden jedoch über die konkrete Implementierung angesprochen, die {{AL|Klasse|Klassen}} haben '''keine Gemeinsamkeit'''. Siehe [[Design_Patterns#Immer_gegen_eine_Schnittstelle_programmieren|Entwurfsprinzip]] 
Diese Probleme können mit dem '''Observer Pattern''' gelöst werden, weiters erhält man durch die [[Design_Patterns#Lockere_Kopplung|Lockere Kopplung]] des '''Musters''' den weiteren Vorteil, dass die '''Beobachter''' zur Laufzeit hinzugefügt und entfernt werden können:
[[Datei:Observer pattern.jpg|600px|mini|ohne]]
'''Beobachter''' können zur Laufzeit '''registriert''' und '''entfernt''' werden, dies bietet viel Flexibilität. Aus dem '''Muster''' leiten wir nun folgende '''Implementierung''' ab. (Der Einfachheit halber wird hier auf das {{AL|Interface}} {{JSL|Subjekt}} verzichtet):
{{JML|code=
public interface Beobachter {
public void aktualisieren(float temp, float humidity, float pressure);
}

public class AktuelleBedingungenAnzeige implements Beobachter {
public void aktualisieren(float temp, float humidity, float pressure) {
System.out.println("Das aktuelle Wetter: "+temp+"°C");
}
}

public class VorhersageAnzeige implements Beobachter {
public void aktualisieren(float temp, float humidity, float pressure) {
System.out.println("Das morgige Wetter: "+temp+"°C");
}
}

public class StatistikAnzeige implements Beobachter {
public void aktualisieren(float temp, float humidity, float pressure) {
System.out.println("Das durchschnittliche Wetter: "+temp+"°C");
}
}

public class WetterDaten {
private List<Beobachter> beobachter = new ArrayList<>();
private float temp, humidity, pressure;

//Damit man das ganze auch ausprobieren kann
public void setMessdaten(float temp, float humidity, float pressure) {
this.temp = temp;
this.humidity = humiditiy;
this.pressure = pressure;
aktualisiereBeobachter();
}

public float getTemperature() {
return temp;
}

public float getHumidity() {
return humiditiy;
}

public float getPressure() {
return pressure;
}

public void registriereBeobachter(Beobachter b) {
if(!beobachter.contains(b)) {
beobachter.add(b);
}
}

public void entferneBeobachter(Beobachter b) {
beobachter.remove(b);
}

public void aktualisiereBeobachter() {
float temp = getTemperatur();
float feuchtigkeit = getLuftfeuchtigkeit();
float druck = getLuftdruck();

for(Beobachter b : beobachter) {
aktuelleBedingungenAnzeige.aktualisieren(temp, feuchtigkeit, druck);
}
}
}
}}
Alle Anzeigen implementieren das {{AL|Interface}} {{JSL|Beobachter}}. {{JSL|WetterDaten}} hält eine Liste von '''Beobachtern'''. Im folgenden ersichtlich, die Verwendung der Wetterstation:
{{JML|code=
public static void main(String[] args) {
//Erstellen des Observables, hier muss die konkrete Implementierung für den Variablen Typ verwendet werden,
//da die Methode setMessdaten(...) benötigt wird
WetterDaten wetterDaten = new WetterDaten();

//Erstellen der Anzeigen
Beobachter aktuelleAnzeige = new AktuelleAnzeige();
Beobachter vorhersageAnzeige = new VorhersageAnzeige();
Beobachter statistikAnzeige = new StatistikAnzeige();

//Keine Beobachter vorhanden
wetterDaten.setMessdaten(10, 90, 1080);

//Alle Anzeigen werden registriert
wetterDaten.registriereBeobachter(aktuelleAnzeige);
wetterDaten.registriereBeobachter(vorhersageAnzeige);
wetterDaten.registriereBeobachter(statistikAnzeige);

//Aktuelle/Vorhersage und Statistik werden benachrichtigt
wetterDaten.setMessdaten(12, 60, 1080);

//Statistik wird entfernt
wetterDaten.entferneBeobachter(statistikAnzeige);

//Aktuelle und Vorhersage werden benachrichtigt
wetterDaten.setMessdaten(21, 99, 1020);
}
}}
Das finale '''UML Klassendiagramm''' obiger Implementierung sieht nun so aus:
[[Datei:Observer final.png|600px|mini|ohne|Finales UML Klassendiagramm der Implementierung]]
[[Datei:Observer final.dia.zip]]

== Simple Factory ==
Die '''Simple Factory''' kapselt die Erstellung von konkreten '''Instanzen''' einer {{AL|Interface|Schnittstelle}}, oder einer {{AL|Abstrakte_Klasse|Abstrakten Klasse}} und trennt sie vom restlichen Code. Die '''Simple Factory''' ist eigentlich kein '''Entwurfsmuster''', sondern eher ein Programmieridiom (konkrete Programmieranweisung). Die entsprechenden '''Design Patterns''', die auf der '''Simple Factory''' beruhen, sind das '''Factory Method Pattern''' und das '''Abstract Factory Pattern'''. 
Im Folgenden wird die '''Simple Factory''' anhand eines Beispiels erarbeitet: 
In einer Pizzeria werden Pizzas gemacht, diese werden '''belegt''', '''gebacken''', '''geschnitten''' und '''eingepackt'''. Dafür ist folgende {{AL|Klasse|Klasse}} gegeben:
{{JML|code=
public class Pizzeria {
public Pizza bestellePizza(String typ) {
Pizza pizza;
if(typ.equals("Salami")) {
pizza = new SalamiPizza();
} else if(typ.equals("Hawai")) {
pizza = new HawaiPizza();
} else if(typ.equals("Margherita")) {
pizza = new MargheritaPizza();
}

pizza.belegen();
pizza.backen();
pizza.schneiden();
pizza.einpacken();
return pizza;
}
}
}}
Im obigen Code wird anhand des Pizza Typs, die konkrete {{AL|Klasse}} instanziert. {{JSL|Pizza}} kann entweder ein {{AL|Interface}} oder eine {{AL|Abstrakte_Klasse|Abstrakte Klasse}} sein, damit sie '''nicht direkt instanziert''' werden kann, da eine unkonkrete {{JSL|Pizza}} keinen Sinn macht. Die aktuelle Implementierung der Pizzeria hat leider eine Schwachstelle, wird eine neue Pizza hinzugefügt, so muss der Code geändert werden.
{{JML|start='8'|highlight='3-5'|code=
} else if(typ.equals("Margherita")) {
pizza = new MargheritaPizza();
} else if(typ.equals("Vegetariana")) {
pizza = new VegetarianaPizza();
}

pizza.belegen();
...
}}
Nun verletzt das ganze folgendes '''Design Prinzip''' [[Design_Patterns#Offen_f.C3.BCr_Erweiterung_aber_geschlossen_f.C3.BCr_Ver.C3.A4nderung|Offen für Erweiterung aber geschlossen für Veränderung]]. Um dies zu beheben wird der Code der sich ändert, vom Code der sich nicht ändert getrennt. 
'''Kann sich ändern:'''
{{JML|start='4'|code=
if(typ.equals("Salami")) {
pizza = new SalamiPizza();
} else if(typ.equals("Hawai")) {
pizza = new HawaiPizza();
} else if(typ.equals("Margherita")) {
pizza = new MargheritaPizza();
}
}}
'''Ändert sich nicht, selbst wenn neue Pizzen hinzugefügt werden:'''
{{JML|start='12'|code=
pizza.belegen();
pizza.backen();
pizza.schneiden();
pizza.einpacken();
return pizza;
}}
Um den Code zu trennen, erstellen wir eine {{JSL|PizzaFabrik}} und verwenden dann in der {{JSL|Pizzeria}} diese '''Fabrik''':
{{JML|code=
public class PizzaFactory {
public Pizza createPizza(String typ) {
Pizza pizza;
if(typ.equals("Salami")) {
pizza = new SalamiPizza();
} else if(typ.equals("Hawai")) {
pizza = new HawaiPizza();
} else if(typ.equals("Margherita")) {
pizza = new MargheritaPizza();
}
return pizza;
}
}

public class Pizzeria {
private PizzaFabrik fabrik;

public Pizzeria(PizzaFabrik fabrik) {
this.fabrik = fabrik;
}

public Pizza bestellePizza(String typ) {
Pizza pizza = fabrik.createPizza(typ);

pizza.belegen();
pizza.backen();
pizza.schneiden();
pizza.einpacken();
return pizza;
}
}}
Somit ist der Code nun '''geschlossen für Veränderung''', aber '''offen für Erweiterung'''. Kommt eine neue Pizza Sorte hinzu, so muss natürlich der Code in der {{JSL|PizzaFactory}} geändert werden, in der {{JSL|Pizzeria}} jedoch nicht mehr.
[[Datei:Simple factory.jpg|mini|none|600px|Simple Factory<ref name='entwurfsmuster_von_kopf_bis_fuß'>Entwurfsmuster von Kopf bis Fuß</ref>]]
=== Anmerkung ===
Weiters sei angemerkt, das '''Simple Factory''' Pattern, findet man ganz oft in seiner Ausprägung als '''Static Factory'''. Das bedeutet, die {{AL|Methoden|Methode}} zur Erstellung der '''Instanzen''' ist '''statisch''':
{{JML|code=
public static createPizza(String type) {
...
}
}}
Der Vorteil der daraus resultiert ist, es muss keine '''Instanz''' der '''Factory''' erstellt werden. Der Nachteil ist, dass die '''Factory Methode''' nicht durch Vererbung geändert werden kann. Folgendes wäre ein Beispiel, wie durch {{AL|Vererbung}} eine weitere '''Factory''' erstellt wird:
{{JML|code=
public class LockDownPizzaFactory extends PizzaFactory {
public Pizza createPizza(String type) {
//It's Lockdown, only Margherita
return new MargheritaPizza();
}
}
}}
Oder ein weiteres super Beispiel durch Vererbung:
{{JML|code=
public class FaschingPizzaFactory extends PizzaFactory {
public Pizza createPizza(String type) {
//In 50% der Fälle wird Margherita anstatt der gewünschten Pizza geliefert HAHAHA
if(Math.random() > 0.5) {
return new MargheritaPizza();
} else {
super.createPizza(type);
}
}
}
}}

== Singleton ==
Das '''Singleton Pattern''' garantiert, dass von einer {{AL|Klasse}} nur eine '''Instanz''' erstellt werden kann.
Warum kann dies wichtig sein? Oft sind verschiedene Programmteile von einer einzelnen '''Instanz''' einer {{AL|Klasse}} abhängig. Beispiele hierfür wären:
* Caches
* API Schnittstellen Anbindung
* ImageLoader
* Einstellungsspeicher
* ...
Anhand eines '''ImageLoaders''' zum Anzeigen von Bildern aus dem Internet, soll das '''Singleton Pattern''' erläutert werden. Verschiedene Screens einer Anwendung laden Bilder und verwenden dazu die selbe {{AL|Klasse}}. Der '''ImageLoader''' selbst hat für die Bilder die übers Internet geladen zwei Arten von '''Caches''':
* '''Memory Cache''' - Bilder werden nach dem Laden im Arbeitsspeicher gespeichert
* '''Disk Cache''' - Bilder werden nach dem Laden auf dem internen Speicher gespeichert
Jede '''Instanz''' des '''ImageLoaders''' hat einen eigenen '''Memory Cache'''. Wenn nun von einer Applikation mehrere '''Instanzen''' des '''ImageLoaders''' verwendet werden, so führt dies dazu, dass die Bilder immer über den langsameren '''Disk Cache''' geladen werden müssen, was nicht erstrebenswert ist. Dies soll anhand folgender {{AL|Klasse}} veranschaulicht werden:
{{JML|code=
public class ImageLoader {
private Map<String, byte[]> imageCache = new HashMap<>;

public byte[] getImage(String imageUrl) {
if(imageCache.contains(imageUrl)) {
return imageCache.get(imageUrl);
} else {
byte[] image = loadFromDisk(imageUrl);
imageCache.put(imageUrl, image);
return image;
}
}

private byte[] loadFromDisk(imageUrl) {
//Zuerst prüfen ob auf internem Speicher vorhanden, ansonsten übers Netzwerk abrufen
...
return image;
}
}
}}
Wenn nun jeder Teil des Programmes eine eigene '''Instanz''' des {{JSL|ImageLoader}} verwendet, so existiert auch für jede '''Instanz''' ein eigener '''Memory Cache''':
{{JML|start=2|code=
private Map<String, byte[]> imageCache = new HashMap<>;
}}
Wie kann nun das Design der {{AL|Klasse}} {{JSL|ImageLoader}} verändert werden, dass immer die selbe '''Instanz''' zurückgegeben wird? 
Dem {{JSL|ImageLoader}} wird ein {{AL|Klassenattribut}}, welches eine '''Referenz''' auf die einzige '''Instanz''' von {{JSL|ImageLoader}} speichert, hinzugefügt. Weiters wird eine {{AL|Klassenmethode}} erstellt, welche die '''Instanzierung''' übernimmt.
{{JML|start=2|highlight='3-10'|code=
private Map<String, byte[]> imageCache = new HashMap<>;

private static ImageLoader imageLoaderInstance;

public static ImageLoader getInstance() {
if(imageLoaderInstance == null) {
imageLoaderInstance = new ImageLoader();
}
return imageLoaderInstance;
}

public byte[] getImage(String imageUrl) {
}}
Nun besteht die Möglichkeit, aus jedem Bereich der Anwendung über {{JSL|ImageLoader.getInstance()}} die eine und wahre Instanz von {{JSL|ImageLoader}} zu erhalten. Jetzt gibt es leider noch ein kleines Problem, {{JSL|ImageLoader}} kann immer noch direkt über {{JSL|new ImageLoader();}} instanziert werden, was erneut zu unerwünschtem Verhalten führen kann. D.h. es besteht die Möglichkeit, dass der {{JSL|ImageLoader}} richtig verwendet wird, dazu wird man aber nicht gezwungen.
Code sollte immer so entworfen werden, dass die korrekte Verwendung forciert wird.
Wie kann nun verhindert werden, dass außerhalb der {{AL|Klasse}} {{JSL|ImageLoader}} der {{AL|Konstruktor}} von {{JSL|ImageLoader}} aufgerufen wird? Sehr einfach, ein verändern der {{AL|Sichtbarkeit}} des {{AL|Konstruktor|Konstruktors}} führt zum gewünschten Ergebnis. 
Der {{JSL|ImageLoader}} besitzt aktuell den '''default Konstruktor''', der nicht zwingend geschrieben werden muss:
{{JML|highlight='2-3'|code=
public class ImageLoader {
public ImageLoader() {
}
}
}}
Nun wird die {{AL|Sichtbarkeit}} geändert:
{{JML|highlight='2'|code=
public class ImageLoader {
private ImageLoader() {
}
}
}}
Somit ist nur noch eine '''Instanzierung''' über die {{AL|Klasse}} selbst möglich. 
Der abgeschlossene '''Singleton''' sieht nun wie folgt aus:
{{JML|code=
public class ImageLoader {
private Map<String, byte[]> imageCache = new HashMap<>;
private static ImageLoader imageLoaderInstance;

private ImageLoader() {
}

public static ImageLoader getInstance() {
if(imageLoaderInstance == null) {
imageLoaderInstance = new ImageLoader();
}
return imageLoaderInstance;
}

public byte[] getImage(String imageUrl) {
if(imageCache.contains(imageUrl)) {
return imageCache.get(imageUrl);
} else {
byte[] image = loadFromDisk(imageUrl);
imageCache.put(imageUrl, image);
return image;
}
}

private byte[] loadFromDisk(imageUrl) {
//Zuerst prüfen ob auf internem Speicher vorhanden, ansonsten übers Netzwerk abrufen
...
return image;
}
}
}}
=== Multithreading ===
Wird nun der {{JSL|ImageLoader}} im Kontext von {{AL|Multithreading}} betrachtet, d.h. das Programm greift über verschiedene {{AL|Multithreading|Threads}} auf den {{JSL|ImageLoader}} zu, so ergibt sich ein Problem. Im folgenden ist der kritische Bereich des '''Singleton''' zu sehen:
{{JML|start=8|highlight='2-3'|code=
public static ImageLoader getInstance() {
if(imageLoaderInstance == null) {
imageLoaderInstance = new ImageLoader();
}
return imageLoaderInstance;
}
}}
Wird von mehreren verschiedenen {{AL|Multithreading|Threads}} der Bereich in ''Zeile 10'' gleichzeitig betreten (solange noch keine '''Instanz''' erstellt wurde), so können wieder mehrere '''Instanzen''' erstellt werden. Zwar wird nur die letzte '''Instanz''' gespeichert und auch bei erneutem Aufruf zurückgegeben, jedoch können mehrere '''Instanzen''' im Umlauf sein. Dieses Problem kann über {{AL|Synchronisierung}} gelöst werden:
{{JML|start=8|code=
public static synchronized ImageLoader getInstance() {
...
}
}}
Weiters sollte zusätzlich die {{AL|Methoden|Methode}} {{JSL|getImage(...)}} {{AL|Synchronisierung|synchronisiert}} werden. Wird das gleiche Bild aus unterschiedlichen {{AL|Multithreading|Threads}} geladen, so kann dies dazu führen, dass es zweimal geladen wird, was aber nicht nötig wäre:
{{JML|start=8|code=
public synchronized byte[] getImage(String url) {
...
}
}}
Mit dem '''Schlüsselwort''' {{JSL|synchronized}} kommt immer ein '''Performanceverlust''' einher. Deswegen sollte genau abgewägt werden ob und wann es verwendet werden soll. In diesem Beispiel ist es vollkommen in Ordnung, da die Aufrufe der {{AL|Synchronisierung|synchronisierten}} {{AL|Methoden}} nicht 10000x pro Sekunde sein werden.

← Nächstältere Version		Version vom 10. März 2021, 13:11 Uhr
Zeile 454:		Zeile 454:
	Wird nun der {{JSL\|ImageLoader}} im Kontext von {{AL\|Multithreading}} betrachtet, d.h. das Programm greift über verschiedene {{AL\|Multithreading\|Threads}} auf den {{JSL\|ImageLoader}} zu, so ergibt sich ein Problem. Im folgenden ist der kritische Bereich des '''Singleton''' zu sehen:		Wird nun der {{JSL\|ImageLoader}} im Kontext von {{AL\|Multithreading}} betrachtet, d.h. das Programm greift über verschiedene {{AL\|Multithreading\|Threads}} auf den {{JSL\|ImageLoader}} zu, so ergibt sich ein Problem. Im folgenden ist der kritische Bereich des '''Singleton''' zu sehen:
	{{JML\|start=8\|highlight='2-3'\|code=		{{JML\|start=8\|highlight='2-3'\|code=
	public static ImageLoader getInstance() {		public static ImageLoader getInstance() {
	if(imageLoaderInstance == null) {		if(imageLoaderInstance == null) {
	imageLoaderInstance = new ImageLoader();		imageLoaderInstance = new ImageLoader();
	}
	~~return imageLoaderInstance~~;
	}		}
			return imageLoaderInstance;
			}
	}}		}}
	Wird von mehreren verschiedenen {{AL\|Multithreading\|Threads}} der Bereich in ''Zeile 10'' gleichzeitig betreten (solange noch keine '''Instanz''' erstellt wurde), so können wieder mehrere '''Instanzen''' erstellt werden. Zwar wird nur die letzte '''Instanz''' gespeichert und auch bei erneutem Aufruf zurückgegeben, jedoch können mehrere '''Instanzen''' im Umlauf sein. Dieses Problem kann über {{AL\|Synchronisierung}} gelöst werden:		Wird von mehreren verschiedenen {{AL\|Multithreading\|Threads}} der Bereich in ''Zeile 10'' gleichzeitig betreten (solange noch keine '''Instanz''' erstellt wurde), so können wieder mehrere '''Instanzen''' erstellt werden. Zwar wird nur die letzte '''Instanz''' gespeichert und auch bei erneutem Aufruf zurückgegeben, jedoch können mehrere '''Instanzen''' im Umlauf sein. Dieses Problem kann über {{AL\|Synchronisierung}} gelöst werden:
	{{JML\|start=8\|code=		{{JML\|start=8\|code=
	public static synchronized ImageLoader getInstance() {		public static synchronized ImageLoader getInstance() {
	...		...
	}		}
	}}		}}
	Weiters sollte zusätzlich die {{AL\|Methoden\|Methode}} {{JSL\|getImage(...)}} {{AL\|Synchronisierung\|synchronisiert}} werden. Wird das gleiche Bild aus unterschiedlichen {{AL\|Multithreading\|Threads}} geladen, so kann dies dazu führen, dass es zweimal geladen wird, was aber nicht nötig wäre:		Weiters sollte zusätzlich die {{AL\|Methoden\|Methode}} {{JSL\|getImage(...)}} {{AL\|Synchronisierung\|synchronisiert}} werden. Wird das gleiche Bild aus unterschiedlichen {{AL\|Multithreading\|Threads}} geladen, so kann dies dazu führen, dass es zweimal geladen wird, was aber nicht nötig wäre:
	{{JML\|start=8\|code=		{{JML\|start=8\|code=
	public synchronized byte[] getImage(String url) {		public synchronized byte[] getImage(String url) {
	...		...
	}		}
	}}		}}
	Mit dem '''Schlüsselwort''' {{JSL\|synchronized}} kommt immer ein '''Performanceverlust''' einher. Deswegen sollte genau abgewägt werden ob und wann es verwendet werden soll. In diesem Beispiel ist es vollkommen in Ordnung, da die Aufrufe der {{AL\|Synchronisierung\|synchronisierten}} {{AL\|Methoden}} nicht 10000x pro Sekunde sein werden.		Mit dem '''Schlüsselwort''' {{JSL\|synchronized}} kommt immer ein '''Performanceverlust''' einher. Deswegen sollte genau abgewägt werden ob und wann es verwendet werden soll. In diesem Beispiel ist es vollkommen in Ordnung, da die Aufrufe der {{AL\|Synchronisierung\|synchronisierten}} {{AL\|Methoden}} nicht 10000x pro Sekunde sein werden.

Design Patterns - Versionsgeschichte

Drlue: /* Multithreading */

Drlue: Die Seite wurde neu angelegt: „'''Design Patterns''' oder '''Entwurfsmuster''' in der Softwareentwicklung sind Vorlagen für gewisse Problemstellungen. Sie geben keine konkrete Implementieru…“