Igen, ha (mar megtorent) esemenyek koveteserol van szo, akkor OK. De ha 'csak' egy altalanos leiras arrol, hogy melyik termek gyartasa milyen lepesekbol all, akkor milyen idot tegyenek bele?
Nem lenne rossz a dolog ertelmerol tobbet tudni! Pl ha egy termek gyartasa egymast koveto folyamatokbol (inkabb lepesekbol), all akkor inkabb azt mondanam:
GYARTAS
#termek_id
#sorszam
*folyamat_id
persze az igaz, hogy uj folyamatot beszurni eleg nehezkes (hacsak nem tizesevel sorszamozunk, mint BASIC-ben :)
Akárki, segítség...
VC++ 6.0 -ban , hogy a halálba tudok globális változót deklarálni?
Megjelenik a Globals folderben, de akárhol próbálok hivatkozni rá, mindig 'undeclared identifier' üzenetet küld.
Na most lehet én vagyok hülye, sőt biztos, de nem értem...
Bár, nem ártana ráébreszteni a megrendelőt, hogy nem csak a cipésznél meg a szabónál, meg az építésznél, meg a számítástechnikán kívül mindenhol máshol kell elmondani, hogy mit akarok.
Hm? Nezz be peldaul az epitkezes-felujitas vagy epitkezesi szaktanacsok topikba.
De tutko meg millio mas hasonlo van. A megrendelo nem ert a megrendelt dologhoz -- ez termeszeres, ha ertene jo esellyel megoldana hazon belul a sjat problemajat.
Ezen a területen mintha elhagyná az embereket a józan eszük. :(((
Hat, a 2 leggyakribb elem, mint tudjuk... De tenyleg nem csak az van teriteken.
Feladni meg termeszetesen sose szabad, csak legyen mindig B terv.
Bár, nem ártana ráébreszteni a megrendelőt, hogy nem csak a cipésznél meg a szabónál, meg az építésznél, meg a számítástechnikán kívül mindenhol máshol kell elmondani, hogy mit akarok.
Ezen a területen mintha elhagyná az embereket a józan eszük. :(((
Kivedeni -- erre nem tudok modszert sajna, es varom az otleteket.
Viszont ha tudod, hogy ez a dolgok termeszete, lehetsz eleg ovatos -- a mertek azert nem mindegy. Es erdemes B tervvel rendelkezni arra az esetre, ha ilyen dolgok derulnek ki.
BTW akkora tragediat azert nem kell latni a dologban, hisz a rendszer elete altalaban nem zarul le az atadassal. Ami nem jott ossze, vagy rosszul megy a kovetkezo verzioba. Es ott nincs akkora kulonbseg a "vadonat uj" es a "kifelejtett" featuresek kozott.
A folyamatos atirasra meg jo rakeszulni, tanulmanyozt a 'refactoring' technikakat, meg az olyan stilust, amelyik keves veraldozattal rugalmas, vagy rugalmassa teheto.
Az egesz OO dolog is azert tudott nagyot aratni, a magas szintu encapsulation-nel. Nagy rendszerekben meg erdemes lazitani a kapcsolatokat (lasd ezzel kapcsolatos patternek) hogy egy resz akar drasztikus megvaltoztatasa se dontson ossze mindent.
Amit meg erdemes tanulmanyozni, az Antipatterns -- az ismerten rossz dolgok, melyek minduntalan ismetlodnek. Ha ezeket koran felismered, nagy elonyt szerezhetsz.
Despil, ha megfogadsz egy tanacsot, majd a munkhelyeden a fonokodnek csak nagyon ovatosan emlitsd ezt a dolgot. Mintha arra probalnad rabeszelni, hogy a szerzodesben kovetleje a holdat meg a csillagokat.
(De ha valaki tud helyet, ahol ez gyakorlat, es termeszetes, szoljatok mar, kuldom is a CV-met. :)
Ezért kell velük aláiratni, hogy igen, ennyit kell a rendszernek tudnia, az igénylista teljes.
Akkor már nem tud kajabálni. Illetve tud, de te védve vagy.
A megrendelonek annyira magatol ertetodo valami, hogy meg sem emliti ("ezt meg az ovodas is tudja" alapon), te meg mint nem annyira szakmabeli vagy eszreveszed vagy nem. Pl: A TSZ-elnok a csirkerendszer atadasanak napjan megpenditi: persze a kopasznyaku csirkekkel egeszen maskepp kell eljarni!
Csak annyi, hogy nem jutsz el odaig... Mert nem hagynak eleg use case-t gyujteni. :-(
Ha megis, akkor eldorado.
A masik tapasztalat, hogy a legnagyobb prioritasu use case-ek az atadas utan (vagy par nappal a hatarido elott) derulnek ki. Mar nemegyszer jartam ugy. A megrendelonek annyira magatol ertetodo valami, hogy meg sem emliti ("ezt meg az ovodas is tudja" alapon), te meg mint nem annyira szakmabeli vagy eszreveszed vagy nem.
Szerbusztok! Nem biztos, de pár embert innen, aki fontosnak tartja a tervezést is, az átgondolást a rátekintést, stb. szóval az ittlévők közül érdekelne az alábbi fórum.
A Responsibilities peldaul nem szerepel a konyvben, legalabbis nem ezen a neven (valszeg a Chain of Responsibilities az).
A Bridge az egy eleg hosszu tortenet, most passzolom :)
Az Iterator az olyasmi, hogy van egy adatszerkezeted es nyilvan hasznalsz valamilyen modszert, hogy a benne levo adatokat elerd, altalaban egy fuggvenyt ami visszaadja az adott erteket (pl. a Javas Vector-nak van egy get(int index) fuggvenye), akkor altalaban az eleres HOGYAN-ja (a get fuggveny) fugg az adatszerkezettol (a Vector-tol). Ha le akarod cserelni az adatszerkezetet, mondjuk egy Set-re, akkor at kell irnod azt is, hogy hogyan ered el az adatszerkezetet, mert a Set-nek nincs get(int index) fuggvenye. Ha azt sok helyen kell lecserelned, akkor az kellemetlen lehet, sok ido, tobb hibalehetoseg stb.
Ezert kulonvalasszuk az eleres modjat az adatszerkezettol: csinalunk egy Iterator interface-t a kovetkezo methodusokkal:
interface Iterator {
// van-e kovetkezo elem
boolean hasNext();
// visszaadja a kovetkezo elemet
Object next();
}
Mind a ket adatszerkezetnek (Vector es Set) adunk egy iterator() fuggvenyt, ami visszater egy Iterator-ral, ahol persze hatterben ott van egy osztaly (illetve ketto, egy a Vectorhoz, egy a Set-hez) ami implementalja az Iterator interface-t, de arrol nekunk nem is kell tudni (ezert is jo dolog az interface!). Es igy mind a ket adatszerkezet elerheto azonos modon:
Vector adat;
//HashSet adat;
Iterator iterator= adat.iterator();
while (iterator.hasNext()) {
Object adat= iterator.next();
// itt csinalsz valamit az adattal
}
A lenyeg az, hogy egy nagyon absztrakt dolgot (az eleres HOGYANjat) egy osztalyba, illetve interface-be rakjak es elkulonitik az adattol.
Tovabbi lepes lehet, hogy ha kulonbozo iteratorokat definialhatunk, amik persze mind az Iterator interface-t implementaljak, de mas mas funkciokat valositanak meg pl: minden masodik elemet adja vissza, minden harmadik, az eleres akkor is ugyanolyan marad. Vagy ha egy fa strukturat kell kulonbozokeppen bejarni, akkor jol johet hogy csak az Iterator-t megvalosito osztalyt kell lecserelni.
Szoval nagyjabol ennyi, a tobbirol is dumalhatunk.
Beszeljunk akkor pattern alapu tervezesrol. Mit ertesz ezalatt? :)
Nem tudom :))
Itt említettétek a Design Pattern könyvet, és a Visual Studio .NET is tartalmaz patterneketet: Bridge, Responsibilities, Iterator, ilyesmiket.
Egyet megnéztem, úgy tünt, hogy valami gyakori osztály típus kapcsolatokat tartalmaz.
Pl. A Responsibility pattern csinált nekem egy Handler-t, meg egy forrás és egy célosztályt, megfelelő asszociációkkal.
Nem nagyon vizsgálgattam még, mert ígéretet kaptam a könyvre, így gondoltam előbb elolvasom azt :))))
