Wpis z mikrobloga

Mam moralnego kaca. Programuję od blisko 7 lat, pisałem wiele przedziwnych rzeczy - jedne wymagały wydajności, inne modułowości. Programowanie obiektowe daje niesamowite możliwości, mało kto wyobraża sobie bez niego współczesne systemy. Wszystko jednak mam wrażenie idzie w stronę gorszą niż Java - wzorce projektowe idą w kierunku wszędobylskich obiektów. O ile teoria "wszystko jest obiektem" brzmi pięknie to już jej realizacja w sposób wydajny jest prawdę mówiąc niemożliwa.

Doskonały przykład zbędnego overheadu stanowią proste gettery i settery zawierajace w swoim ciele wyłączenie return/przypisanie do prywatnego pola klasy. Chroni to wyłączenie przed podaniem złego typu argumentu ale wprowadza dość spory narzut w przypadku konstrukcji wywoływanych tysiące razy. A właściwie po co one powstają? No tak, co by progrmistę (!) ochronić przed wysypaniem kodu... no do cholery, czy nawet tutaj trzeba prowadzić za rączkę?

Do czego to do cholery zmierza? Chyba do hello world napisanego w 11 klasach (bo przecież każdy znak powinien mieć swój obiekt!).

Ehh... albo się starzeję albo rzeczywiście coś jest nie tak z dzisiejszymi standardami ()

p.s. Może znacie jakaś pozycję dot. wydajnego programowania obiektowego (po angielsku lub polsku)?

#programowanie #gorzkiezale #boldupy
  • 30
  • Odpowiedz
  • Otrzymuj powiadomienia
    o nowych komentarzach

@kiler129: Tja. Też mnie to denerwuje. Zobacz sobie np. takie Magento ;) Chcesz zrobić jeden model, musisz dodać katalogów, plików i zmodyfikować plików ze dwiejście w siedemnastu różnych miejscach. A potrzebujesz tylko jedno zapytanie, żeby nie #!$%@?ć go jak jakiś Hindus prosto w widoku. Siedzisz i myślisz czemu ten #!$%@? xml konfiguracyjny nie działa, w końcu po trzech godzinach myślisz sobie - #!$%@? z tym - i robisz w widoku.
  • Odpowiedz
@katinka: Mnie za to dość mocno wpienia filozofia Symfony. Każde najmniejsze działanie wymaga tak wielkiego overheadu, że nawet sam framework posiłkuje się generowaniem kodu do cache ( ͡° ͜ʖ ͡°)

Mam wrażenie, że twórcy tego frameworka chcieli mieć coś co jest bardzo elastyczne - udało się, ale jakim kosztem?

Fajnym przykładem "raka OOP" jest PSR-3 - zgodnie z nim eliminujemy cokolwiek co jest globalne (nawet w
  • Odpowiedz
@kiler129: Akurat narzut wydajnościowy w wypadku getterów i setterów to jest praktycznie żaden w większości biznesowych aplikacji. Dziwny przykład wybrałeś.
  • Odpowiedz
@mathix: Zależy od sposobu ich użycia. Innym przykładem niech będzie wszędobylskie wywoływanie kodu przesłanego w parametrze czyli calluserfunc() jeśli by już odwoływać się do konkretnego języka.

Nie mówię, że OOP jest beee, piszmy przepastne struktury - problem stanowią patterny które prześcigają się w utrzymaniu jak najbardziej modułowego i prostego w modyfikacji kodu. Problem w tym, że chyba zatracono jakiś zdrowy balans i programistę sprowadza się do roli małpy
  • Odpowiedz
@kiler129: Zobacz sobie tutorial jak dodać nowy moduł w Magento ;)

Przykładowo chcesz wyświetlić sobie jedną rzecz - jakiś widżecik czy banerek pobierany z bazy i chciałbyś to zrobić zgodnie z zasadami sztuki:
  • Odpowiedz
@katinka: Podobnie jest z bundlami w Symfony - też leci się generatorami bo pisanie tego z palca jest upierdliwe. Prawdę mówiąc nie wyobrażam sobie też wygodnej pracy bez przepastnego IDE (<3 Jetbrains) przy takiej konstrukcji kodu. To ma jednak zasadniczą wadę - w pewnym momencie nie wiesz co się dzieje a stacktrace niewiele ci podpowiada.

Pierwszy raz jak zobaczyłem te XMLe w Magento to się przeraziłem, gdy się w to
  • Odpowiedz
@katinka: To też nie jest do końca dobre. Wynajdywanie koła na nowo jest fajne ale niestety mało produktywne - wielu inżynierów przekonało się o tym próbując pisać własne implementacje kryptografii czy hashowania ( ͡° ͜ʖ ͡°)

  • Odpowiedz
przykład zbędnego overheadu stanowią proste gettery i settery


@kiler129: Bo to nie jest wtedy element programowania obiektowego, tylko zwykła struktura.

* enakpsulacja? brak – wszystko można odczytać i
  • Odpowiedz
@kiler129: odpowiadam z telefonu, wiec będzie krótko. Używanie getterów i setterów bezmyślnie jest typowe dla ludzi łudzących się, że programują obiektowo. Polecam zapoznać się z podejściem "objects calisthenics".
  • Odpowiedz
@katinka: @kiler129: ja się tylko odniosę do tego Magento

Problem z Magento i wieloma innymi serwisami tkwi w tym, że to nie są projekty budowane przez jednego programistę który pracuje tylko na swoim komputerze lokalnie i na serwerze live. Przy dużych serwisach pracuje przynajmniej kilku programistów i każda zmiana potencjalnie może ubić serwer na którym działa sklep który w ciągu minuty odwiedza setki uzytkowników. Ten overhead ma na celu takie zabezpieczenie aplikacji, żeby przez zupełny przypadek programista nie wygenerował strat na setki tysięcy (dowolnej waluty).

Twój przykład z utworzeniem tabelki w bazie i prostym zapytaniem. Oczywiście, prościej ją utworzyć w bazie w phpMyAdminie, wrzucić zapytanie do widoku i działa. Ale normalnie to zrobisz to na serwrze lokalnym -> póżniej musisz to przenieść na instancję deweloperską (tworzenie nowej tabelki w PMA na serwerze deweloperskim) -> później na instancję testową (tworzenie nowej tabelki w PMA na kolejnym serwerze) -> póżniej na live (tworzenie nowej tabelki na serwerze live). Ok, jeśli to Ty jesteś jedyną programistką w projekcie i element jest zaakceptowany przez klienta natychmiast po jego utworzeniu. Ale co jeśli to inny programista zrobi merge twojej gałęzi z serwerem live i nie będzie wiedział o tabelce? Wysypie stronę :D Albo klient zaakceptuje tę rzecz po miesiącu, a Ty już nie będziesz pamiętała, że trzeba jeszcze utworzyć
  • Odpowiedz
@kiler129: O jakim overheadzie mówisz? Przecież często używane gettery/settery są inline'owane przez JITa.

Po drugie całkowicie nie zgadzam się z tezą, że wszystko wymaga coraz więcej konfiguracji, ja obserwuję odwrotny trend. Zobacz np. Spring Boota albo np. scaffolding. Możesz sobie wygenerować prostego CRUDa w kilka minut.
  • Odpowiedz
@marrbacca: W takich sklepach i tak (gdzie chwila przestoju spowodowana jednym błędem może wygenerować setki tysięcy złotych straty) nikt Magento nie korzysta, bo taka krowa po prostu za wolna. Jak masz 140 000 produktów w ofercie a na promocję na raz rzuci ci się sklep kilkanaście tysięcy klientów, to nawet jak postawisz to na klastrze serwerów to będzie mulić. To już nawet nie Magento ale samo PHP i MySQL nie
  • Odpowiedz
@MacDada: Prawda jest jednak taka, że 90% modeli ma w większości g/s wygenerowane właśnie w ten sposób. I teraz dylemat - czy robić walidację do każdego pola ponad to co oferuje weryfikacja typu argumentu (i tutaj implementacja PHP jest z dupy bo nie pozwala na typy podstawowe) aby był to prawdziwy obiekt czy też polegać na tym, że programista to jednak nie idiota.

Array owszem, jest zły jeśli sobie lata po aplikacji. Ja mam jednak dylemat na ile mocno rozdzielać odpowiedzialność. Weźmy sobie prosty serwer - ma on obiekt samego serwera, ma obiekt klienta. I teraz zgodnie ze sztuką należy wydzielić jeszcze obiekty request i response - a to już niestety bije w wydajność.

Owszem, kod obiektowy jest czytelniejszy i jestem jak najbardziej za nim, ale jednocześnie widząc w niektórych aplikacjach przekazywanie obiektu np. "status" który spokojnie mógł by być zastąpiony constantem z innej klasy po prostu z lekka ręce mi
  • Odpowiedz
To nie jest kwestia mulenia PHP tylko przygotowania infrastruktury. Dużych serwisów nie uruchamia się na zasadzie "apt-get install php5-apache mysql". MySQL ma klastrowanie, PHP ma wątki i różne mechanizmy offloadingu, istnieje dużo różnych znacznie lepszych serwerów niż apache etc.


@kiler129: W dużych serwisach konfiguracją i optymalizacją serwerów (serwerów nie kodu!) nie zajmuje się programista ;) Czy to jest apache czy nie - nie moja sprawa. Ja dostaję od adminów wytyczne
  • Odpowiedz