Zasady projektowania obiektowego?

0

Panowie chcac napisac aplikacje ktora bedzie spelniac wymagania klienta,bedzie elastyczna i w razie potrzeby podatna na wszelkiego rodzaju poprawki i modyfikacje, jakie zasady podczas pisania trzeba zachowac,jesli chodzi o projektowanie obiektowe? Uzywac jakichs zasad czy piszecie ze tak powiem bez wiekszego zastanawiania sie nad tym ?Np. zeby nie pisac Od razu gotowych metod tylko implementowac interfejsy itd ? Z gory dzieki.

0

Stosujemy podział na warstwy oraz wzorce projektowe warstwy prezentacji.

0

No wzorce projektowe to rozumiem ale podzial na warstwy mozesz mi to dokladniej wyjasnic? Rozumiem ze wzorce trzeba miec wyryte na blache?Zeby wiedziec kiedy jaki zastosowac?

0

Nieśmiało moge Ci polecić tę książkę:

user image
http://helion.pl/ksiazki/head-first-object-oriented-analysis-and-design-edycja-polska-rusz-glowa-brett-d-mclaughlin-gary-pollice-david-west,hfooad.htm

idealna jako odpowiedź na Twoje pytanie. Nie spodziewaj się że w jednym poście albo w jednym zdaniu ktoś Ci wyczerpująco odpowie na takie pytanie.

0

Ta ksiazka ma zbyt wiele zbednych informacji ja chce miec sama esencje bez calej tej smiesznej otoczki. Myslalem ze mozecie wskazac kilka regul ktorymi sie kierujecie podczas pisania aplikacji.

0
OO napisał(a)

No wzorce projektowe to rozumiem ale podzial na warstwy mozesz mi to dokladniej wyjasnic? Rozumiem ze wzorce trzeba miec wyryte na blache?Zeby wiedziec kiedy jaki zastosowac?

Wykucie wzorców na blachę, to raczej trudna rzecz. W pewnym momencie po prostu się zauważa kiedy jakiego użyć. Ale mi nie o te wzorce chodziło, tylko te od warstwy prezentacji, czyli MVC, MVP, itp., a ich użycie zależy już raczej od wybranej przez nas technologii GUI.
Podział na warstwy polega na tym, że jeden zestaw klas (zazwyczaj zamknięty w ramach jednego projektu kompilowanego do dll) odpowiada za dostęp do danych, inny za logikę biznesową, inny jest modelem danych (czyli obiektami mapowanymi do tabel bazy danych, na których operuje reszta klas), kolejny to jakieś klasy pomocnicze, a poza tym są jeszcze moduły zawierające logikę biznesową, czyli np. dla MVP będą to wszystkie interfejsy i powiązane z nimi prezentery, a nad tym wszystkim jest wykonana w konkretnej technologii aplikacja GUI.

Varran napisał(a)

idealna jako odpowiedź na Twoje pytanie. Nie spodziewaj się że w jednym poście albo w jednym zdaniu ktoś Ci wyczerpująco odpowie na takie pytanie.

Czy ja wiem, czy idealna. Ta książka to wprowadzenie w świat myślenia obiektowego, a nie o tworzeniu aplikacji o sensownej strukturze.

0

No dobrze a czy piszac w asp.net mvc mamy juz problem z glowy,jesli chodzi o zaprojektowanie aplikacji?Bo tutaj jestesmy zmuszeni do takiego a nie innego tworzenia aplikacji, ktory chyba sam nas jak gdyby prowadzi do napisania oprogramowania elastycznego i latwego do modyfikacji dzieki temu wlasnie, ze jest to rozdzielone czego nie ma w zwyklym asp,dobrze mowie czy nie?

0

Częściowo tak, masz narzuconą strukturę warstwy prezentacji, nawet początkującemu trudniej zrobić bałagan niż np. w WebForms. Ale jeśli zamkniesz logikę biznesową w prezenterach, a warstwę dostępu do danych w modelu (a tak pokazuje większość tutoriali w necie), to nadal będziesz miał syf. MVC odpowiada tylko za obsługę "komunikacji" z użytkownikiem, pozostałe operacje powinny być w innych warstwach.

Dostęp do danych (operacje na bazie)
|
Logika biznesowa (obliczenia, wystawianie faktur, stan magazynu, itd.)
|
MVC/MVP/inne - w zależności od preferencji i technologii

0

Mowiac o tych 3 warstwach masz na mysli to, ze w jednym sln powinny byc 3 projekty? Jedne odpowiedzialny za dzialania na bazie,drugi za logike i trzeci za prezentacje,dobrze rozumiem ?

0

A do tego czwarty z klasami pomocniczymi, piąty z obiektami domenowymi i jeszcze parę innych, ale wszystko w zależności od potrzeb.

0

Ok to juz czaje mniej wiecej o co chodzi jeszcze tylko wzorce i bedzie git:) dzieki.

1 użytkowników online, w tym zalogowanych: 0, gości: 1