Ortogonalita vystrkuje růžky
V matematice pojem ortogonální znamená pravoúhlý nebo kolmý. V programátorské branži se termín ortogonální používá, když je něco na sobě nezávislé, svým způsobem se doplňující. Například můžou existovat dva úplně ortogonální přístupy k problému. Zkusím teď naznačit pár příkladů, kde se ortogonalita objevuje, a snad se mi podaří ukázat, že to s ní není zrovna snadné.
Příklad první
Windows a UNIXy maijí úplně odlišný způsob uspořádání souborů na disku. Pokud
ve Windows instalujete nějaký program, téměř všechny své soubory si umístí do
nějakého podadresáře v Program Files – ať už to jsou spustitelné
soubory, pomocná data nebo třeba dokumentace. Naproti tomu na UNIXech je to
úplně obráceně: každý typ souborů má svůj podadresář (spustitelné soubory
/bin, /sbin, /usr/bin, dokumentace /usr/doc,
konfigurace /etc, apod.) a programy jsou díky tomu "rozprsklé" pod
celém adresářovém stromu.
Výhody i nevýhody obojího jsou celkem zřejmé: Ve Windows je jasně vidět, co patří kterému programu a kolik místa zabírá. Každý program si navíc může data uchovávat ve struktuře, jaká mu vyhovuje. V UNIXu zase není problém s hledáním cest ke spustitelným souborům (na Windows kvůli tomu musí být speciální klíč v registrech, kde jsou všechny "exáče", které mají jít spustit zadáním svého jména, vyjmenované).
A teď mi řekněte, co je lepší?
Příklad druhý
Podobný problém jsem nedávno řešil při tvorbě těchto stránek: mají být
obrázky centrálně v adresáři /img, nebo tam mají být jen ty
společné pro všechny sekce a každá část by pak měla potřebné obrázky ve svém
adresáří? Popravdě řečeno, současný stav webu je takový, že něco je tak a něco
jinak, podle toho, jak se postupně měnil můj názor na tuto věc. Čili pěkný
zmatek.
Příklad třetí
Teď trochu z jiného soudku – dělám webovou aplikaci v PHP, která má v tři vrstvy: databázovou (cokoliv, co zavání SQL), prezentační (cokoliv, co zavání HTML) a "business logic" (zbytek, vlastní logika aplikace). Aplikaci píšu objektově. Jak navrhnout rozdělení do objektů? Možné jsou opět dva přístupy:
- Objekty modelovat podle vrstev:
// načtení dat o osobě z databáze (pomocí databázového objektu) $personData = $db->selectPerson($id); // zobrazení formuláře pro jejich editaci (pomocí prezentačního objektu) $layout->writePersonEditForm($personData);
- Objekty modelovat podle dat:
$person = new Person(); // nový objekt "osoba" $person->selectById($id); // načtení dat o osobě z databáze $person->writeEditForm(); // zobrazení formuláře pro jejich editaci
Na takhle malých příkladech to asi není moc velký rozdíl, ale když píšete monstrum o 20 000 řádcích, už je potřeba si to promyslet. V mém konkrétním případě jsem zvolil první možnost, protože součástí požadavků na aplikaci bylo centralizovat databázový a prezentační kód na jedno místo, aby to šlo později snadno změnit, ale pokud by takové omezení v požadavcích nebylo, tak fakt nevím. Nemá s tímhle někdo ze čtenářů náhodou zkušenosti?
