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:

1. 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);
   

2. 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?