Administrace komentářů

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

Pokud je tohle posloupnost volání, tak to je instance něčeho co pracovně nazývám architektura trubka nebo štafeta. Tam máte natvrdo zadrátovánou tu šipku č. 2 a nemůžete s tím nic udělat. To je váš hlavní problém, kterého se potřebujete zbavit.

Pokud byste volání předělal takto:

    class aplikace -> class fileFinder 
                   <- $files                                        
                   -> class htmlRenderer

Tak s tím můžete pak dělat co chcete.

varianta (A): nezávisle fungující Finder a Filter

    class aplikace -> class fileFinder 
                   <- $files            
                   -> class fileFilter
                   <- $filteredFiles
                   -> class htmlRenderer

nebo

varianta (B): Dědění nebo lépe Dekorátor

    class aplikace -> class filteredFileFinder 
                                               -> class fileFinder
                                               <- $files
                   <- $filteredFiles
                   -> class htmlRenderer

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.

Můžete tohle aplikovat na stávající požadavky, nebo ty, které s nějakou rozumnou pravděpodobností očekáváte, ale nemůžete udělat univerzální stroj.

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

To je klasický příklad použití vzoru Factory.

varianta (C): Factory

$className = getConfigOption("fileFinderClass");
$factory = new FileFinderFactory();
$fileFinder = $factory->createFileFinder($className);

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í?

To by byl následující kód:

varianta (D): Filter jako plugin funkcionalita Finderu

$filter = new WhateverFilter();
$fileFinder = new FileFinder($filter);
$files = $fileFinder->getFiles();

To je ještě další varianta, kterou můžete použít.

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

To je něco čemu byste se měl vyhnout - fileFinder by měl výsledek vracet a ne štafetově předávat a mělo by mu být úplně jedno kdo ho zavolal a komu ten výsledek vrátí. Pak nebude problém s vložením kódu.

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)

Tím pouze používáte pneumatické kladivo tam kde stačí trochu ťuknout hřebíček.

Neumí se "vklínit" do posloupnosti dědění, a nahradit pouze jeden článek.

Proto se dědění moc nepoužívá - vytváří vazby moc natvrdo. Pokud tam potřebujete něco vklínit, je lepší použít volnější vazby, viz příklady.

V kódu nahoře jsem označil varianty ABCD, chtěl bych shrnout výhody a nevýhody každé:

A) (nezávislé třídy Finder a Filter) nejobecnější možnost, kde ani jedna třída neví o jiné - můžete kombinovat všechno se vším a udělat téměř jakékoliv chování.

B) (Filter jako dekorátor nad Finderem) něco jako dědění, můžete před a po volání základního Finderu provést libovolnou modifikaci a vrátit výsledek ve stejném formátu. Oproti dědění můžete ty modifikace libovolně nabalovat na sebe a to i v době běhu aplikace.

C) (Factory) výroba různých komponent (Finderů, Filtrů, ...) je schována na centrální místo, a případně konfigurovatelná uživatelem. Řekl bych, že to je spíš doplňková záležitost k ostatním variantám.

D) (Plugin Filter) implicitně předpokládáte že se nějaký filtr použít musí, byť třeba prázdný. Hodí se, pokud je hodně jednoduchých Filtrů ale třeba jen jeden Finder. Místo jednoho filtru můžete třeba pluginovat pole filtrů atd.