Může mít třída Image metodu resize?

Školení, která pořádám

U článku Práce s vlastnostmi pomocí metod se rozvinula zajímavá diskuse několika vynikajících teoretiků o tom, v čem vlastně spočívá objektově orientované programování. Přes několik příkladů jsme se dostali ke třídě Image, která reprezentuje obrázek. V diskusi jsme se bavili o metodě save, která obrázek uloží do souboru na disku, ale tato metoda je trochu složitější a diskuse o ní ještě nedospěla ke konci (chtěl bych totiž, aby tato metoda vybrala formát souboru podle jeho názvu – tedy aby save("krajina.jpg") vytvořilo soubor ve formátu JPG – to současné návrhy dosud nezvládnou). Současné poznatky bych tedy shrnul na jednodušší metodě resize, která by měla zmenšit nebo zvětšit obrázek.

Přímočaré řešení

Nejprve moje přímočará implementace a její použití:

<?php
class Image {
    private $resource;
    
    function resize($width, $height) {
        $resized = imagecreatetruecolor($width, $height);
        imagecopyresampled($resized, $this->resource, 0, 0, 0, 0, $width, $height, imagesx($this->resource), imagesy($this->resource));
        $this->resource = $resized;
    }
}

$image->resize(320, 240);
?>

Část teoretiků

Část teoretiků (Jiří Knesl, Ondřej Mirtes, Jan Tichý) tvrdí, že třída Image by měla mít jen jednu zodpovědnost a to sice reprezentaci obrázku. Veškeré operace (v diskusi ukládání do souboru, ale totéž se dá vztáhnout i na změnu rozměrů) by měly být vyčleněny do samostatných tříd implementujících patřičná rozhraní. Jak taková implementace vypadá?

<?php
interface ImageResizer {
    function resize(Image $image, $width, $height);
}

class ImageResizerResampled implements ImageResizer {
    function resize(Image $image, $width, $height) {
        $original = imagecreatefromstring($image->toString());
        $resized = imagecreatetruecolor($width, $height);
        imagecopyresampled($resized, $original, 0, 0, 0, 0, $width, $height, imagesx($original), imagesy($original));
        ob_start();
        imagepng($resized);
        $image->fromString(ob_get_clean());
    }
}

class Image {
    private $resource;
    
    function fromString($data) {
        $this->resource = imagecreatefromstring($data);
    }
    
    function toString() {
        ob_start();
        imagepng($this->resource);
        return ob_get_clean();
    }
}

$imageResizer = new ImageResizerResampled;
$imageResizer->resize($image, 320, 240);
?>

Implementace je tak složitá proto, že třída Image rozhodně nesmí zveřejnit svůj $resource, protože to by bylo porušení zapouzdření a vnitřnosti třídy bychom později nemohli snadno vyměnit třeba za ImageMagick. Jaké jsou výhody tohoto řešení?

Celkem snadno si můžeme vytvořit nový resizer, který bude změnu rozměrů provádět jiným algoritmem.
Při testování můžeme resizer snadno mocknout, protože zjistíme, že ten normální je pro testování moc pomalý (aby ne).

Jaké vidím nevýhody?

Pokud se v budoucnu rozhodneme resizer změnit, tak ho musíme vyměnit na všech místech programu.
Kvůli dvojnásobné serializaci do formátu PNG a načtení z něj bude kód zbytečně pomalý.
Kvůli implementaci rozhraní nemůže metoda resize dostat žádné další parametry (např. $blur) – ty musíme předat konstruktoru, takže když chceme vygenerovat třeba víc verzí obrázku s různým blurem, musíme pro každou verzi vytvořit nový resizer.
Kód je poměrně komplikovaný a špatně se používá.

Druhá část teoretiků

Druhá část teoretiků (~~Jan Tichý,~~ např. René Stein) jde o něco dál. Souhlasí s tím, že by funkčnost měla být vyčleněna do samostatných tříd, ale zároveň se kloní k tomu, že by třída Image neměla být jen primitivní obálka na data, se kterou pracují externí metody, ale že by tyto metody měla sama nabízet. Kód tedy využije všechno z předchozího příkladu a přidá k tomu:

<?php
class Image {
    private $resizer;
    
    function __construct() {
        $this->resizer = new ImageResizerResampled;
    }
    
    function setResizer(ImageResizer $resizer) {
        $this->resizer = $resizer;
    }
    
    function resize($width, $height) {
        $this->resizer->resize($this, $width, $height);
    }
}

$image->resize(320, 240);
?>

Tohle je řešení podle Reného. Nelíbí se mi na něm dvě věci. První je to, že se v konstruktoru vytváří dost možná zbytečný objekt. Druhá námitka je závažnější – třída Image musí vědět o existenci ImageResizerResampled a třída ImageResizerResampled musí pochopitelně vědět o existenci třídy Image.

Honza nabízí alternativu: konstruktor a metodu setResizer vyhodíme a použijeme anotaci:

<?php
class Image {
    /** @inject */
    private $resizer;
    
    function resize($width, $height) {
        $this->resizer->resize($this, $width, $height);
    }
}
?>

Přiznám se, že netuším, čím bude to @inject zpracované, ani jak vlastně funguje. Nicméně takhle rozsáhlá magie mě u odpůrců metod __get a __set opravdu překvapuje a na řešení mi vadí ze všeho nejvíc.

Závěr

Objektový návrh by měl vést především ke snižování složitosti jednotlivých částí aplikace. To spočívá mimo jiné i v návrhu API, se kterým se bude dobře pracovat. Další bod se týká omezení závislostí mezi jednotlivými třídami. Lepší je podle mě navrhnout třídu Image tak, aby měla metody save, resize a další, které fungují samy o sobě. A když někomu nevyhovují, tak ať si nějak poradí – můžu zveřejnit metody toString a (statickou) fromString a tím to uživateli trochu usnadnit, ale když nechám API jen přes soubory, tak se to dá taky zvládnout. A víte co? Já bych zpřístupnil i $resource – ať si uživatel zkontroluje, jestli mu to vrátí to, co čeká, a když ne, tak ať použije náhradní řešení nebo prostě vyhodí výjimku. Výsledkem je kód, který se dá použít mnohem snadněji a bude fungovat mnohem rychleji, i když se při něm uživatel může střelit do nohy.

Přijďte si o tomto tématu popovídat na školení Programování v PHP 5.

Jakub Vrána, Dobře míněné rady, 6.6.2011, diskuse: 59 (nové: 0)

Diskuse

bene:

Problem se zbytečným vytvářením třídy ImageResizerResampled lze vyřešit velmi elegantně.

<?php
class Image {
private $resizer;

function setResizer(ImageResizer $resizer) {
$this->resizer = $resizer;
}

function getResizer()
{
if ($this->resizer === null) {
$this->resizer = new ImageResizerResampled;
}
return $this->resizer;
}

function resize($width, $height) {
$this->getResizer()->resize($this, $width, $height);
}
}

$image->resize(320, 240);
?>

6.6.2011 13:05:42

Martin Hruška:

To je přece věčný boj. Dnes mezi Javisty a Rubysty.

Java: cizí programátoři jsou zlí. Musíme před nimi náš kód ochránit!
Ruby: cizí programátoři jsou hodní. Můžou rozvrtat úplně všechno a klidně můžou v naší knihovně změnit plus za mínus když se jim to hodí.

Stačí si tedy přečíst pár starých článků s diskusemi a je to. Tahle diskuse je už dávno vyčpělá.

6.6.2011 13:44:43

Rene Stein:

Dnes už na diskuze nebudu mít moc času, ale to přece není moje řešení - já jsem říkal, že metodu Resize i s implementací *za určitých okolností* nechám ve třídě Image a že vidím velké rozdíly mezi metodou Save a Resize.

Je to napsáno i u mě v diskuzi. Viz i dále. A teoretik nejsem.

"Metodu Resize mít objekt může a může ji i implementovat. V některých řešeních se vám ale transformace s obrázky mohou začít (Rotate, Skew) množit, a proto řešení refaktorizujete a zavedete raději ImageServices, aby nemusela vše řešit jedna třída. V průběhu návrhu a vývoje se objevují další doposud skryté doménové objekty a služby."

Může mít třída Image metodu resize?

Školení, která pořádám

Přímočaré řešení

Část teoretiků

Druhá část teoretiků

Závěr

Diskuse

bene:

Martin Hruška:

Rene Stein:

Jakub Vrána :

David Grudl:

Daniel Steigerwald:

Jakub Vrána :

Michal Illich:

Jakub Vrána :

Daniel Steigerwald:

Jakub Vrána :

Daniel Steigerwald:

Jakub Vrána :

analytik:

Jakub Vrána :

v6ak:

analytik:

Dundee:

Landy:

Michal Illich:

David Grudl:

Andrew:

David Grudl:

Denis:

Denis:

Jiří Knesl:

Jan Tichý:

Jakub Vrána :

Jan Tichý:

Jan Tichý:

Jakub Vrána :

Martin Hruška:

Jan Tichý:

Jakub Vrána :

Jan Tichý:

Jakub Vrána :

kukulich:

Jakub Vrána :

Jan Tichý:

Jakub Vrána :

Jan Tichý:

Jakub Vrána :

Jan Tichý:

Jakub Vrána :

Jan Tichý:

Jakub Vrána :

Pooky:

Jan Tichý:

Jan Tichý:

KarelI:

Naith:

Radek Miček:

Franta:

Pavel Král:

Peter:

Tom:

Kirara:

blizz:

knyttl:

Navigace

PHP triky

Kupte si mou knihu

Reklama

Web běží na serveru

Články podle skupin

Výběr článků

Nejnovější články

Normy a manuály

Další projekty