OOP. Interfejsy oraz klasy abstrakcyjne, Zabezpieczenie przed programistą? Opcje

[Jabol]

Witam,

Nawiązując do http://forum.php.pl/index.php?showtopic=64555&st=80 chciałem troszkę rozjaśnić swoje zdanie na temat obiektowości w programach. Rozumiem koncept OOP i dzielenia aplikacji na obiekty - logiczne, wszystko dzieli się według zastosowania. Ale OOP to nie tylko taki podział. Potem dochodzą do tego interfejsy oraz klasy abstrakcyjne. Rozumiem interfejs, ale czemu interfejs nie może być normalną klasą, przecież i tak nie ma być wykorzystywany w programie? To tak jakby sucha kromka chleba miała być niejadalna, bo jest tylko interfejsem do kromki z serem. A jest jadalna - tylko większość osób kładzie na nią dodatkowo ser czy cośtam. I teraz klasy abstrakcyjne. Rozumiem, że obiekty mają hierarchię, ale po co klasy abstrakcyjne? Jeżeli są to klasy, których nie nalaży używać, to wystarczy ich nie używać - na pewno są przecież bezużyteczne, inaczej nie byłyby abstrakcyjne.

Dlatego mam czasami wrażenie, że OOP to nie tylko standart projektowania, ale również inny troszkę tok myślenia. Rozumiem, że programista musi założyć, że użytkownicy to idioci. Bo oni mogą się nie znać. Ale jeżeli ktoś pisze jakąś obiektową bibliotekę, albo jeszcze gorzej strukturę programu dla siebie, to nie musi wychodzić z założenia, że jest idiotą. Jeżeli programista jest idiotą to jego sprawa, bo jego program i tak nie będzie działał - nie potrzeba do tego warningów/errorów kompilatora/interpretera. Tak samo metody prywatne. Jeżeli w dokumentacji będzie wspomniane nie używać, to mądry programista ich i tak nie użyje, a sprytny użyje i też będzie ok.

Dlatego nie rozumiem, po co w OOP ten cały mechanizm zabezpieczania programów przed... programistami, którzy je piszą?

Pozdrawiam

[Zeman]

Ja się jeszcze dorzucę.

Interfejsy w językach skryptowych odgrywają trochę inną rolę niż w językach kompilowanych.

Interfejsy w językach kompilowanych:
W językach kompilowanych interfejs daje możliwość symulowania dziedziczenia wielobazowego przy językach, które jako takiego dziedziczenia wielobazowego klas nie mają. Poza tym, interfejsy narzucają specyfikację i jakby karzą bezwzględnie tej specyfikacji się trzymać, znaczy się dla autorów klas które będą implementować dany interfejs. Następną i chyba główną cechą interfejsów w językach kompilowanych jest możliwość sterowania obiektem zdalnie, znaczy się jedna aplikacja może sterować obiektem który istnieje w innej aplikacji (programowanie rozproszone).


W językach skryptowych:
Tutaj interfejs jakby traci swoją moc dawania możliwości symulowania dziedziczenia wielobazowego, ponieważ język skryptowy metody wywołuje i tak po nazwach (tzw. późne wiązania). Narzucanie pewnej specyfikacji pozostaje tj dla języków kompilowalnych, natomiast jeśli chodzi o programowanie rozproszone to szczerze mówiąc nie wiem jak to jest w PHP, nic mi nie wiadomo żeby interfejsy w tym pomagały, zresztą cieżko mi sobie wyobrazić programowanie rozproszone w PHP (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) No, chyba że tylko jako aplikacja kliencka.


Pozwiodronka,
Zeman.


Aha, co do klas abstrakcyjnych, to jest takie narzucanie pewnej specyfikacji autorom klas chcącym dziedziczyć po danej klasie abstrakcyjnej.

Co do metod prywatnych (private), chronionych (protected) i publicznych (public), to jest to swego rodzaju umożliwienie pisania metod na wewnętrzny użytek klasy i eśli ktoś chciałby dziedziczyć po klasie i używać tych metod, to już nie może, wtedy metoda musi być conajmniej protected. Prosze mi uwierzyć że chowanie metod ma sens - niekiedy metoda niespecjalnie się nadaje do użytku z zewnątrz, a programista nie będący autorem danej klasy może popsuć skrypt jak jej nieumiejętnie użyje. Poza tym, utrzymuje porządek, nie kusi żeby kombinować (choć może i bardziej kusić).

Osobiście w PHP zwykłem często używać private, protected i public dla metod i pól, oraz często static. Interfejsów w PHP osobiście nie używam, ale w Delphi niemalże wszędzie.