Administrace komentářů

Ano, tohle je řešení. Jestli to správně chápu, navrhujete vlastně zadefinovat systém pluginů, které umožní měnit předem vymezené vlastnosti aplikace.

Mým cílem je aplikace, která něco umí a je možné ji co nejširším způsobem a s co nejmenčí redundancí kódu upravovat.

Rozvedu náš příklad do reálnější podoby. Následuje struktura volání aplikace "webový manažer souborů":

class aplikace -(1)-> class fileFinder -(2)-> class htmlRenderer

Rozhodnu se, že chci upravit fileFinder diskutovaným způsobem. A mám následující možnosti:

1) aplikace musí být naprogramovaná tak, že umí nahradit třídu fileFinder jinou (např. v konfiguráku bude jméno třídy)

2) fileFinder musí mít rozhraní pro aplikování vybraných operací s možností ovlivnit výsledné chování - tedy fileFinder musí mít rozhraní pro pluginy a v runtime někde uloženou jejich konfiguraci - to je Vaše řešení?

3) do místa (1) vložím vlastní kód, který udělá co bude potřebovat, využije třeba alternativní třídu pro fileFinder, ale pak musí zajistit volání htmlRendereru v kroku (2) sám

4) řešení co sem navrhl odpoledne - tedy nějak elegantně zařídím, aby celá aplikace používala místo třídy fileFinder úplně jinou třídu (potomka původní nebo implementující stejný interface)

Varianta 1) a 2) je OK, ale vyžaduje předem vyspecifikované podporované změny chování aplikace. Každé rozšíření těchto možností znamená netriviální úpravu aplikace. Navíc tato řešení neumí měnit předky používaných metod. Neumí se "vklínit" do posloupnosti dědění, a nahradit pouze jeden článek. Takto je možné pouze v libovolném místě řetěz dědění přetnout a pak znovu doimplementovat až do finálních tříd (tedy redundance kódu a druhotně podobný nešvar jako má 3)

Varianta 3) se mi hrubě nelíbí. Vyžaduje dost redundantní práce.

Co říkáte na Variantu 4)?