Forum PHP.pl

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

Moim zdaniem źle podszedłeś do sprawy. Zły przykład i nietrafne argumenty.

Jak już się przyczepiłeś tej kromki chleba... z czego ona powstała? Ze zboża, czy zbożem się najesz? nie, kromka chleba, bułka, rogalik itp dziedziczą po zbożu, który jest odpowiednio obrabiany. Załóż, że zboże to pewnien standard produkcji pieczywa, nie wyprodukujesz go z plastku. Teraz przykład w php.

Mamy abstrakcyjny kontroler z pewnymi metodami, np api __get(), __set(), itp. Wśród nich jest także metoda index() uwględniona w interfejsie, jaki ten abstrakcyjny obiet implementuje. Index to swego rodzaju przymus (standard pieczywa) działania kontorlera, gdyż bez niego (w wypatku braku akcji) zostanie on ewentualnie odpalony. Czym jest dla porównania metoda abstrakcyjna? Może w niej zostać zaprojektowane zupełnie co innego dla dziecka niż dla rodzica, z tym że dziecko potrzebuje metody rodzica. Przykład? obróbka danych:

[PHP] pobierz, plaintext 
<?php
 
interface ObrabiarkaTablic
{
  function obrobka($aTablica);
}
 
class Rodzic
{
  abstract function obrobka($aTablica)
  {
	// wykonanie jakis operacji
	return $aTablica;
  }
}
 
class Dziecko extends Rodzic implements ObrabiarkaTablic
{
  public function obrobka($aTablica)
  {
	// poprzednia filtracja danych:
	$aTablica = parent::obrobka($aTablica);
	// inna przerobka danych
}
 
?>
[PHP] pobierz, plaintext 

To są mechanizmy języka. Skoro powstało pojęcie klasy abstrakcyjnej, to dla mnie jak najbardziej w porządku jest włączenie tego do języka (czyli wyskakujące błędy, gdy taki obiekt stworzę).



Zapewne nigdy nie rozwijałeś kodu po innym programiście, albo nie wracałeś do swojego projektu po długiej przerwie. Spróbuj kiedyś.



Widzisz, naprawdę tu powinno sie przytoczyć jakieś cytaty z mądrych książek i najlepiej kilka real life examples. Istnieją metody prywatne i metody publiczne, do jednych jest dostęp z zewnątrz obiektu, do innych nie ma - koniec i kropka. Jeżeli uzywam tego przy programowaniu, używam tego nie bez kozery.



Sam sobie odpowiedziałeś, to zabezpiecza programistę - sprawia, że mozliwości popełnienia błędu maleją.



No, cześć, cześć smilingsmiley.gif

Ten post edytował LBO 3.04.2007, 18:32:29

Dzieki za wyjaśnienie, rozumiem w czym rzecz.

Czyli jak widzę OOP to rzeczywiście bardziej dziecko inżynieri programowania niż np. algorytmiki. Może dlatego nie całkiem mogę to pojąć, choć widzę zalety.

Pozdrawiam

Tylko w opisie pojawił się pewien bug, bo bułki/chleb agregują zboże (czy raczej pieczywo to robi, i dodatkowo inne składniki), a nie dziedziczą... a bułki i chlew dziedziczą po pieczywo (mniej więcej, zleży jak to dokładnie rozpisywać)

To już bardziej dziedziczenie wielopoziomowe, nie chciałem tutaj wprowadzać kogoś w obszar głębszego rozmyślania, tylko podac jakis przykład, ale słuszna uwaga



Z czasem, jak nabierzesz więcej doświadczenia, będziesz całował interfejsy i abstrakty po nogach - gwarantuję. Teraz póki co dostałeś suche przykłady, postaraj się je wykorzysać we wzorcach projektowych, zobaczysz, że naprawdę się przydają i coś z tego de facto jest.

To w sumie pokazuje jeszcze jedno, gdyż pieczywo jest interfejsem (lub abstrakcją, zależy jak zdefiniujemy) to chyba logiczne jest, że nie można tworzyć obiektu tego typu, bo takie coś nie może istnieć, dlatego kompilator/interpreter powinien wyrzucić błąd.

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 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.

Chyba coś Ci się pomieszało, bo protected nie pozwala na uruchomienie metody z zewnątrz ale jest dziedziczone, aby nie można było dziedziczyć to private aby nie można było nadpisać final.

Nie nie pomieszało mi się nic, bo napisałem jeśli ktoś chciałby dziedziczyć po klasie i używać jej metod, może tylko dla jasności nie dopisałem że w klasie dziedziczonej.

Ale przy protected w klasie dziedziczącej jest widoczna, właśnie po to się ustawia tą widoczność aby nie można było jej z zewnątrz wywołać, ale w klasie dziedziczącej jak najbardziej.
Zacytuję, bo chyba tego nie widzisz:

wtedy musi być private

No to sie chyba faktycznie nie rozumiemy, bo poprawiasz mnie tak samo ja ja piszę.
Podsumowywując krótko i jednoznacznie:
private - metoda widoczna tylko w klasie w ktorej jest definicja tej metody, niewidoczna w klasach potomnych ani poza klasą
protected - tj private a dodatkowo widoczna w klasach potomnych
public - tj protected a dodatkowo poza klasą

Dziwisz się później, że nikt Cię nie rozumie. Napisz to jak po ludzku a nie się bawisz
Jak protected to protected a nie jakieś "ale".

private - składowe klasy (pola, funkcje) widoczne (czyli dostęp do niech) tylko i wyłącznie wewnątrz klasy;
protected - składowe klasy, do których dostęp jest z wewnątrz klasy oraz wewnątrz klas dziedziczących.
public - składowe klasy do których dostęp można uzyskać w dowolnym miejscu aplikacji.

Ten post edytował mike_mech 3.04.2007, 21:19:43

W mojej skromnej opinii, klasy abstrakcyjne, finale i interfejsy, to błogosławieństwo. Wiem to z doświadczenia, bo kod którego używam rozwijałem przez ponad rok w różnych odstępach czasu. Z dużą ilość modyfikacji, różnymi stylami programowania, ale zgodnie z OOP i teraz poprawia oraz używa się to cudownie.

Specjalnie dla niedomyślnego pana Athlana uzasadnienie:
Mam ok. 50 klas, które były pisane na przestrzeni 1 roku i gdyby nie jasno zdefiniowane interfejsy itp. , miałbym spore problemy, z powrotem do programowania, po przerwie jaką sobie ostatnio zrobiłem (2 miesiące).

Ten post edytował Turgon 4.04.2007, 18:22:43

dołączę się do tematu klasa Rodzic musi być abstrakcyjna chyba, tak

kurde czegoś tu nie rozumiem, no po co tak robić
class Dziecko extends Rodzic implements ObrabiarkaTablic
nie można by tylko
class Dziecko extends Rodzic
bo jakoś oprócz tego że wymuszają w klasie która dziedziczy zaimplementowanie odpowiednch funkcji nie widzę idei proszę o jaśniejsze wytłumaczenie po co to używamy

Ten post edytował enigma 1.05.2007, 16:47:54

Interfejsy zostaly wziete z Javy, gdzie zmienna musi miec typ:

a to wszystko po to zeby mozna bylo wykonac

bo kompilator musi wiedziec czy na obiekcie 'ot mozna wywolac obrobka().

W PHP nie ma typowania zmiennych i mamy duck-typing, tzn. jesli na obiekcie wywolamy metode a on ja posiada to jest OK, czyli -> interfejsy sa niepotrzebne od strony wykonania, 'kompilacji' a bardziej do dokumentacji kodu, ogarniecia jego struktury

Tu po prostu Rodzic powinien implementować ObrabiarkaTablic, a wtedy nie trzeba dzieciom tego pisać, bo to jest z rodzica (jeśli się nie mylę przy takiej składni w Java też by nie było problemu)
A dodanie interfejsu to raczej kiedy rozszerzany jest rodzica, np. amfibia dziedziczy po samochodach, ale też implementuje łodzie, bo może pływać

czyli przy każtym projekcie robić sobie klasy abstrakcyjne i interfejsy


czyli wielodziedziczenie

oprócz tych dwóch, są jeszcze jakieś zastosowania ?

--EDIT
przeczytałem wszystkie topiki na forum o interfejsach i klasach abstrakcyjnych ale jeszcze czegoś mi brakuje musze się z tym przespać

w jednej ksiżące znalazłem fajny przykład dla kals abstrakcyjnych
mamy klasę ssak no co to jest, nic konkretnego, nie można mieć obirektu klasy ssak, to byłoby bez sensu, więc robimy abstrakcję i dziedziczymy po niej
chyba dobre jeszcze żeby tak ładnie były interfejsy wytłumaczone

Ten post edytował enigma 2.05.2007, 14:15:09

Ale interfejsy sa bardzo proste do zrozumienia. Stosuje sie je najczęściej kiedy jakaś klasa moze byc wymieniona na inna. Np. handler sesji, Router. Wtedy w interefejsie zawierasz które metody są wymagane do poprawnego działania nowej klasy z pozostałymi i jazda

A co do przykladów... Ja nie wiem po co ludzie w tych wszstkich książkach dają te durne odniesienia do samochodów, zwierząt. Jak czytałem ksiązki to nigdy tego nie mogłem poją. Dopiero jak pracowałem z kodem to wszystko sie wyjasniło. Takie przykłady wprowadzają tylko bezsensowne zamieszanie.

Ten post edytował menic 13.05.2007, 10:14:31

Interfejsy to dla mnie głównie nowe typy, które można wymusić.
Proszę pominąć niedociągnięcia w implementacji

[PHP] pobierz, plaintext 
<?php
interface inteligencjaNaPewenymPoziomie{}
abstract class Ssaki{}
 
class Czlowiek extends Ssaki implements inteligencjaNaPewenymPoziomie{}
class Orangutan extends Ssaki{}
 
// 2  podobne, ale jakże różne klasy Budowniczy
 
class Budowniczy{
 
function budujSamolot(Ssaki $object){}
function budujSamolot(Ssaki $object); //orangutan z powodzeniem wybuduje na samolot : )
function malujWPaincie(Ssaki $object){} // orangutan i czlowiek mogą używać Painta(TM)
}
 
 
class Budowniczy{
 
function __construct(Ssaki $object){}
function budujSamolot(inteligencjaNaPewenymPoziomie $object){} // tutaj tylko obiekt typu inteligencjaNaPewenymPoziomie bedzie mógł wykonać zadanie
function malujWPaincie(Ssaki $object){} // orangutan zawsze może pomalować : P
}
?>
[PHP] pobierz, plaintext 

Pozdrawiam.

Ten post edytował Cysiaczek 13.05.2007, 11:59:59