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

[-=Peter=-]

Witam, może powinienem założyć nowy temat, ale wolę nie zaśmiecać forum (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) Napotkałem problem, oto kod który wg mnie powinien działać:

[PHP] pobierz, plaintext 
<?php
interface A{}
 
interface B extends A{}
 
interface C{
   public function metoda(A $obiekt);
}
 
abstract class D implements C{
   public function metoda(A $obiekt){
	  //jakas implementacja
   }
}
 
class E extends D{
   public function metoda(B $obiekt){
	  parent::metoda($obiekt);
   }
}
?>
[PHP] pobierz, plaintext 

Problem jest taki, że wywala błąd że metoda E::metoda nie jest kompatibilna z interfejsem C::metoda... (Declaration of E::metoda() must be compatible with that of C::metoda()). Tak, jest inne wymuszenie typu w klasie D, ale podany typ jest dziedziczony po interfejsie który jest wymuszony w interfejsie C...

Czyli podsumowywując, jeśli chcemy wymusić typ w interfejsie to już nie da się później w klasach implementujących ten interfejs, w tej metodzie wymusić typ, który dziedziczy po typie wymuszonym pierwotnie w interfejsie? (mam nadzieje, że zrozumiecie o co mi chodzi (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) ) Jak w takim razie to "obejść"? Czy może jest to jakiś bug w php5, albo dziwne i świadome ograniczenie? (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) Bo na "chłopski rozum" powinno to działać.

EDIT: pytanie jak to "obejść" raczej jest nie na miejscu, bo wiem jak to obejść, tylko trochę to jest niewygodne (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

EDIT2: znalazłem już odpowiedź (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) wg twórców php, nie jest to błąd. PHP nie sprawdza, czy rzutowany typ jest dziedziczony po tym, który został zrzutowany w interfejsie/klasie po której dana klasa jest dziedziczona. Wg mnie to trochę dziwne, no ale cóż poradzić...

Ten post edytował -=Peter=- 2.02.2008, 12:59:42