In der Lagerplatzverwaltung soll es möglich sein, Lagergüter mit unterschiedlichen Einlagerstrategien einzulagern. So soll z.B. bei Kunde A möglichst nahe an den Gassenköpfen eingelagert werden, bei Kunde B sollen zuerst Lagerplätze in einer für Menschen optimalen Höhe belegt werden. Zusätzlich soll die geeignete Einlagerstrategie abhängig vom Lagerhilfsmittel (LHM) des Lagerguts und des Einlager- bzw. Umlagergrundes sein. Um die Anwendung portierbar zu halten, sollte sich die Anwendung, die einen Lagerplatz sucht, nicht an einen spezifischen Satz von Einlagerstrategien binden. Die Auswahl einer Einlagerstrategie sollte nicht über die gesamte Anwendung verteilt, sondern an einer einzigen Stelle entschieden werden, um den Aufwand bei der Wiederverwendung zu minimieren.

In der prozeduralen Programmierung wäre ein Lösungsansatz, eine globale Bibliothek von Einlagerstrategien anzulegen, die über die Zeit hinweg gefüllt wird.
In der objektorientierten Welt könnte ein kundenspezifisches PlatzAnweiser Objekt erzeugt werden, das die gewünschte Einlagerstrategie implementiert. Dies bringt den Vorteil der Eigenständigkeit des Moduls, hat aber den Nachteil, dass die Anwendung (hier: der PlatzSucher) diesen konkreten PlatzAnweiser kennen muss. Das führt zu Problemen, wenn die Anwendung bei einem anderen Kunden wiederverwendet werden soll, da sie mit dem konkreten PlatzAnweiser des ursprünglichen Kunden verhaftet ist.

Mehr Informationen zur modularen Software finden Sie unter Modulare Software – Die abstrakte Fabrik angewendet auf die Lagerplatzverwaltung.

Bildquelle: © Maxoido – Fotolia.com