OOP Najbardziej obiektowo jak tylko mozna...

Hej!

Mam do napisania mały programik do ewidencji polis, chociaż co on ma robić to nie jest ważne. Ważne jest rozplanowanie klas i wszystkich innych elementów programu.

Założenia są takie:

1. Mamy klientów: imię, nazwisko, adres, cokolwiek...
2. Polisy: majątkowe i komunikacyjne
3. Raty do spłaty powiązane z polisami.

Chciałbym prosić bo problem polega, żeby w tym programie wykorzystać maksymalnie wszystkie dobrodziejstwa OOP jak dziedziczenie, polimorfizm, hermetyzacja itp itd. Nie chce aby ktokolwiek implementował metody. Proszę jedynie o pomoc w zaprojektowaniu programu. Język nie ma znaczenia ale najlepiej Java.

a jak sobie wyobrażasz zrobienie projektu jeśli

co on ma robić to nie jest ważne

Misiekd napisał(a)

a jak sobie wyobrażasz zrobienie projektu jeśli

co on ma robić to nie jest ważne

Nie jest ważne dla tego postu bo nie z tym mam problem ale ogólnie dla mnie jest jedna z ważniejszych rzeczy.

Witam

Zgaduję ,że to program na zajęcia i jeśli tematem było jak najbardziej skomplikowane zakodowanie programu hello world(wpisz w googlach <<hello world="world" design="design" patterns="patterns">>. Pozdrów profesora.
Normalnie to powinno działać tak,że techniki obiektowe mają niejako ułatwić problem a nie stanowić jego dodatkowe utrudnienie ale skoro taka jest treść zadania to proponuję.

Klasa InsuranceFactory będzie zwracała dana implementację obiektu implementujacego interfejs polisa. Do tego dojdzie nam klasa klienta implementująca interfejs client, a ponieważ nie wiemy w która stronę rozwinie się system to rozdzielamy hierarchię interfejsów od implementacji przy pomocy klasy ClientInuranceBridge. Teraz każdy klient może spłacać polisę po swojemu ,wiec dochodzi hierarchia obiektów implementujących interfejs InsurancePayStrategy , która będzie zawierał klient, ale aby nasz system pozostał elastyczny wydzielmy spłacanie polisy z klienta i zaimplementujmy w osobnym obiekcie spłacanie rat. Aby clienta i komponent spłacający uczynić bardziej niezależnymi wprowadzamy klasę PayInsuranceCommand , która będzie wykonywała nam spłatę owej polisy. A ponieważ spłata spłacie nierówna i jej implementacja może się zmieniać dodajmy sobie może jakiegoś PayInsuranceVisitatora.
Ale co jeśli chcemy opłacić opłaconą polisę? Najlepiej niech jej Stan zadecyduje o jej zachowaniu. Więc dochodzą nam dwie nowe implementacje PaidInsurance i UnpaidInsurance.
Oczywiście klientów może być więcej, więc aby było bardziej obiektowo użyjemy sobie wzorca kompozyt do przechowywania i wzorca iterator do iterowania.Kolejne dwa obiekty.
Na sam koniec zróbmy obiekt PaiyngFasade ,która będzie miała tylko jedną metodę i ukryje złożoność rozwiązania przed klientem.

Autor nie bierze odpowiedzialności za powyższe rozwiązanie, stosowanie go w innych celach niż edukacyjnych tylko na odpowiedzialność osoby trzeciej.

Pozdrów Profesora

PS. Na pewno macie masę pomysłów jak owe rozwiązanie uczynić bardziej obiektowym : )

pozdrawiam

PawelW napisał(a)

Pozdrów Profesora

Pozdrowienia przekażę, dzięki za odpowiedź :-)

Czy można prosić outsidera albo pawelW o jpg jak to wyszło ostatecznie ?

na razie rozpisałem to tak ale nie jest to ostateczna wersja tego jestem pewien ;-P

package polisa;

import java.util.*;

public class InsuranceManager {
	public InsuranceManager() {

	}

	public static void main(String[] args) {
		InsuranceManager insuranceManager = new InsuranceManager();
	}
}

class Person {
	String pesel, imie, nazwisko;
	Address adres;
}

class Address {
	String ulica, nrdomu, nrmieszkania, kodpocztowy, miasto;
}

abstract class Insurance implements InsuranceInterface {
	Boolean payed;
	Date start, end;
}


interface InsuranceInterface {

}

class InsuranceChattel extends Insurance {
	
}

class InsuranceEstate extends Insurance {
	
}

class Instalment {
	
}

interface InstalmentInterface {
	
}

class ConsoleUI implements UserInterface { 
	
}

interface UserInterface {
	
}

juz bez przesady z tym OOP bo sie czas na traci na wymyslanie wszystkich szczegolow a i tak wpraniu wychodzi ze polowe metod trzeba wywalic a drugie tyle dodac i tyle à propos efektywnosci ;p

Po ostatnim projekcie zgadzam się w 100% z cepą.
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"
Ten cytat idealnie pasuje do programowania obiektowego.

rnd napisał(a)

"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

a co to znaczy w przełożeniu na polski ?

W C łatwo strzelić sobie w noge. W C++ trudniej ale gdy już to zrobisz, urywa ci całą nogę.
Błędy projektowe w OOP są wyjątkowo spektakularne szczególnie gdy się z obiektowością przesadzi.

rnd napisał(a)

W C łatwo strzelić sobie w noge. W C++ trudniej ale gdy już to zrobisz, urywa ci całą nogę.

W C łatwo strzelić sobie w stopę.

rnd napisał(a)

Błędy projektowe w OOP są wyjątkowo spektakularne szczególnie gdy się z obiektowością przesadzi.

Podaj przykłady.

Przykład: błędne użycie wzorca projektowego kompozyt. Traktowanie korzenia jak liścia jednak okazało się złym pomysłem tyle, że wyszło to nawierzch dopiero gdy już projekt był daleko posunięty. Skończyło się na ograniczonej funkcjonalności, korzystaniu z RTTI i metodach rzucających wyjątki typu UnsupporetedOperationException. Raczej mało eleganckie.
Do tego dochodzi kwestia o której mówi cepa - pisze się obiekty, tak na wszelki wypadek bo mogą się przydać, kod się robi skomplikowany, potem okazuje, że jednak coś innego by się przydało, więc trzeba to dopisać. Oczywiście tych błędów dało by się uniknąć gdyby zaprojektować wszystko dokładnie i starannie tylko, że zazwyczaj nie ma na to czasu.

rnd napisał(a)

Przykład: błędne użycie wzorca projektowego kompozyt. Traktowanie korzenia jak liścia jednak okazało się złym pomysłem tyle, że wyszło to nawierzch dopiero gdy już projekt był daleko posunięty. Skończyło się na ograniczonej funkcjonalności, korzystaniu z RTTI i metodach rzucających wyjątki typu UnsupporetedOperationException. Raczej mało eleganckie.

Wiesz jest to błąd projektowy. Błąd projektowy może się zdarzyć wszędzie gdzie występuje faza projektowania. No i gdzież tutaj owa "wyjątkowa spektakularność"? : >

pisze się obiekty, tak na wszelki wypadek bo mogą się przydać, kod się robi skomplikowany, potem okazuje, że jednak coś innego by się przydało, więc trzeba to dopisać. Oczywiście tych błędów dało by się uniknąć gdyby zaprojektować wszystko dokładnie i starannie tylko, że zazwyczaj nie ma na to czasu.

Kto pisze? Jakie obiekty? Na jakiej podstawie sądzisz ,że zazwyczaj nie ma czasu zaprojektować na staranne zaprojektowanie aplikacji?

Wydaje mi się ,że próbójesz udowodnić pewną tezę dotyczącą tworzenia rozwiązań informatycznych bazując na technice obiektowej, bazując na nieumiejętnościach osób ,które się ową techniką posługują.

pozdrawiam
</quote>

No i gdzież tutaj owa "wyjątkowa spektakularność"?

Liczyłeś na fruwające flaki czy wybuchające cysterny ? ;) Mówiąc spektakularność miałem na myśli sytuacje gdzie:
a) zmieniasz pół projektu co zajmuje mnóstwo czasu i potem program niekoniecznie działa
b) stosujesz kombinacje alpejskie a wynik i tak leży daleko od oczekiwanego

Kto pisze? Jakie obiekty? Na jakiej podstawie sądzisz ,że zazwyczaj nie ma czasu zaprojektować na staranne zaprojektowanie aplikacji?

Na podstawie swojego doświadczenia. Studia: brak na cokolwiek czasu. Praca - zależy gdzie się trafi. Raz trafiłem na firme gdzie nie było czasu ;)

Wydaje mi się ,że próbójesz udowodnić pewną tezę dotyczącą tworzenia rozwiązań informatycznych bazując na technice obiektowej, bazując na nieumiejętnościach osób ,które się ową techniką posługują.

Ludzie są tylko ludźmi i czasem strzeli się byka, który wyjdzie dopiero potem. Prawdopodobieństwo walnięcia takiego czeskiego błędu rośnie odwrotnie proporcjonalnie do ilości posiadanego czasu ;) Gdyby wszyscy idealnie projektowali i idealnie pisali aplikacje to nie było by bibliotek z assertami a testerzy nie mieli by pracy ;p

mi glownie chodzi oto ze jezeli z poczatku nie wiadomo co tak naprawde bedzie robil projekt i w jakim kierunku bedzie sie rozwijal (np: rozne app internetowe) to zbytnie przesadzanie z oop konczy sie tym ze mamy albo niepotrzebne obiekty albo sa one zle skonstruowane tak czy siak wszystko zaczyna sypac sie zgodnie z zasada ze jak cos jest do wszystkiego to jest do niczego, czasami po prostu lepiej uproscic sobie zycie kodzac prosto i przyjemnie;p