"pisać obiektowo" - znaczy jak?

witam
od jakiegos czasu sledze dyskusje w tym dziale odnośnie if..else.. i wiele razy pojawia sie w temacie pojecie "pisac obiektowo" lub "uzywac polimorfizmu". Pewnie pytanie wyda się troszkę trywialne, ale chciałbym się spytać co to znaczy to pisanie obiektowo. Nie chce zebyscie mnie zle zrozumieli. Nie chodzi mi tutaj o to by podać link do tutoriala z podstawami java i wszystko bedzie jasne.

Chodzi raczej o to, że najprostsza konstrukcja if..else.. jest w temacie ww. wrecz czasami absurdalnie negowana i zastanawiam się czemu. Czy to przez to, że "powinniśmy" pisac obiektowo? gdzie zaczyna sie granica głupoty w długości (w ilościach linii) jedej klasy oraz granica dzielenia jednej klasy na dziesiątki innych?
Czy klasa powinna miec jak najwiecej krótkich metod czy może kilka, ale dłuższych? czy właśnie tworzenie metod to podejście obiektowe?

Jak nauczyć się tak poprawnie pisać?:) może moglibyście polecić jakieś źródło wiedzy?

pozdrawiam!

Hmmm, nie umiem tłumacyzć ale tak:

• Obiekt jest to np, samochód, stół, człowiek itd.
• Metody to czynności czyli np: podnies_reke itd.

Jeżeli Tworzysz klase, np. ssaski to wiadomo, że warto stworzyc klasy które bedą dziedziczyć cechy wspólne z klasy saki, jeśli jednak tworzysz tylko jedną klase np. samochód, dodajemy mu atrybuty(kola, silnik itd...), a do niego czynności - metody.
Długośc i ilośc metod jest zależna od, ilości akcji jakie będzie miał dany obiekt.
Obiekty dzielić musisz, nie chcesz chyba mieć stołu połączonego z krzesłem, lub rybe z psem - od tego warto tworzyć obiekty.

To chyba najprościej jak można napisać - nie wiem, nie znam się. Reszta to chyba doswiadczenie.
Dużó na ten temat można znaleźć w google:
http://xion.org.pl/files/texts/mgt/html/1_7.html
http://e-java.pl/kurs-java/kurs-javaczesc-4-programowanie-obiektowe/idea-programowania-obiektowego/

Pisanie obiektowe jest problemem filozoficznym w stylu "Być czy mieć". Samo tworzenie interfejsów (klasy to tylko miły dodatek) pozwala na definiowanie bytu - możliwości interakcji z danym obiektem. Z drugiej strony masz problem "posiadania", czyli tego jak współpracują obiekty. O ile w prostych, podręcznikowych, przypadkach wiadomo mniej więcej jak to powinno działać np. ferrari jest samochodem i ma koła, to już praktyka pokazuje, że można się nieźle "zakałapućkać" - w samochodzie należy wymienić koła - jak to zrobić obiektowo i nie zagmatwać kodu?

Programowanie obiektowe to pewne podejście, które ułatwia nam zrozumienie modelu biznesowego i pracę z nim. Czasami się sprawdza, a czasami... no cóż... pozostaje Prolog.

Wydaje mi się, że obiekty warto sobie ćwiczyć itp. Obiekt jest twoim polem i to co na nim robicz co sadzisz co zmieniasz, zależy tylko od twojej wyobraźni i ograniczeń języka, W wielu sytuacjach są niezastąpione a szczególnie do interfejsów. Źródłem wiedzy dla ciebie niech będzie twoja wyobraźnia i podstawowa wiedza budowania obiektu nic więcej nie potrzebujesz reszta sama przyjdzie.