Temat: Programowanie NIE-obiektowe

W każdym ogłoszeniu pracy dla programisty znajdziemy dziś informację: "umiejętność OOP wymagana"

Czy może to świadczyć o pewnej "faworyzacji" jednego z modeli ?

Nie ma jednak "róży bez kolców"

Zapraszam do dyskusji zwolenników alternatywnych i obiektowych metodologii :)

Czy należy bezwzględnie opanować OOP ?

Temat: Programowanie NIE-obiektowe

Jarosław K.:
Czy należy bezwzględnie opanować OOP ?

tak, no chyba ze chcesz sie zatrzymac na poziomie projektow do hmm kilku tys lini max.

dlaczego:?
- przenosi rozwazanie o problemie na nowy wyzszy poziom abstrakcji uniezalezniony od platformy, ktory lepiej odwzorowuje rzeczywistosc, w przeciwienstwie do myslenia o programie jak o algorytmie z wejsciem i wyjsciem
- logika jest podzielona na mniejsze elementy (obiekty), ktore moga wchodzic w interakcjie miedzy soba, zamiast masy funkcji i jeszcze wiekszej ilosci zmiennych/struktor
- enkapsulacja danych
- ponownie wykorzystanie kodu (trzeba naprawde dobrze pisac w jezyku proceduralnym aby kod sie pozniej nadawal do czegokolwiek)
- latwiejszy refactoring kodu (logika zamknieta w obiekcie, jezeli zmieniam kod moge skupic sie na testowanie jednego kawalka projektu)
- obiekt jest sam w sobie namespace'm przez co upraszcza sie styl kodowania i struktura kodu

no i jezeli jest to juz grupa php, to programowanie proceduralne w php jest wybitnie sieczkogenne :S

inna kwestia, ze kazdy program obiektowy mozna byc zamienic na strukturalny

z innych podejsc do programowania, imho zajebiste jest programowanie generyczne (meta programowanie), ale to wlasciwie rozszerzenie oop

//edit: niestety, oop to slogan, nie wszedzie OOP = OOP, niektorym wydaje sie ze samo stosowanie slowka kluczowego class to juz ŁoŁoPe :)Łukasz Cepowski edytował(a) ten post dnia 15.10.09 o godzinie 21:04

Temat: Programowanie NIE-obiektowe

OOP nie jest srebrną kulą, ale się przydaje, bo jest obecnie na topie i raczej jeszcze długo pobędzie (niby rewolucyjne rzeczy jak programowanie funkcyjne albo aspektowe jakoś się nie przebiły), i w takim paradygmacie opisywane są modne młotki - różnego rodzaju wzorce projektowe i takie tam - i to jest IMO główna zaleta znajoomści OOP, żeby nie szuakć długo: http://www.ibm.com/developerworks/library/os-php-desig... - pierwszy link z googla.

Przepaść pomiędzy programowanie proceduralnym a obiektowym w PHP jest głeboka dlatego że nie ma w PHP odpowiednika struct z C (rekordu z Paszczala), więc nie ma enkapsulacji danych tak o i wszystko wala się gdzie popadnie. Samą enkapsulację można emulować przez tablice asocjacyjne, tylko wtedy kontrola typów idzie się...

Co do listy zales OOP podanych wyżej:
- program dalej jest algorytmem z wejściem i wyjściem, niezależnie czy jest strukturalny, obiektowy czy funkcyjny
-- to samo można powiedzieć o modułach i bibliotekach, metody nadal są procedurami, tylko OOP wymusza jakieś ich uporządkowanie. Jak ktoś programuje syfiasto, to nadal to będzie syfiasto wyglądało, ale cośtam daje;
- z enkapsulacją jest tak, że jest fajna wtedy gdy jest fajna, nieraz już kląłem bo ktoś zenkapsulował coś, co jakby było odkryte zaoszczędziłoby sporo kodu, w większym projekcie dotykanie wszystkiego może przynieść dość opłakane efekty;
-- metody to nadal funkcje, parametry stubuje się tak samo.

OOP trochę utrudnia strzelenie sobie w stopę.

Temat: Programowanie NIE-obiektowe

Jakub L.:
Przepaść pomiędzy programowanie proceduralnym a obiektowym w PHP jest głeboka dlatego że nie ma w PHP odpowiednika struct z C (rekordu z Paszczala), więc nie ma enkapsulacji danych tak o i wszystko wala się gdzie popadnie. Samą enkapsulację można emulować przez tablice asocjacyjne, tylko wtedy kontrola typów idzie się...

ale co ma enkapsulacja do tablicy asocjacyjnej? tablice asocjacyjna mozesz uzywac jak struktury, ale danych w srodku nie ukryjesz, typow nie ma bo php jest jezykiem dynamicznie typowanym ale to tez sie ma nijak do enkapsulacji

- program dalej jest algorytmem z wejściem i wyjściem, niezależnie czy jest strukturalny, obiektowy czy funkcyjny

zgadza sie, ale chodzilo mi o myslenie w kategori problemu umiejscowionego w jakims tam wirtualnym swiecie w przeciwienstwie do myslenia o programie jako narzedziu ktore wykona pare konkretnych instrukcji atomowych na zbiorze A i wypluje zbior B

-- to samo można powiedzieć o modułach i bibliotekach, metody nadal są procedurami, tylko OOP wymusza jakieś ich uporządkowanie.

technicznie tak, ale w oop mozesz tworzyc ukryte "procedury" dostepne jedynie w scope danego obiektu, pozatym dochodzi polimorfizm ktory umozliwia przeslanianie jednych metod innymi bez zmiany pozostalego kodu, a takze dziedziczenie dzieki czemu na nowym "typie" danych mozesz wykonywac te same operacje co na starym

- z enkapsulacją jest tak, że jest fajna wtedy gdy jest fajna, nieraz już kląłem bo ktoś zenkapsulował coś, co jakby było odkryte zaoszczędziłoby sporo kodu, w większym projekcie dotykanie wszystkiego może przynieść dość opłakane efekty;

to nie wina enkapsulacji tylko ch**owego projektu, imho enkapsulacja jest najbardziej przydatna wtedy jak przy rozwoju oprogramowania chcesz zachowac wsteczna kompatybilnosc przez dlugi czas

OOP trochę utrudnia strzelenie sobie w stopę.

ale umozliwia odstrzelenie calej nogi :)

Temat: Programowanie NIE-obiektowe

Równie dobrze można spytać, czy potrzebne są nam profesje - przecież można dobierać ludzi do konkretnego zadania ze względu na ich cechy osobiste i poszczególne zdolności. Niejeden elektryk umie kafelkować.

W oop masz klasy i wzorce - działasz jak z ludźmi - profesje i schematy pracy.

Jarosław K.:
Czy może to świadczyć o pewnej "faworyzacji" jednego z modeli ?

Tak. A dokładniej świadczy to o faworyzacji rozwiązań prostszych, intuicyjnych, przenośnych i skalowalnych nad innymi.

Nie ma jednak "róży bez kolców"

Nic się samo nie zrobi. Im więcej umiesz - tym więcej zdziałasz.

Czy należy bezwzględnie opanować OOP ?

Tak, choćby po to, żeby wiedzieć kiedy jest niepotrzebne :D

Uważam, że dyskusja jest trochę bezcelowa, bo OOP jest już standardem i żaby nie prowadzić rozważań o wyższości świąt Wielkiej nocy nad Bożym Narodzeniem, wypadałoby zapytać "Jak i gdzie stosować OOP"

Na koniec jakiś konkret ZA. Spróbuj pomyśleć w takich kategoriach:
- Z OOP mogę zlecić wykonanie klasy która spełnia konkretne zadanie i zająć się ogólna strukturą programu.
- Z OOP mogę pominąć specjalistyczne rozwiązania i przygotować szkic programu, bez znajomości pewnych bibliotek a kod mojego programu głównego przypomina przepis na ciasto, przez co każdy programista, który na to spojrzy od razu wie co się dzieje w każdym miejscu.
- Z OOP nie muszę wyważać otwartych drzwi, ponieważ standardowe problemy mają swoje pewne i sprawdzone rozwiązania, często dostępne w postaci gotowych bibliotek, których nie muszę znać na wylot - ważne, że znam publiczne metody.

Oczywiście na upartego możesz stosować funkcje i udowodnić że da się coś zrobić strukturalnie. Tylko nie zawsze fakt, że się da oznacza, że tak jest dobrze. Obiektowość narzuca pewne schematy myślenia o konstrukcji programu, które ułatwiają pracę. Jeżeli nie myślisz obiektowo to się zajedziesz :)

Temat: Programowanie NIE-obiektowe

Ja bym raczej spojrzał na OOP jako pewien element układanki, część projektów na nim bazuje, więc trzeba rozumieć i znać obiektówkę żeby się rozwijać. Dobrze jest dla równowagi przestudiować parę magicznych skryptów perlowych, krókie, zabójczo skuteczne i nieprzyjemne w czytaniu ;-)
Zachwyconym OOP polecam jakieś środowisko graficzne w Javie np Swing i zrobienie w tym jakiegoś dziwnego elementu gui, dystans do oop gwarantowany ;-)
Na koniec jeszcze jakiś projekt w pythonie np Trac niby oop a nie to samo co java. Ważne jest żeby patrzeć z różnych perspektyw na programowanie.

Temat: Programowanie NIE-obiektowe

Łukasz Cepowski:

Jarosław K.:
Czy należy bezwzględnie opanować OOP ?

tak, no chyba ze chcesz sie zatrzymac na poziomie projektow do hmm kilku tys lini max.

Istnieją projekty (znacznie więcej niż kilka tys lini max), które nie korzystają z paradygmantu obiektowego (przynajmniej na poziomie kodu).
Istnieją tez inne metody "organizacji" kodu.

Dlaczego ?

dlaczego:?
- przenosi rozwazanie o problemie na nowy wyzszy poziom abstrakcji uniezalezniony od platformy, ktory lepiej odwzorowuje rzeczywistosc, w przeciwienstwie do myslenia o programie jak o algorytmie z wejsciem i wyjsciem
- logika jest podzielona na mniejsze elementy (obiekty), ktore moga wchodzic w interakcjie miedzy soba, zamiast masy funkcji i jeszcze wiekszej ilosci zmiennych/struktor
- enkapsulacja danych
- ponownie wykorzystanie kodu (trzeba naprawde dobrze pisac w jezyku proceduralnym aby kod sie pozniej nadawal do czegokolwiek)
- latwiejszy refactoring kodu (logika zamknieta w obiekcie, jezeli zmieniam kod moge skupic sie na testowanie jednego kawalka projektu)
- obiekt jest sam w sobie namespace'm przez co upraszcza sie styl kodowania i struktura kodu

Zgadzam się z tymi zaletami.
Chciałbym jednak aby ta dyskusja pokazywała alternatywy i przyświecające im cele.

no i jezeli jest to juz grupa php, to programowanie proceduralne w php jest wybitnie sieczkogenne :S

To akurat fakt, widziałem kod w którym bez względu na wszystko zlecił bym stosowanie OOP (przepraszam za slogan)

Zawsze w opozycji do OOP stawia się abstrakcję niższego poziomu, a ja pytam o alternatywne podejścia - nie koniecznie strukturalne, lecz bez użycia obiektów.

inna kwestia, ze kazdy program obiektowy mozna byc zamienic na strukturalny

Dzięki czemu zajmie mniej pamięci i będzie efekywniejszy :)

z innych podejsc do programowania, imho zajebiste jest programowanie generyczne (meta programowanie), ale to wlasciwie rozszerzenie oop

A gdyby przeskoczyć jedem poziom abstrakcji pomijająć pośredni ?

Temat: Programowanie NIE-obiektowe

Jarosław K.:
Istnieją projekty (znacznie więcej niż kilka tys lini max), które nie korzystają z paradygmantu obiektowego (przynajmniej na poziomie kodu).
Istnieją tez inne metody "organizacji" kodu.

tak, widoczne to jest np w C, i problem sie robi kiedy masz kilkadziesiat tys. lini kodu z prostego faktu ze koncza sie sensowne sposoby nazywania funckji/zmiennych, co do organizacji to przykladowo GTK jest napisane w C ktore jest jezykiem proceduralnym/strukturalnym ale sama organizacja kodu jest... obiektowa:
zalety:
- mniej problemow z nazewnictwem i utrzymaniem kodu
wady:
- dluuuugie nazwy funkcji jak biblioteka_jakas_funkcja_ktora_robi_cos
- niskopoziomowe dziedziczenie w oparciu struktury, podejzewam ze ta metoda by nie przeszla w innych jezykach

inna kwestia, ze kazdy program obiektowy mozna byc zamienic na strukturalny

Dzięki czemu zajmie mniej pamięci i będzie efekywniejszy :)

w php byc moze ale w normalnych ]:-> jezykach argument jak najbardziej nietrafiony :)
kod kompilowany np: w C++ jest optymalizowany, dochodza takie rzeczy jak metody inline i kompilowanie tak aby pozbyc sie niepotrzebnych skokow,
w javie metodamy inline zajmuje sie kompilator, i nie wiem czy nie jvm cos tam miesza dodatkowo, ale glowy sobie za to nie dam uciac :)

A gdyby przeskoczyć jedem poziom abstrakcji pomijająć pośredni ?

tzn?

Temat: Programowanie NIE-obiektowe

A gdyby przeskoczyć jedem poziom abstrakcji pomijająć pośredni ?

Programując w językach wysokiego poziomu już pomijasz warstwę niskopoziomową. Co więcej, jak u Ogrów, są tam warstwy ... tyle tylko, że nie musisz o nich wiedzieć, żeby napisać program. Sam wspominasz, żeby przeskoczyć - a nie pominąć, zatem ten pośredni poziom musi istnieć, ktoś to musi obiektowo napisać i udostępnić Ci narzędzie wyższego poziomu. I jesteśmy w domu zwanym IDE lub innym , zwanym Framework.

Ale to nie alternatywa, tylko konsekwentny postęp.

Temat: Programowanie NIE-obiektowe

Łukasz Cepowski:

ale co ma enkapsulacja do tablicy asocjacyjnej? tablice asocjacyjna mozesz uzywac jak struktury, ale danych w srodku nie ukryjesz, typow nie ma bo php jest jezykiem dynamicznie typowanym ale to tez sie ma nijak do enkapsulacji

A co myślisz o takiej "enkapsulacji" ?

function object_1($construct)

{

    $data=array(); // private data



    if()

    $object=create_function($data,$implementation1);

    else

    $object=create_function($data,$implementation2);       

}

-- to samo można powiedzieć o modułach i bibliotekach, metody nadal są procedurami, tylko OOP wymusza jakieś ich uporządkowanie.

I tu zgadzam się w 100% OOP bardzo porządkuje kod i pracę - stanowi standard.Jarosław K. edytował(a) ten post dnia 15.10.09 o godzinie 22:22

Temat: Programowanie NIE-obiektowe

Łukasz Rylik:

W oop masz klasy i wzorce - działasz jak z ludźmi - profesje i schematy pracy.

Model jest zasadniczo dobry :)

Jarosław K.:
Czy może to świadczyć o pewnej "faworyzacji" jednego z modeli ?

Tak. A dokładniej świadczy to o faworyzacji rozwiązań prostszych, intuicyjnych, przenośnych i skalowalnych nad innymi.

wolniejszych i bardziej ekstensywnych "kropka" :)

Nie ma jednak "róży bez kolców"

Nic się samo nie zrobi. Im więcej umiesz - tym więcej zdziałasz.

True :)

Czy należy bezwzględnie opanować OOP ?

Tak, choćby po to, żeby wiedzieć kiedy jest niepotrzebne :D

:D

Uważam, że dyskusja jest trochę bezcelowa, bo OOP jest już standardem i żaby nie prowadzić rozważań o wyższości świąt Wielkiej nocy nad Bożym Narodzeniem, wypadałoby zapytać "Jak i gdzie stosować OOP"

Chodziło mi o troszkę inną dyskusję :)
"Jak i gdzie nie stosować OOP - i co w zamian ?"

Oczywiście na upartego możesz stosować funkcje i udowodnić że da się coś zrobić strukturalnie. Tylko nie zawsze fakt, że się da oznacza, że tak jest dobrze. Obiektowość narzuca pewne schematy myślenia o konstrukcji programu, które ułatwiają pracę. Jeżeli nie myślisz obiektowo to się zajedziesz :)

Co do schematów zgadzam się, jednak nie stosowanie OOP, nie znaczy, że nie myslisz obiektowo - przykład GTK.

Temat: Programowanie NIE-obiektowe

Jarosław K.:

function object_1($construct)

{

    $data=array(); // private data



    if()

    $object=create_function($data,$implementation1);

    else

    $object=create_function($data,$implementation2);       

}

ale to funkcje lambda ktore podpina sie pod paradygmat programowania funkcyjnego :)
dla mnie enkapsulacja to poprostu zablokowanie bezposredniego dostepu do skladowych pol obiektu a wzamian za to udostepnienie konkretnego api na zasadzie fasady

Temat: Programowanie NIE-obiektowe

Łukasz Cepowski:

Jarosław K.:
Istnieją projekty (znacznie więcej niż kilka tys lini max), które nie korzystają z paradygmantu obiektowego (przynajmniej na poziomie kodu).
Istnieją tez inne metody "organizacji" kodu.

tak, widoczne to jest np w C, i problem sie robi kiedy masz kilkadziesiat tys. lini kodu z prostego faktu ze koncza sie sensowne sposoby nazywania funckji/zmiennych, co do organizacji to przykladowo GTK jest napisane w C ktore jest jezykiem proceduralnym/strukturalnym ale sama organizacja kodu jest... obiektowa:
zalety:
- mniej problemow z nazewnictwem i utrzymaniem kodu
wady:
- dluuuugie nazwy funkcji jak biblioteka_jakas_funkcja_ktora_robi_cos
- niskopoziomowe dziedziczenie w oparciu struktury, podejzewam ze ta metoda by nie przeszla w innych jezykach

Dokładnie o to mi chodziło. Można więc programować obiektowo bez obiektowości na poziomie kodu...

inna kwestia, ze kazdy program obiektowy mozna byc zamienic na strukturalny

Dzięki czemu zajmie mniej pamięci i będzie efekywniejszy :)

w php byc moze ale w normalnych ]:-> jezykach argument jak najbardziej nietrafiony :)

Też się nie zgadzam ale nie chciał bym abyśmy dyskusje zmienili w spór!

kod kompilowany np: w C++ jest optymalizowany, dochodza takie rzeczy jak metody inline i kompilowanie tak aby pozbyc sie niepotrzebnych skokow,

Wiem, ale optymalizacja maszynowa nigdy nie zastąpi specjalizowanego rozwiżania. Patrz: architektura RISC/CISC i powrót do metodologi ze specjalizowanymi układami sprzętowymi.

w javie metodamy inline zajmuje sie kompilator, i nie wiem czy nie jvm cos tam miesza dodatkowo, ale glowy sobie za to nie dam uciac :)

Każna pośrednia warstwa zwięszka złożoność, zajętość pamięci itd a co za tym idzie zmniejsza możliwości systemu.

A gdyby przeskoczyć jedem poziom abstrakcji pomijająć pośredni ?

tzn?

Gdy ludzie przeskoczyli z ASM do C zapomnieli prawie o GOTO, być może gdy ludzie przeskoczą z OOP do ... zapomną o obiektach :)

Temat: Programowanie NIE-obiektowe

Łukasz Cepowski:

Jarosław K.:

function object_1($construct)

{

    $data=array(); // private data



    if()

    $object=create_function($data,$implementation1);

    else

    $object=create_function($data,$implementation2);       

}

ale to funkcje lambda ktore podpina sie pod paradygmat programowania funkcyjnego :)
dla mnie enkapsulacja to poprostu zablokowanie bezposredniego dostepu do skladowych pol obiektu a wzamian za to udostepnienie konkretnego api na zasadzie fasady

Patrz wyżej - masz API, masz fasade ( construct ) masz blokade dostępu
Funkcyjne nie funkcyjne - działa i realizuje CEL :)

Temat: Programowanie NIE-obiektowe

my tu sobie gadu gadu, a prawda jest taka ze soft trzeba napisac raz, dobrze i szybko :)

nie wazne w czym, jaki paradygmat itp bzdety, czy wykonanie metody dupa() zajmie 5 czy 50 cykli,
dla pani Krystyny z ksiegowosci bedzie wazne czy program robi to co ona oczekuje a nie czy zrobi to w 0.001s czy w 0.1s :P

a dla prezesa bedzie wazne ze programisci dopisza nowa funkcjonalnosc tydzien a nie w miesiac, i tu bym sie dopatrywal sukcesu łołope ;)

Temat: Programowanie NIE-obiektowe

Przepaść pomiędzy programowanie proceduralnym a obiektowym w PHP jest głeboka dlatego że nie ma w PHP odpowiednika struct z C (rekordu z Paszczala),

Odpowiednikiem struct w PHP jest class

Temat: Programowanie NIE-obiektowe

Jarosław K.:
Patrz wyżej - masz API, masz fasade ( construct ) masz blokade dostępu
Funkcyjne nie funkcyjne - działa i realizuje CEL :)

no a wez pozniej utrzymuj taki kod, mase takiego kodu :P
poco udziwniac rzeczy proste :D

Temat: Programowanie NIE-obiektowe

Jarosław K.:

Przepaść pomiędzy programowanie proceduralnym a obiektowym w PHP jest głeboka dlatego że nie ma w PHP odpowiednika struct z C (rekordu z Paszczala),

Odpowiednikiem struct w PHP jest class

oj tego z C nie ma, ani struct ani tym bardziej union

struktura to nie tylko pudelko na zmienne! :P

Temat: Programowanie NIE-obiektowe

Łukasz Cepowski:
my tu sobie gadu gadu, a prawda jest taka ze soft trzeba napisac raz, dobrze i szybko :)

Z biznesowego pkt. widzenia masz całkowitą racje ;)

nie wazne w czym, jaki paradygmat itp bzdety, czy wykonanie metody dupa() zajmie 5 czy 50 cykli,
dla pani Krystyny z ksiegowosci bedzie wazne czy program robi to co ona oczekuje a nie czy zrobi to w 0.001s czy w 0.1s :P

Dla Pani Krystyny może i nie ale dla użytkowników portalu, których jest milion - już tak...

a dla prezesa bedzie wazne ze programisci dopisza nowa funkcjonalnosc tydzien a nie w miesiac, i tu bym sie dopatrywal sukcesu łołope ;)

A dla innego prezesa czy użytkownicy portalu będą z niego w ogóle korzystać :)

Temat: Programowanie NIE-obiektowe

Łukasz Cepowski:

no a wez pozniej utrzymuj taki kod, mase takiego kodu :P
poco udziwniac rzeczy proste :D

Dla sztuki!