{"id":1110,"date":"2016-07-26T16:15:54","date_gmt":"2016-07-26T14:15:54","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=1110"},"modified":"2020-09-21T11:45:14","modified_gmt":"2020-09-21T09:45:14","slug":"so-leicht-wie-eine-fliege","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/so-leicht-wie-eine-fliege\/","title":{"rendered":"So leicht wie eine Fliege"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

Weiter geht es mit unserer Reihe \u00fcber Entwurfsmuster, <\/em>heute mit einem weiteren Muster aus der Kategorie der Strukturmuster. <\/em>Wir schauen uns in diesem Artikel den Fliegengewicht <\/strong>(engl. Flyweight) an, der auch aus der Sammlung der Gang of Four stammt.<\/p>\n

Da fliege ich voll drauf<\/h1>\n

Das Entwurfsmuster Fliegengewicht ist im heutigen Alltag weiter verbreitet, als m\u00f6glicherweise viele vermuten. Bei diesem Muster geht es darum, ein Objekt mit hohem Ressourcenbedarf in zwei Teile zu gliedern. Ein Teil enth\u00e4lt dabei unver\u00e4nderliche Daten, welche von allen konkreten Auspr\u00e4gungen des zweiten Teils genutzt werden. Der zweite Teil enth\u00e4lt die spezifischen ver\u00e4nderlichen Daten eines konkreten Kontextes.<\/p>\n

Wie funktioniert das Fliegengewicht?<\/h1>\n

Stellen wir uns eine Webseite vor, auf der viele Bilder angezeigt werden und dabei auch einige Bilder mehrfach dargestellt werden. Wenn ein Bild – sagen wir – 5 mal auf der Seite angezeigt wird, wird es dieses Bild dann 5 mal runter geladen und im Speicher vorr\u00e4tig gehalten? Nein, das l\u00e4uft hier viel leichter. Jedes Bild, egal wie oft auf der Webseite dargestellt, wird nur einmal von der Quelle heruntergeladen und ist nur einmal im Speicher. Dies sind die unver\u00e4nderlichen Daten. Ver\u00e4nderlich hingegen ist die Position, an der das Bild angezeigt wird.<\/p>\n

Ein Beispiel zur Verdeutlichung<\/h1>\n

Schauen wir uns wie immer eine Beispielimplementierung an. Zun\u00e4chst ohne das Fliegengewicht Muster und anschlie\u00dfend wenden wir dieses Muster an und pr\u00fcfen die daraus resultierende Ver\u00e4nderung. Messen werden wir die Ver\u00e4nderung anhand des Speicherbedarfs der Testanwendung.<\/p>\n

Ein Schwergewicht<\/h2>\n

Erstellen wir eine Klasse f\u00fcr ein Bild mit Positionsangaben anhand von X- und Y-Koordinaten.<\/p>\n

@Data\n@Builder\npublic class PositionedImage {\n    private Image image;\n    private int positionX;\n    private int positionY;\n\n    public void print() {\n        \/\/ print image on specified position\n    }\n}<\/pre>\n
Bei diesen POJOs oder Entit\u00e4ten bietet sich wieder einmal die Verwendung von Projekt Lombok zur Generierung der \u00fcblichen Methoden an. Mehr dazu findet ihr im Artikel http:\/\/invidit.de\/blog\/lombok-macht-das-schon\/<\/a>.<\/p>\n
Das Bild muss von der Platte geladen werden womit sich die Erstellung von Objekten der Klasse PositionedImage<\/em> aufwendiger gestaltet. Aus diesen Grund bauen wir eine Fabrik, welche uns fertige Objekte baut.<\/p>\n
public class PositionedImageFactory {\n    public PositionedImage createPositionedImage(String pathToImage, int positionX, int positionY) {\n        BufferedImage image = null;\n        try {\n            image = ImageIO.read(this.getClass().getClassLoader().getResourceAsStream(pathToImage));\n        } catch (IOException e) {\n            System.out.println(\"Image not found\");\n        }\n        return PositionedImage\n                .builder()\n                .image(image)\n                .positionX(positionX)\n                .positionY(positionY)\n                .build();\n    }\n}<\/pre>\n
Wir \u00fcbergeben den Pfad zur Bilddatei und die beiden Koordinaten f\u00fcr die Positionierung. Das Bild wird geladen und das fertige Objekt zur\u00fcckgegeben. Konnte das Bild nicht geladen werden, bleibt es Null, was in diesem Beispiel v\u00f6llig in Ordnung ist.<\/p>\n
Zur \u00dcberpr\u00fcfung der Speichernutzung ben\u00f6tigen wir noch einen Berichterstatter. Dieser sieht wie folgt aus:<\/p>\n
public class MemoryUsageReporter {\n    private static final long MEGABYTE = 1024L * 1024L;\n\n    public void ReportTo(Consumer<String> reportTo) {\n        Runtime runtime = Runtime.getRuntime();\n        long memory = runtime.totalMemory() - runtime.freeMemory();\n        reportTo.accept(\"Used memory: \" + bytesToMegabytes(memory) + \" MB.\");\n    }\n\n    private long bytesToMegabytes(long bytes) {\n        return bytes \/ MEGABYTE;\n    }\n}<\/pre>\n
Dieser bekommt eine Methode, welche einen String<\/em> erwartet und gibt den aktuellen Speicherbedarf dort aus. Der Bedarf wird anhand der Runtime ermittelt und in MB umgerechnet.<\/p>\n
In einem Testprogramm f\u00fcr die Kommandozeile stecken wir alle Einzelteile zusammen und laden 100 Bilder in eine Liste. Vorher und nachher geben wir den Speicherbedarf auf die Konsole aus.<\/p>\n
public class MainWithNonFlyweight {\n    public static void main(String...args) {\n        MemoryUsageReporter memoryUsageReporter = new MemoryUsageReporter();\n        memoryUsageReporter.ReportTo(System.out::println);\n\n        List<PositionedImage> positionedImages = new ArrayList<>();\n        PositionedImageFactory positionedImageFactory = new PositionedImageFactory();\n\n        System.out.println(\"Loading 100 images.\");\n        for (int i = 0; i < 100; i++) {\n            ImagePosition imagePosition = ImagePosition.builder()\n                    .positionX(i)\n                    .positionY(i)\n                    .build();\n            PositionedImage positionedImage = positionedImageFactory.createPositionedImage(\"images\/Fliege.jpg\", imagePosition);\n            positionedImage.print();\n            positionedImages.add(positionedImage);\n        }\n        memoryUsageReporter.ReportTo(System.out::println);\n    }\n}<\/pre>\n
So weit zum Schwergewicht.<\/p>\n
Und jetzt mit Fliegengewicht<\/h2>\n
Zu Beginn trennen wir den Kontext vom Bild, welches in unserem Beispiel immer gleich bleibt. Dazu erstellen wir die Klasse ImagePosition<\/em>.<\/p>\n
@Data\n@Builder\npublic class ImagePosition {\n    private int positionX;\n    private int positionY;\n}<\/pre>\n
Das zuk\u00fcnftige Fliegenwicht, also unser Bild, wird \u00fcblicherweise gegen eine abstrakte Klasse oder eine Schnittstelle implementiert und erh\u00e4lt den jeweiligen Kontext. Wir erstellen dazu eine Schnittstelle FlyweightImage<\/em>.<\/p>\n
public interface FlyweightImage {\n    void print(ImagePosition imagePosition);\n}<\/pre>\n
Unser konkretes Fliegengewicht implementiert nun dieses Interface und enth\u00e4lt das Bild.<\/p>\n
@Data\n@Builder\npublic class PositionedFlyweightImage implements FlyweightImage {\n    private Image image;\n\n    @Override\n    public void print(ImagePosition imagePosition) {\n        \/\/ print image on specified position\n    }\n}<\/pre>\n
Auch in diesem Fall lassen wir eine Fabrik wieder die Arbeit zum Erstellen von Objekten der Klasse PositionedFlyweightImage<\/em> \u00fcbernehmen.<\/p>\n
public class PositionedFlyweightImageFactory {\n    private Map<String, PositionedFlyweightImage> stringImageMap = new HashMap<>();\n\n    public PositionedFlyweightImage createPositionedFlyweightImage(String pathToImage) {\n        PositionedFlyweightImage flyweightImage = this.stringImageMap.get(pathToImage);\n\n        if (flyweightImage == null) {\n            BufferedImage bufferedImage = null;\n            try {\n                bufferedImage = ImageIO.read(this.getClass().getClassLoader().getResourceAsStream(pathToImage));\n            } catch (IOException e) {\n                System.out.println(\"Image not found\");\n            }\n            flyweightImage = PositionedFlyweightImage\n                    .builder()\n                    .image(bufferedImage)\n                    .build();\n            this.stringImageMap.put(pathToImage, flyweightImage);\n        }\n        return flyweightImage;\n    }\n}<\/pre>\n
Jetzt k\u00f6nnte die Frage aufkommen „Warum hei\u00dft die Klasse denn PositionedFlyweightImageFactory<\/em>? Es wird doch keine Position gesetzt!“. Genau, die Position wird nicht direkt gesetzt, kommt aber sp\u00e4ter als Kontext des Bildes dazu. Da die Methode print()<\/em> der Klasse PositionedFlyweightImage<\/em> eben genau diesen Kontext erwartet.<\/p>\n
Die Besonderheit in dieser Fabrik ist eine HashMap mit bisher geladenen Bildern. Der Schl\u00fcssel ist dabei der vollst\u00e4ndige Dateipfad. Somit wird gew\u00e4hrleistet, dass jedes Bild einmalig geladen wird und nur ein einziges Objekt mit diesem Bild im Speicher existiert.<\/p>\n
Die Klasse f\u00fcr den Test des Fliegengewichts sieht sehr \u00e4hnlich zu der ersten Testklasse aus. Die Abweichung resultiert hierbei aus der Trennung der Position und des Bildes. Beide Informationen werden nun separat erzeugt und dann \u00fcber die Methode print()<\/em> kombiniert.<\/p>\n
public class MainWithFlyweight {\n    public static void main(String...args) {\n        MemoryUsageReporter memoryUsageReporter = new MemoryUsageReporter();\n        memoryUsageReporter.ReportTo(System.out::println);\n\n        List<PositionedFlyweightImage> positionedFlyweightImages = new ArrayList<>();\n        PositionedFlyweightImageFactory positionedFlyweightImageFactory = new PositionedFlyweightImageFactory();\n\n        System.out.println(\"Loading 100 images.\");\n        for (int i = 0; i < 100; i++) {\n            PositionedFlyweightImage positionedFlyweightImage = positionedFlyweightImageFactory.createPositionedFlyweightImage(\"images\/Fliege.jpg\");\n            ImagePosition imagePosition = ImagePosition.builder()\n                    .positionX(i)\n                    .positionY(i)\n                    .build();\n            positionedFlyweightImage.print(imagePosition);\n            positionedFlyweightImages.add(positionedFlyweightImage);\n        }\n\n        memoryUsageReporter.ReportTo(System.out::println);\n    }\n}<\/pre>\n
Und was bringt die Trennung nun tats\u00e4chlich?<\/p>\n
Ergebnisauswertung<\/h1>\n
Lasen wir die beiden Main-Klassen laufen und ein paar Objekte erzeugen. Ohne Fliegengewicht sehen wir auf der Konsole diese Speichernutzung:<\/p>\n
Used memory: 4 MB.\nLoading 100 images.\nUsed memory: 1727 MB.\n\nProcess finished with exit code 0<\/pre>\n
Wie ihr bei der Ausf\u00fchrung sicherlich bemerkt, dauert das Laden der 100 Bilder recht lange. Da nun 100 Bilder im Speicher gehalten werden ist auch die Speichernutzung entsprechend hoch.<\/p>\n
Werfen wir einen Blick auf die Speichernutzung mit dem Fliegengewicht.<\/p>\n
Used memory: 4 MB.\nLoading 100 images.\nUsed memory: 20 MB.\n\nProcess finished with exit code 0<\/pre>\n
Nicht nur die Ausf\u00fchrung geht deutlich schneller, sondern auch der Speicherverbrauch ist signifikant geringer. Warum? Durch die Entkopplung von geladenem Bild (internem Zustand) und der Position (externer Kontext) muss das Bild nur einmalig geladen werden. Wir kombinieren dies dann zur Laufzeit mit den verschiedenen Positionen. Gro\u00dfartig!<\/p>\n
Zusammenfassung<\/h1>\n
Wir haben uns das Entwurfsmuster Fliegengewicht angeschaut, mit dessen Hilfe der Ressourcenverbrauch von Software gesenkt werden kann. Die unver\u00e4nderlichen Bestandteile (interner Zustand) wird von den ver\u00e4nderlichen Daten (externer Kontext) getrennt und kann dann wiederverwendet werden. Dazu werden beide Teile zur Laufzeit kombiniert.<\/p>\n
Das Fliegengewicht Muster ist in gewisser Weise speziell. Wo seht ihr noch M\u00f6glichkeiten zum Einsatz dieses Musters?<\/p>\n
Eure Spa\u00df-Coder<\/p>\n
Dieser Artikel basiert neben unseren Erfahrungen auf den Ausf\u00fchrungen aus:<\/p>\n