Re: OT: Architektura
Jozef Babjak wrote: Dany analytik v tom pripade nepotrebuje ani packages. Proc clenit na packages kod, ktery delam pro samostatneho klienta a davat ho do balicku cz.klient1. ... ? Tak to rovnou prepisu cele sakum pikum a supnu vsechny tridy do jednoho chumlu. Alespon nebudu muset resit importy. ^-- Paradox je, ze v sucasnosti packages nevaju valny vyznam, co sa tyka navrhu. Viac ci menej iba pomahaju v orientacii medzi mnohymi subormi. Ale java 7 by mala konecne priniest realnejsi vyznam aj pre packages. V ciste JSE ne, ale pokud zacnete pouzivat neco komponentoveji orientovaneho, tak mohou zacit hrat vyznacnejsi roli... Trebas na netbeans platform muze modul rozhodovat, jake package ukaze ven... Ondra Satai Nekola www.nekola.cz
Re: OT: Architektura
Ja by som sa ho opytal preco :). Je jasne ze nie vzdy je vhodne delenie na vrstvy, zalezi od aplikacie, ale vrstvy su odolne voci zmene poziadavkam. Lenze ak si spomenie napr na SOA, tak to je este odolnejsia architektura voci zmene poziadavkam. A ak sa predpoklada ze sa poziadavky budu velmi menit, alebo su nejasne, tak by som okrem navrhu super architektury rozmyslal o prototype alebo extremnom programovani. Jiří Kotal wrote / napísal(a): V tomto případě šlo spíše o jednotlivé vrstvy systému, jednak z hlediska třívrstvé architektury a jednak vnitřní členění na další subvrstvy. Zmíněný architekt zastává názor, že pokud se předpokládají časté změny v požadavcích, je výhodnější vůbec členění na subvrstvy nezavádět. Osobně si myslím, že naopak vhodné vrstvení aplikace přispěje ke snadnější realizaci změn. Jirka -Original Message- Doufam, ze spravne chapu namitku - hlavne toho, co se rozumi vnitrnim rozhranim. Mozna bych odpovedel., ze pokud se s kazdym novym zakaznikem musí menit nejake vnitrni API, tak je asi neco spatne. Mozna je pes zakopany nekde v nepochopeni tohoto rozliseni? http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi (Mimochodem - po precteni tohohle dokumentu mi doslo, kolik veci jsme s kolegy delali nekolik let spatne a jakych zlozvyku se musim odnaucit :/ ) A nebo to API neni vubec API, ale jen nejaky implementacni kod? Ondra Nekola
OT: Architektura
Omlouvám se za off topic, ale rád bych se podělil o jednu zkušenost. Při vysvětlování principů třívrstvé architektury jsem použil citaci z wikipedie a volně jsem ji přeložil: The tiers should be populated with functionality in such a way as to minimize dependencies, and isolate functionalities in a coherent manner - knowing that everything is likely to change, and changes should be made in the fewest number of places, and be testable. Tato citace (z definice třívrstvé architektury na Wikipedii) říká, že je výhodné budovat systém tak, aby obsahoval co nejméně závislostí (částí systému) a izoloval jednotlivé funkčnosti navzájem (jedna komponenta slouží vždy pouze k jednomu účelu) - víme, že vše podléhá změně, a proto by měly změny způsobit opravy co nejmenšího počtu míst v systému. V reakci na toto sdělení jeden architekt uvedl: Je to otázka optimismu či skepse při návrhu vnitřních rozhraní. Tato mají smysl pokud jsou stabilní. Pokud každý nový zákazník přináší změny v těchto rozhraních, pak je někdy lepší, když takováto rozhraní nejsou. Co byste takovému architektu odpověděli? Jirka
Re: OT: Architektura
Jiří Kotal wrote: Omlouvám se za off topic, ale rád bych se podělil o jednu zkušenost. Při vysvětlování principů třívrstvé architektury jsem použil citaci z wikipedie a volně jsem ji přeložil: The tiers should be populated with functionality in such a way as to minimize dependencies, and isolate functionalities in a coherent manner - knowing that everything is likely to change, and changes should be made in the fewest number of places, and be testable. Tato citace (z definice třívrstvé architektury na Wikipedii) říká, že je výhodné budovat systém tak, aby obsahoval co nejméně závislostí (částí systému) a izoloval jednotlivé funkčnosti navzájem (jedna komponenta slouží vždy pouze k jednomu účelu) - víme, že vše podléhá změně, a proto by měly změny způsobit opravy co nejmenšího počtu míst v systému. V reakci na toto sdělení jeden architekt uvedl: Je to otázka optimismu či skepse při návrhu vnitřních rozhraní. Tato mají smysl pokud jsou stabilní. Pokud každý nový zákazník přináší změny v těchto rozhraních, pak je někdy lepší, když takováto rozhraní nejsou. Doufam, ze spravne chapu namitku - hlavne toho, co se rozumi vnitrnim rozhranim. Mozna bych odpovedel., ze pokud se s kazdym novym zakaznikem musi menit nejake vnitrni API, tak je asi neco spatne. Mozna je pes zakopany nekde v nepochopeni tohoto rozliseni? http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi (Mimochodem - po precteni tohohle dokumentu mi doslo, kolik veci jsme s kolegy delali nekolik let spatne a jakych zlozvyku se musim odnaucit :/ ) A nebo to API neni vubec API, ale jen nejaky implementacni kod? Ondra Nekola
Re: OT: Architektura
Quoting Jiří Kotal [EMAIL PROTECTED]:
Tato citace (z definice třívrstvé architektury na Wikipedii) říká, že je
výhodné budovat systém tak, aby obsahoval co nejméně závislostí (částí
systému) a izoloval jednotlivé funkčnosti navzájem (jedna komponenta slouží
vždy pouze k jednomu účelu) - víme, že vše podléhá změně, a proto by měly
změny způsobit opravy co nejmenšího počtu míst v systému.
Toto ma obecnou platnost a netyka se pouze trivrstve architektury.
Provazanost komponent (coupling) se snazime minimalizovat vzdy (nelze
ji ovsem uplne odstranit, protoze pak by nam zustaly izolovane
komponenty).
Take jasne definovana zodpovednost patri mezi osvedcene navrhove
principy. A to na urovni komponent i trid. Pokud ma trida zodpovednost
Customer, nemela by mit soucasne i zodpovednost napr. Account.
Zlepsuje to flexibilitu, tj. system lze snadneji prizpusobit. Tj.
presne jak pisete.
V reakci na toto sdělení jeden architekt uvedl:
Je to otázka optimismu či skepse při návrhu vnitřních rozhraní. Tato mají
smysl pokud jsou stabilní. Pokud každý nový zákazník přináší změny v těchto
rozhraních, pak je někdy lepší, když takováto rozhraní nejsou.
Co byste takovému architektu odpověděli?
Pokud jde o to, zda ma ci nema cenu definovat interface ke tride, na
kterou se chceme odkazovat z jineho baliku, tak zalezi na konkretni
situaci.
Priklad:
package a;
public class A { }
package b;
public class B {
A p;
}
Trida B ma odkaz na tridu A, tj. mezi tridami je vazba. Lze ji
zeslabit zavedenim rozhrani:
package a;
public interface IA { }
class A implements IA { }
package b;
public class B {
IA p;
}
Pokud existuje byt i nepatrna moznost, ze bychom pridali jinou
implementaci rozhrani IA, napr.:
class A2 implements IA { }
pak je zavedeni rozhrani IA prinosem. Je potreba ovsem videt i
nevyhody: je to dalsi interface a navic pokud nechceme svazat tridu B
s konkretni implementaci rozhrani IA, je potreba zajistit nejakym
zpusobem inicializaci promenne p ve tride B (napr. pomoci navrhoveho
vzoru Factory method ci Abstract factory).
Moc nerozumim co je mysleno tim, ze kazdy novy zakaznik prinasi zmeny
v techto rozhranich, takze na to nemuzu odpovedet. Jiste ale je, ze
rozhrani by mela byt pokud mozno stabilni.
Z.T.
--
Zdenek Tronicek
Department of Computer Science and Engineering
Prague tel: +420 2 2435 7410
http://cs.felk.cvut.cz/~tronicek
RE: OT: Architektura
V tomto případě šlo spíše o jednotlivé vrstvy systému, jednak z hlediska třívrstvé architektury a jednak vnitřní členění na další subvrstvy. Zmíněný architekt zastává názor, že pokud se předpokládají časté změny v požadavcích, je výhodnější vůbec členění na subvrstvy nezavádět. Osobně si myslím, že naopak vhodné vrstvení aplikace přispěje ke snadnější realizaci změn. Jirka -Original Message- Doufam, ze spravne chapu namitku - hlavne toho, co se rozumi vnitrnim rozhranim. Mozna bych odpovedel., ze pokud se s kazdym novym zakaznikem musí menit nejake vnitrni API, tak je asi neco spatne. Mozna je pes zakopany nekde v nepochopeni tohoto rozliseni? http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi (Mimochodem - po precteni tohohle dokumentu mi doslo, kolik veci jsme s kolegy delali nekolik let spatne a jakych zlozvyku se musim odnaucit :/ ) A nebo to API neni vubec API, ale jen nejaky implementacni kod? Ondra Nekola
Re: OT: Architektura
Zmineny architekt by chtel menit cely sitovy stack, protoze nekdo chce do mailoveho klienta pridat novou ikonku? Trebas rodinka TCP/IP ukazuje, ze dobre navrzene a odseparovane vrstvy mohou prezivat i dost radikalni zmeny pozadavku... Pokud jsou v planu caste a velke zmeny pozadavku, tak jsou potize na ceste, ale zrusenim vrstev si imo nikdo nepomuze. O. V tomto případě šlo spíše o jednotlivé vrstvy systému, jednak z hlediska třívrstvé architektury a jednak vnitřní členění na další subvrstvy. Zmíněný architekt zastává názor, že pokud se předpokládají časté změny v požadavcích, je výhodnější vůbec členění na subvrstvy nezavádět. Osobně si myslím, že naopak vhodné vrstvení aplikace přispěje ke snadnější realizaci změn. Jirka -Original Message- Doufam, ze spravne chapu namitku - hlavne toho, co se rozumi vnitrnim rozhranim. Mozna bych odpovedel., ze pokud se s kazdym novym zakaznikem musí menit nejake vnitrni API, tak je asi neco spatne. Mozna je pes zakopany nekde v nepochopeni tohoto rozliseni? http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi (Mimochodem - po precteni tohohle dokumentu mi doslo, kolik veci jsme s kolegy delali nekolik let spatne a jakych zlozvyku se musim odnaucit :/ ) A nebo to API neni vubec API, ale jen nejaky implementacni kod? Ondra Nekola
Re: OT: Architektura
V reakci na toto sdělení jeden architekt uvedl: Je to otázka optimismu či skepse při návrhu vnitřních rozhraní. Tato mají smysl pokud jsou stabilní. Pokud každý nový zákazník přináší změny v těchto rozhraních, pak je někdy lepší, když takováto rozhraní nejsou. Co byste takovému architektu odpověděli? To je asi jako tvrdit, ze davat do auta airbagy je otazka optimismu ci skepse designera, protoze kdyz to do tebe navali kamion, tak ti to je k nicemu. Je to samozrejme nesmysl, protoze v 80% procentech pripadu ti ty airbagy zachrani zivot. Vnitrni rozhrani nezavadime jenom proto, aby odolaly zakaznickym vlnam, ale take proto, abychom oddelily odpovednost jednotlivych komponent (vrstev) systemu a zavedli jistou miry abstrakce. Pokud vnitrni rozhrani nejsou vede to k spagetovemu kodu (http://en.wikipedia.org/wiki/Spaghetti_code). Nadto bych jeste podotknul, ze je vnitrni rozhrani a vnitrni rozhrani. Vetsina systemu ma nejaky core, ktery je takrka nezavisly na tom, co si zakznik navymysli za use-cases. Jedine co tedy muze byt nestabilni u dobre navrzene architektury je API, ktere implementuje jednotlive zakaznicke use cases a i to je napovazenou (spatna analyza zakaznickych pozadavku, spatna komunikace se zakaznikem). -- S pozdravem Roman Dagi Pichlik /* http://www.sweb.cz/pichlik/ Blog pro kodery */
Re: OT: Architektura
A prave rozhrani jsou idealni pro zmeny vnitrni logiky. A pokud ma neco klient uplne samostatne, tak to ma pak resit jeho vlastni casti kodu. Pouziti rozhrani mu prece dava moznost nedotknout se jinych casti aplikace. To znamena ze ty znemy ktere specificky dela pro daneho klienta budou kompatibilni s ostatnimi obecnejsimi castmi. Kuprikladu me nebude zajimat, ze jsem zmenil zpracovani faktury, protoze z fakturou bude umet porad pracovat stejne dobre jako drive cast, ktera kontroluje jestli jsem prijal platbu v bankovnim uctu. Dany analytik v tom pripade nepotrebuje ani packages. Proc clenit na packages kod, ktery delam pro samostatneho klienta a davat ho do balicku cz.klient1. ... ? Tak to rovnou prepisu cele sakum pikum a supnu vsechny tridy do jednoho chumlu. Alespon nebudu muset resit importy. Pet On Tue, 25 Sep 2007 16:43:38 +0200, Ondrej Nekola [EMAIL PROTECTED] wrote: Zmineny architekt by chtel menit cely sitovy stack, protoze nekdo chce do mailoveho klienta pridat novou ikonku? Trebas rodinka TCP/IP ukazuje, ze dobre navrzene a odseparovane vrstvy mohou prezivat i dost radikalni zmeny pozadavku... Pokud jsou v planu caste a velke zmeny pozadavku, tak jsou potize na ceste, ale zrusenim vrstev si imo nikdo nepomuze. O. V tomto případě šlo spíše o jednotlivé vrstvy systému, jednak z hlediska třívrstvé architektury a jednak vnitřní členění na další subvrstvy. Zmíněný architekt zastává názor, že pokud se předpokládají časté změny v požadavcích, je výhodnější vůbec členění na subvrstvy nezavádět. Osobně si myslím, že naopak vhodné vrstvení aplikace přispěje ke snadnější realizaci změn. Jirka -Original Message- Doufam, ze spravne chapu namitku - hlavne toho, co se rozumi vnitrnim rozhranim. Mozna bych odpovedel., ze pokud se s kazdym novym zakaznikem musí menit nejake vnitrni API, tak je asi neco spatne. Mozna je pes zakopany nekde v nepochopeni tohoto rozliseni? http://openide.netbeans.org/tutorial/api-design.html#design.apiandspi (Mimochodem - po precteni tohohle dokumentu mi doslo, kolik veci jsme s kolegy delali nekolik let spatne a jakych zlozvyku se musim odnaucit :/ ) A nebo to API neni vubec API, ale jen nejaky implementacni kod? Ondra Nekola -- Zpráva vytvořena poštovním klientem M2, který je součástí webového prohlížeče Opera. Více na http://www.opera.com/mail/ .
Re: OT: Architektura
Dany analytik v tom pripade nepotrebuje ani packages. Proc clenit na packages kod, ktery delam pro samostatneho klienta a davat ho do balicku cz.klient1. ... ? Tak to rovnou prepisu cele sakum pikum a supnu vsechny tridy do jednoho chumlu. Alespon nebudu muset resit importy. ^-- Paradox je, ze v sucasnosti packages nevaju valny vyznam, co sa tyka navrhu. Viac ci menej iba pomahaju v orientacii medzi mnohymi subormi. Ale java 7 by mala konecne priniest realnejsi vyznam aj pre packages. J.
