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?

Feb 13, 2004 – 15:46

Comments

crs
crs
termin `orthogonalni` jsem slysel u architektury procesoru. slysel jsem napr, ze procesor ARM-7 TDMI, ktery pouziva napr. GBA, je orthogonalni, a znamenalo to, ze je striktne RISCovy, a navic je rozdelen do mensich obvodu, ktere se ve vetsi mire navzajem vyuzivaji. Vyhoda pak tkvi v tom, ze se napr nesnazi implementovat co nejvic strojovych instrukci, ale kombinuje je z tech nejjednodusich, stavajicich (jeste vic nez neorthogonalni RISC CPU)...
Martin Mojzis
Zdar,

mozna si me jeste pamatujes ze souteze v programovani :)

Programuju pro StatCounter a tam pouzivame prave ten model 1. Funguje to dobre, v prubehu vyvoje doslo k docela razantni zmene databazove vrstvy a diky tomu nam to zas tak moc neprerostlo pres hlavu.

Takze ze zkusenosti muzu rict, ze objektovy navrh obvykle zustava (pokud se udela dobre) a provadi se maximalne dilci zmeny, kdezto design (spis) nebo databazovy system (mozna asi mene casteji) se muze zmenit.
David Majda
David Majda
[2] Nazdar, jasně, pamatuju si tě :-)

Mimochodem, naše zkušenosti se celkem shodují.
dgx
dgx
Rozhodně bych taky preferoval první způsob (příklad 3), právě kvůli té menší závislosti na jednotlivých vrstvách. Vlastně mě ani nenapadá jediný důvod, proč použít druhý postup...

Add comment

It is not possible to add comments to posts older than one month.