Das Fliegengewicht (englisch flyweight pattern) ist eine bewährte, wiederverwendbare Lösungsschablone in der Softwareentwicklung und gehört als Vorlage zu den Problemen aus der Kategorie Strukturmuster (structural patterns). Die allgemeineren Entwurfsmuster und auch diese Schablone für Beziehungen zwischen gleichartigen Objekten stammen aus dem Buch Entwurfsmuster der „Gang of Four“ (GoF), das Techniken der Objektorientierten Programmierung erklärt.

Das Fliegengewicht wird eingesetzt, wenn eine große Anzahl gleichartiger Objekte benötigt wird, die variable Informationen teilen. Eine klassische Implementierung würde unverhältnismäßig viel Speicherkapazität erfordern^[1] und zu Problemen während der Laufzeit führen. Ein Teil des Zustands dieser Objekte kann in den Kontext ausgelagert werden, und zwar auf eine extrinsische Art, von außen her angeregt. Nach der Entfernung des Zustands reduziert sich die Anzahl verschiedener Objekte auf ein überschaubares Maß.

Dieses Diagramm in der Unified Modeling Language (UML) zeigt die Beziehung von einem Kunden (Klient) über die „Fabrik“ bis zum Fliegengewicht.

Die einzelnen Elemente sind:

• Der Klient (client) verwaltet Referenzen auf Fliegengewichte und den extrinsischen Zustand der Fliegengewichte.

• Die Fliegengewicht-Fabrik (flyweight factory) erzeugt und verwaltet Fliegengewichte. Sie stellt die korrekte Benutzung der gemeinsam benutzten Objekte sicher.

• Das Fliegengewicht ist eine Abstrakte Klasse und definiert die Schnittstelle für Objekte, die einen von außen sichtbaren Zustand empfangen und verarbeiten.

• Das Konkrete-Fliegengewicht (concrete flyweight) implementiert die Fliegengewichtschnittstelle. Bei Bedarf wird ein innerer Zustand ergänzt. Exemplare von KonkretesFliegengewicht oder abgeleiteten Klassen werden gemeinsam genutzt. Der intrinsische Zustand muss unabhängig vom Kontext sein.

• Das Getrennt-Genutzte-Konkrete-Fliegengewicht (unshared concrete flyweight) implementiert diese Schnittstelle ebenfalls, enthält allerdings den kompletten Zustand. Das bedeutet, dass diese Objekte nicht gemeinsam genutzt werden. Hierbei handelt es sich nicht mehr im engeren Sinne um Fliegengewichte. Es können sich sogar echte „Schwergewichte“ dahinter verbergen. Es zeigt vielmehr die Stelle, an der „normale“ Objekte ihren Platz in dem Muster finden.

Das Verfahren reduziert Speicherkosten proportional zur Größe des ausgelagerten Zustands und zur Anzahl der Fliegengewichte. Die Speicherkosten sinken weiter, wenn der ausgelagerte Zustand nicht gespeichert werden muss, sondern berechnet werden kann.

Anderseits steigt die Komplexität relativ stark,^[2] insbesondere bei Designs, die Fliegengewicht gemeinsam mit Kompositum nutzen. Eine saubere Dokumentation der Verantwortlichkeiten ist ein Muss. Die Laufzeitkosten steigen an, da der ausgelagerte Zustand wieder aufgefunden und dem Fliegengewicht beim Methodenaufruf übergeben werden muss. Sie steigen weiter, wenn der Zustand berechnet wird.

Ein Beispiel ist die grafische Darstellung eines Textdokumentes, das leicht aus Hunderttausenden oder gar Millionen von Zeichen und damit Zeichenobjekten bestehen kann. Jedes Byte im Zeichenobjekt wird unter Umständen zu einem Megabyte. Es ist inakzeptabel, alle Informationen, die das Zeichenobjekt benötigt, wirklich im Objekt zu speichern.

Das Zeichenobjekt befindet sich in einem Zeilenobjekt (Kompositum). Die Zeilennummer und die Y-Koordinate auf dem Bildschirm sind für alle Zeichen der Zeile identisch. Sie werden in das Zeilenobjekt verlagert. Die Spaltennummer und die X-Koordinate ergeben sich aus der Position in der Zeile. Das Zeilenobjekt ist verantwortlich, diese zu berechnen. Schriftattribute sind meist für benachbarte Zeichen identisch. Sie werden ebenfalls ausgelagert.

Übrig bleibt alleine der Code des Zeichens. Somit gibt es am Ende lediglich einige hundert unterschiedlicher Zeichenobjekte, zumindest bei Alphabetschriften.

Der typische Code in der Programmiersprache Java für die Abrechnung an einer Kaffeebar enthält folgende Elemente:

// Flyweight object interface
public interface CoffeeOrder {
    void serveCoffee(CoffeeOrderContext context);
}
// ConcreteFlyweight object that creates ConcreteFlyweight
public class CoffeeFlavor implements CoffeeOrder {
    private String flavor;

    public CoffeeFlavor(String newFlavor) {
        this.flavor = newFlavor;
    }
    public String getFlavor() {
        return this.flavor;
    }
    public void serveCoffee(CoffeeOrderContext context) {
        System.out.println("Serving Coffee flavor " + flavor + " to table number " + context.getTable());
    }
}
public class CoffeeOrderContext {
   private int tableNumber;

   public CoffeeOrderContext(int tableNumber) {
       this.tableNumber = tableNumber;
   }
   public int getTable() {
       return this.tableNumber;
   }
}
import java.util.HashMap;
import java.util.Map;

//FlyweightFactory object
public class CoffeeFlavorFactory {
    private Map<String, CoffeeFlavor> flavors = new HashMap<String, CoffeeFlavor>();

    public CoffeeFlavor getCoffeeFlavor(String flavorName) {
        CoffeeFlavor flavor = flavors.get(flavorName);
        if (flavor == null) {
            flavor = new CoffeeFlavor(flavorName);
            flavors.put(flavorName, flavor);
        }
        return flavor;
    }
    public int getTotalCoffeeFlavorsMade() {
        return flavors.size();
    }
}
public class TestFlyweight {
   /** The flavors ordered. */
   private static CoffeeFlavor[] flavors = new CoffeeFlavor[100];
   /** The tables for the orders. */
   private static CoffeeOrderContext[] tables = new CoffeeOrderContext[100];
   private static int ordersMade = 0;
   private static CoffeeFlavorFactory flavorFactory;

   public static void takeOrders(String flavorIn, int table) {
       flavors[ordersMade] = flavorFactory.getCoffeeFlavor(flavorIn);
       tables[ordersMade++] = new CoffeeOrderContext(table);
   }
   public static void main(String[] args) {
       flavorFactory = new CoffeeFlavorFactory();
      /** Durch Zwischenspeicherung der Geschmäcker in einer HashMap in der Factory wird jeweils nur ein Objekt des gleichen Geschmacks erzeugt und damit Speicherplatz gespart. */
       takeOrders("Cappuccino", 2);
       takeOrders("Cappuccino", 2);
       takeOrders("Frappe", 1);
       takeOrders("Frappe", 1);
       takeOrders("Xpresso", 1);
       takeOrders("Frappe", 897);
       takeOrders("Cappuccino", 97);
       takeOrders("Cappuccino", 97);
       takeOrders("Frappe", 3);
       takeOrders("Xpresso", 3);
       takeOrders("Cappuccino", 3);
       takeOrders("Xpresso", 96);
       takeOrders("Frappe", 552);
       takeOrders("Cappuccino", 121);
       takeOrders("Xpresso", 121);

       for (int i = 0; i < ordersMade; ++i) {
           flavors[i].serveCoffee(tables[i]);
       }
       System.out.println(" ");
       System.out.println("total CoffeeFlavor objects made: " +  flavorFactory.getTotalCoffeeFlavorsMade());
   }
}

Das Fliegengewicht ist ein reines Design-Muster, da seine Anwendung vor allem vom Designaspekt Speicherplatz getrieben wird, daneben auch vom Aspekt zentraler Update eines sehr globalen Zustands. Die Verwendung von Fliegengewicht in der Analyse ist in aller Regel ein Code-Smell (deutsch ‚schlechter Geruch‘), der eine Überarbeitung des schlecht strukturierten Programm-Quelltextes nahelegt.

Das Kompositum bietet sich an, um Fliegengewichte zu hierarchischen Strukturen zusammenzufügen, z. B. Zeichen, Zeile, Absatz. Eine Fabrikmethode wird benötigt, um die Fliegengewichte zu erzeugen.

Auch für die Zustands- und Strategie-Objekte ist das Fliegengewichtsmuster vorteilhaft. Das Idiom „immutable object“ ist eng verwandt mit dem Fliegengewicht. Fliegengewichte sollten immer als „immutable objects“ designt werden.

1. ↑ Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Entwurfsmuster. 5. Auflage. Addison-Wesley, 1996, ISBN 3-8273-1862-9, S. 223. 
2. ↑ Karl Eilebrecht, Gernot Starke: Patterns kompakt. 4. Auflage. Springer Vieweg Verlag, Berlin 2013, ISBN 978-3-642-34717-7, S. 98.