konto usunięte

Temat: Za co się teraz zabrać?

Tomasz Zadora:
Łukasz K.:
Nie. To nie jest ad personam. Ja tutaj nie mówię o Tobie

Nie byłoby gdybyś nie użył "Ci" albo "Ty" - bo kierujesz to w tym momencie personalnie do mnie, co innego gdybyś użył zwrotu "osoba" albo "ktoś".

Tia... weź przemyśl co teraz piszesz, bo to śmieszne :) Powtórzę, bo dopisałem w międzyczasie... to co napisałem to nie jest argument w dyskusji, tylko przykład. O przykładach ad personam nie słyszałem. A w przykładach często używa się interlokutora w roli podmiotu, aby wczuł się w sytuację. Ty odwołałeś się do mojej wiedzy insynuując jej brak. EOT3-sprzedane, bo nie ma sensu zbaczać na tematy niezwiązane z meritum.
Tomasz Zadora

Tomasz Zadora programuję

Temat: Za co się teraz zabrać?

Łukasz K.:
nie jest argument w dyskusji, tylko przykład. O przykładach ad personam nie słyszałem. A w przykładach często używa się

Może nie słyszałeś, ale właśnie taki popełniłeś. Tak czy inaczej nadal nie wyjaśniłeś po co w praktycznie każdym jeżyku programowania obiektowego jest możliwość publicznego dostępu do zmiennej. Skoro tego nie potrafisz sensownie wyjaśnić to EOT jest jak najbardziej na miejscu.

konto usunięte

Temat: Za co się teraz zabrać?

Jarek Żeliński:
to nie ma nic wspólnego z programowaniem obiektowym, a gettery/settery są wręcz 'antyobiektowe"....
Dokładnie to samo napisałem parę postów wcześniej :) (a przynajmniej taki miał być w założeniu sens).
w moich oczach powyższe jest niestety wręcz antyporadą...
ale mi chodziło tylko o to, żeby nie było tak, że ktoś będzie wiedział co to są klasy, a nie będzie wiedział co to jest funkcja czy pętla foreach ;)
Dla mnie jeśli ktoś będzie się chciał nauczyć jak programować w PHP to najlepiej żeby zrobił np. tak:
1. jak działają pętle i warunki; do czego są zmienne; wejście ($_GET) i wyjście (echo)
2. co to są funkcje i do czego służą. Unikanie pisania dwa razy tego samego.
3. podział aplikacji na moduły (czyli np. użycie include/require w PHP), wzorzec MVC, zasada hermetyzacji (czyli np. kilka plików *.php, i każdy z nich korzysta z własnych zmiennych, nieruszanych przez inne moduły)
4. próba zrobienia niewielkiego projektu typu księga gości - i dopiero teraz można chyba wprowadzać klasy, bo człowiek przynajmniej widzi, po co one właściwie są - tj. żeby wprowadzić ład i zapisać prosto to, co się i tak będzie emulować na dziwny sposób*.

Jak dla mnie OOP to jest raczej paradygmat. Równie dobrze można robić kod proceduralny oparty na klasach, jak i programować obiektowo bez użycia jakiejkolwiek klasy (ale zachowując takie zasady jak hermetyzacja czy stosując wzorce projektowe).

Tylko, że chyba lepiej się nauczyć narpierw po prostu tworzyć dobrze zaprojektowane, małe aplikacje chociażby na funkcjach, zamiast indoktrynować się paradygmatami obiektowymi, których się nawet nie potrafi zrozumieć, jak się jest nowicjuszem (wiem, bo sam ich nie rozumiałem).

*szczytem emulacji jest np. JavaScript, gdzie nie ma klas, a i tak się da je zrobić za pomocą funkcji ;)Łukasz Lityński edytował(a) ten post dnia 18.03.12 o godzinie 20:30
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Za co się teraz zabrać?

Tomasz Zadora:
Jarek Żeliński:
obiekt", żadne cechy obiektu nie są publiczne (raczej nie praktykujemy tauowania sobie danych osobowych na czole by każdy sam mógł sobie je "pobrać"). Ale to temat na inny wątek,

Z tym absolutnym brakiem używania zmiennych publicznych to też przesada - mam każdą zmienną obiektu lub jakąś mapę zmiennych pobierać przez metodę obiektu, nigdy bezpośrednio?

a po co? Pobierając dane bezpośrednio nie kontrolujesz tego pobierania, owszem sa wyjątki aleto WYJĄTKI
Po za tym jak już piszemy o przykładach praktycznych - wiele obiektów istnieje w przestrzeni publicznej i czy nam się to podoba czy nie to każdy może zmieniać ich właściwości (zmienne). W związku z tym w naturalny sposób zmienne te są publiczne.

publiczne są nie zmienne a operacje, mało jest obiektów niepilnowanych i nie obsługiwanych... no np. pomniki...
Np. jeżeli stworzylibyśmy obiekt "atmosfera" to zmienna "zawartość CO2" jest jak najbardziej publiczna i nikt się nie musi pytać/prosić atmosfery o zmianę tej zmiennej :)

musisz mieć urządzenie do pomiaru....

konto usunięte

Temat: Za co się teraz zabrać?

Tomasz Zadora:
Łukasz K.:
nie jest argument w dyskusji, tylko przykład. O przykładach ad personam nie słyszałem. A w przykładach często używa się

Może nie słyszałeś, ale właśnie taki popełniłeś. Tak czy inaczej nadal nie wyjaśniłeś po co w praktycznie każdym jeżyku programowania obiektowego jest możliwość publicznego dostępu do zmiennej. Skoro tego nie potrafisz sensownie wyjaśnić to EOT jest jak najbardziej na miejscu.


Co to jest "język programowania obiektowego"?, bo OOP to paradygmat. Nie ma to nic wspólnego z językiem, który może w większym, lub mniejszym stopniu wspierać OOP. To, że w takim Pythonie*** wszystko jest obiektem, nie oznacza, że każdy program będzie napisany zgodnie z zasadami OOP. Tak samo nie trzeba wcale pisać w Javie zgodnie z tym paradygmatem, ale owszem - po to została stworzona. Tylko gdy była tworzona, nie było tak mocnych tendencji, a z czasem okazało się, że używanie publicznych atrybutów jest wysoce zwodnicze - dokładniej wtedy, gdy przekonano się powszechnie i w praktyce do wyższości abstrakcji nad implementacją.

Każdy, kto musiał choć raz zmienić implementację klasy* o tym wie. Każdy, kto chciał realnie wykorzystać polimorfizm o tym wie. W końcu każdy, kto pisał dowolne API o tym powinien wiedzieć. Czemu mam udowadniać, że 2 + 2 jest 4?

----
* Klasy, nie struktury. Nie POJO, którego zadaniem jest wziąć dane i wypluć dane. Ale nawet tu, ze względu na ułomność Javy, akcesory są wskazane. W innych językach - jak pisałem** - niekoniecznie! Tu nie chodzi o psychopatyczne dodawanie metod do klasy, tylko zapewnienie możliwości przyszłej (spodziewanej lub nie) zmiany imlementacji sposobu dostępu do danych czy wykonywanych operacji.

** Przeczytać dokładnie i na głos! ;) Bo nie chcę już powtarzać. Poza tym w język może być wsadzone pierdyliard rzeczy, co nie oznacza, że zgodnie z dobrymi lub jakimiś innymi nawykami należy je tykać ;)

*** Przykładem jest moduł imaplib, który de facto zwraca nieobrobione struktury, nie ma ładnych (żadnych w sumie sensownych) klas. Gdy zapytałem o obiektową bibliotekę do IMAP-a, to spotkałem święte oburzenie - "jak to?! przecie wszystko w Pythonie jest obiektowe! jesteśmy zaje*iście obiektowi!". Bull shit. Konstrukcja języka, składnia, możliwości i implementacja nie mają wcale przełożenia ani nie determinują tego jak napisany będzie program czy biblioteka.Łukasz K. edytował(a) ten post dnia 18.03.12 o godzinie 22:01
Tomasz Zadora

Tomasz Zadora programuję

Temat: Za co się teraz zabrać?

Jarek Żeliński:
a po co? Pobierając dane bezpośrednio nie kontrolujesz tego pobierania, owszem sa wyjątki aleto WYJĄTKI

Pytanie czy zawsze ta kontrola jest potrzebna? Nie zawsze. Wolę zrobić wszystkie lub większość właściwości klasy jako publiczne - dla wygody, a jeżeli zajdzie taka potrzeba dopiero je ukrywać.

Wyobraź sobie metodę która dokonuje szeregu obliczeń i ustawia kilkadziesiąt właściwości klasy, teraz chciałbym te właściwości odczytać - mam się męczyć z wieloma metodami? Mam tworzyć osobną metodę która zwróci te dane w jakimś formacie - np. XML? To jest po prostu niepraktyczne i niewydajne.

Oczywiście z drugiej strony, jeżeli już ukryję wcześniej publiczną właściwości to jest problem z tymi wszystkimi miejscami gdzie jest ona odczytywana bezpośrednio i trzeba robić refaktoryzację.

Generalnie zgodzę się, że dla każdej właściwości powinna być osobna metoda do zapisu/odczytu i można tą czynność w pewnym stopniu zautomatyzować, jednak nadal z punktu widzenia szybkości tworzenia oprogramowania jest to proces który go spowalnia.
publiczne są nie zmienne a operacje, mało jest obiektów niepilnowanych i nie obsługiwanych...
no np. pomniki...

Przyznaje, że zaczyna mnie to przekonywać - np. jeżeli istnieje publiczna tablica ogłoszeń, gdzie każdy może sobie przykleić ogłoszenie to w sumie właściwość "ile jest ogłoszeń na tablicy" nie powinna być publiczna a jedynie metoda "przyklej ogłoszenie" albo "zerwij ogłoszenie (konkurencji)". Natomiast odczytanie ile jest tych ogłoszeń to już powinna być sprawa obiektu klasy "tablica ogłoszeń"...

konto usunięte

Temat: Za co się teraz zabrać?

Tomasz Zadora:

Generalnie zgodzę się, że dla każdej właściwości powinna być osobna metoda do zapisu/odczytu i można tą czynność w pewnym stopniu zautomatyzować, jednak nadal z punktu widzenia szybkości tworzenia oprogramowania jest to proces który go spowalnia.

Przepraszam, że się wtrącę, ale to jeden skrót klawiszowy, który może zaoszczędzić kłopotliwego refaktoringu w późniejszym etapie. Faktycznie jednak w Javie nie jest to jakoś specjalnie wygodne.
publiczne są nie zmienne a operacje, mało jest obiektów niepilnowanych i nie obsługiwanych...
no np. pomniki...

Przyznaje, że zaczyna mnie to przekonywać - np. jeżeli istnieje publiczna tablica ogłoszeń, gdzie każdy może sobie przykleić ogłoszenie to w sumie właściwość "ile jest ogłoszeń na tablicy" nie powinna być publiczna a jedynie metoda "przyklej ogłoszenie" albo "zerwij ogłoszenie (konkurencji)". Natomiast odczytanie ile jest tych ogłoszeń to już powinna być sprawa obiektu klasy "tablica ogłoszeń"...

Coś Ty? A nie powinno być konduktora, który karteczkę z liczbą przyklei PANI stojącej obok tablicy? Jak to? ;)

EDIT: No i faktycznie powinny być metody jak piszesz. A w przykładzie z koleją nie sądziłem, że rozważasz cokolwiek innego jak dodajObserwatora() obiektu klasy Pasażer, który sobie zapisuje obserwujących w kolekcji, a potem na komunikat iluCieObserwuje() zwraca ich liczbę albo nie (jeśli jest bucem).Łukasz K. edytował(a) ten post dnia 18.03.12 o godzinie 22:41
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Za co się teraz zabrać?

a po co? Pobierając dane bezpośrednio nie kontrolujesz tego pobierania, owszem sa wyjątki aleto WYJĄTKI

Pytanie czy zawsze ta kontrola jest potrzebna?

bo kontrola podstawą zaufania ;), jak będziesz miła kilkadziesiąt klas i coś Ci się wywali będziesz dopiero sprawdzał gdzie?
Nie zawsze. Wolę zrobić wszystkie lub większość właściwości klasy jako publiczne - dla wygody, a jeżeli zajdzie taka potrzeba dopiero je ukrywać.

testując rozwalony system w końcu ukryjesz wszystko... a nie lepiej od razu?

Wyobraź sobie metodę która dokonuje szeregu obliczeń i ustawia kilkadziesiąt właściwości klasy, teraz chciałbym te właściwości odczytać - mam się męczyć z wieloma metodami?

nie, piszesz jedną dobrą operację serializacji całości i wysyłasz jak kto poprosi o całość lub część tych danych, przy okazji kontrolujesz kto pobiera ...

Mam tworzyć osobną metodę która zwróci te dane w jakimś formacie - np. XML? To jest po prostu niepraktyczne i niewydajne.

czyżby, tą metodą jeżeli w stu miejscach systemu będą potrzebne jakieś części lub całość z tych danych napiszesz sto różnych komunikatów pobierających konkretne dane publiczne, jak ukryjesz dane i napiszesz jedną metoda odsyłająca je do sto komunikatów to będzie taki sam komunikat... jak coś zmienić w danych źródłowych nie będzie trzeba orać całego systemu...
Generalnie zgodzę się, że dla każdej właściwości powinna być osobna metoda do zapisu/odczytu i można tą czynność w pewnym stopniu zautomatyzować, jednak nadal z punktu widzenia szybkości tworzenia oprogramowania jest to proces który go spowalnia.

obyć nie zabrną w operacje get/set... w większości przypadków nie ma sensu pobierać parametrów na sztuki, lepiej wysłać od razu komplet...
publiczne są nie zmienne a operacje, mało jest obiektów niepilnowanych i nie obsługiwanych...
no np. pomniki...

Przyznaje, że zaczyna mnie to przekonywać - np. jeżeli istnieje publiczna tablica ogłoszeń, gdzie każdy może sobie przykleić ogłoszenie to w sumie właściwość "ile jest ogłoszeń na tablicy" nie powinna być publiczna a jedynie metoda "przyklej ogłoszenie" albo "zerwij ogłoszenie (konkurencji)". Natomiast odczytanie ile jest tych ogłoszeń to już powinna być sprawa obiektu klasy "tablica ogłoszeń"...

... wzorzec publish/subscribe... tablica ma operację przyklej, karteczka to także obiekt, reszta "czycha" na swoje...
Tomasz Zadora

Tomasz Zadora programuję

Temat: Za co się teraz zabrać?

Łukasz K.:
EDIT: No i faktycznie powinny być metody jak piszesz. A w przykładzie z koleją nie sądziłem, że rozważasz cokolwiek innego jak dodajObserwatora() obiektu klasy Pasażer, który sobie zapisuje obserwujących w kolekcji, a potem na komunikat iluCieObserwuje() zwraca ich liczbę albo nie (jeśli jest bucem).

Szkopuł tkwi w tym, że pasażer nie zawsze może zdawać sobie sprawę z tego, że ktoś go obserwuje.

Można zastanawiać się w jakim kontekście użyć metody dodajObserwatora() - czy powinna być wywoływana na obiekcie który jest obserwowany czy na obiekcie który jest obserwatorem. Ewentualnie tak jak sugerowałem - bez metod tylko na zasadzie ++/-- na zmiennej "liczbaObserwatorow".

Jeżeli nie przewidujemy żadnych dodatkowych operacji związanych ze zwiększaniem/zmniejszaniem obserwatorów, prościej i szybciej jest zrobić to przez zmienną publiczną.

W każdym razie dziękuję Jarkowi i Łukaszowi za dyskusję, ja na razie nie mam nic do dodania.Tomasz Zadora edytował(a) ten post dnia 18.03.12 o godzinie 23:38

konto usunięte

Temat: Za co się teraz zabrać?

Istnienie akcesorów wg mnie w dużej mierze zależy od konkretnej sytuacji/roli obiektu jaką ma pełnić w systemie - a ta często określa i/lub jest określana przez interfejs.

Są sytuacje gdzie robienie prywatnych/chronionych parametrów wraz z metodami dostepowymi będzie tylko oznaką bezmyślnego trzymania się fajnych słów jak "enkapsulacha" czy "hermetyzacja" bez żadnego projektowego/architektonicznego uzasadnienia.

Dyskutować o akcesorach można w nieskończoność i do żadnego sensownego wniosku nie dojdziecie/dojdziemy, bez znaczenia o jakim języku jest mowa.

Częściej - tak jak napisałem wyżej - ważniejszy jest interfejs, który ma w d. czy parametry są publiczne czy prywatne. Liczy się zestaw metod, to co się za nimi dzieje jest i powinno być nieistotne z perspektywy projektu/architektury.

Trzymając się kolejowego przykładu - nie ważne czy ktoś ma wytatuowaną ilość obserwujących na czole, czy jest skryty i trzeba go pytać.
Każdy z elementów w przedziale - pieski, plecaki, osoby musi implementować TransportableInterface::owner(), zaś osoby dodatkowo muszą implementować PassengerInterface::getTicket().
W efekcie Transportable->owner()->getTicket();

Zaś sama ilość obserwujących powinna być tak:


function checkObservers(TransportableInterface $Transportable) {
if(isset($Transportable->observing)) {
return (int) $Transportable->observing; // skoro widzę na czole, to po co pytam?
}

if(is_callable($Transportable, 'getObservers')) { // sprawdzam czy mogę zapytać, może jest w czyimś bagażu
return $Transportable->getObservers(); // pytam
}

// TODO - próbuj ocenić sam i zwróć wartość

return null; // zwróć null bo nie masz pojęcia
}


funkcja zwraca kolekcję obiektów TransportableInterface (tak na wypadek gdyby prócz pasażerów obserwował mnie pies pani z naprzeciwka i bagaż z półki) lub null w przypadku gdy jesteśmy w tunelu.

[Edit]
Jak widać - implementacja interfejsów całkowicie uwalnia od problemu publiczne/prywatne, gdzie przez interfejs należy rozumieć ustalony zestaw metod, niezależnie czy jest poprzedzony słowem "interface" czy spisany na kartce i wymuszany przez kierownika projektu. Interfejs to interfejs.

[Edit2]
Wg mnie - obserwatora powinno się dodawać do elementów implementujących Obserwowalny::dodajObserwatora(); Jej implementacja określa czy obiekt może być obserwowany czy nie (np. powietrze w przedziale nie implementuje tego, a pieniądze w kieszeni, choć implementują nie informują o zdarzeniach - bo są w kieszeni i ich nie widać).Michał Wachowski edytował(a) ten post dnia 19.03.12 o godzinie 00:08

konto usunięte

Temat: Za co się teraz zabrać?

Tomasz Zadora:
Łukasz K.:
EDIT: No i faktycznie powinny być metody jak piszesz. A w przykładzie z koleją nie sądziłem, że rozważasz cokolwiek innego jak dodajObserwatora() obiektu klasy Pasażer, który sobie zapisuje obserwujących w kolekcji, a potem na komunikat iluCieObserwuje() zwraca ich liczbę albo nie (jeśli jest bucem).

Szkopuł tkwi w tym, że pasażer nie zawsze może zdawać sobie sprawę z tego, że ktoś go obserwuje.

Można zastanawiać się w jakim kontekście użyć metody dodajObserwatora() - czy powinna być wywoływana na obiekcie który jest obserwowany czy na obiekcie który jest obserwatorem. Ewentualnie tak jak sugerowałem - bez metod tylko na zasadzie ++/-- na zmiennej "liczbaObserwatorow".

Jeżeli nie przewidujemy żadnych dodatkowych operacji związanych ze zwiększaniem/zmniejszaniem obserwatorów, prościej i szybciej jest zrobić to przez zmienną publiczną.

W każdym razie dziękuję Jarkowi i Łukaszowi za dyskusję, ja na razie nie mam nic do dodania.

Sorry, jeśli uznałeś, że odnoszę się do Ciebie personalnie - nie miałem takiego zamiaru ;)

A jeśli pasażer ma nie mieć pojęcia, to robimy klasę Szpieg z metodą dodajFiguranta() ;) ale wtedy ciężko o podliczenie obserwujących przez Pasażera. Może to zrobić ABW, która przekaże tę wartość Pasażerowi - albo przyklei mu kartkę na plecach z numerkiem (atrybut publiczny), albo wywoła metodę hejSzpiegujeCieXOsob(int liczba). Przy pierwszym podejściu Pasażer ma szansę zareagować tylko, jesli coś cyklicznie wywołuje mu metodę paranoicznieSprawdzajPlecy(). Tu już nieważne, czy publiczną czy prywatną.
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Za co się teraz zabrać?

Są sytuacje gdzie robienie prywatnych/chronionych parametrów wraz z metodami dostepowymi będzie tylko oznaką bezmyślnego trzymania się fajnych słów jak "enkapsulacha" czy "hermetyzacja" bez żadnego projektowego/architektonicznego uzasadnienia.
Częściej - tak jak napisałem wyżej - ważniejszy jest interfejs, który ma w d. czy parametry są publiczne czy prywatne. Liczy się zestaw metod, to co się za nimi dzieje jest i powinno być nieistotne z perspektywy projektu/architektury.

Ogólnie właśnie tak, i dodam: po grzyba walka z get/set i publicznymi atrybutami? Bo poza istniejącymi wyjątkami gdy ma to sens (jakieś przykłady???), to wymiana komponentu na nowy z zupełnie nową implementacją, do którego "reszta świata" zna tylko interfejs jest "łatwa", wymiana komponentu, gdzie "cały świat" się odwoływał do jego atrybutów jest w zasadzie przepisaniem na nowo całego systemu...

a życie uczy, ze pewne są podatki, śmierć ... i zmiana wymagań...
Jak widać - implementacja interfejsów całkowicie uwalnia od problemu publiczne/prywatne, gdzie przez interfejs należy rozumieć ustalony zestaw metod, niezależnie czy jest poprzedzony słowem "interface" czy spisany na kartce i wymuszany przez kierownika projektu. Interfejs to interfejs.

amen :)
Jacek R.

Jacek R. programista

Temat: Za co się teraz zabrać?

Dyskutować o akcesorach można w nieskończoność i do żadnego sensownego wniosku nie dojdziecie/dojdziemy, bez znaczenia o jakim języku jest mowa.

Nieprawda. Polecałem wcześniej C#, a jedną z jego niezaprzeczalnych zalet jest... całkowite pozbycie się problemów związanych z hermetyzacją/enkapsulacją oraz getterami/setterami, ponieważ sposób dostępu do atrybutów obiektu (tzw. properties) może być przez programistę nadpisywany. I to przy całkowitym zachowaniu interfejsu pobierania zmiennej bezpośrednio, nie przez metodę. Dlatego wskazane jest odnosić się do niej w ten sposób, a kiedy zajdzie potrzeba, można do niej dopisać gettera/settera, który będzie automatycznie wywoływany podczas pobierania/zapisywania danych. W PHP można sobie troszkę takie rozwiązanie zapewnić dzięki magicznym metodom, ale jednak ciężko się to implementuje, bo koniec końców, obsługuje się wtedy niekończącego się switcha ;)
Częściej - tak jak napisałem wyżej - ważniejszy jest interfejs, który ma w d. czy parametry są publiczne czy prywatne. Liczy się zestaw metod, to co się za nimi dzieje jest i powinno być nieistotne z perspektywy projektu/architektury.
Dodatkowo, w C# propertiesy mogą być dodawane do interfejsów, wraz z określeniem typu dostępu, co jest kompleksowym rozwiązaniem wszelakich problemów związanych z dostępem do pól.

Polecam lekturę http://msdn.microsoft.com/en-us/library/x9fsa0sw(v=vs.... . Nie wszystko zło, co Microsoft :) Zostało to zaczerpnięte z Delphi, oraz wyśmiane przez społeczność Javową (Javowcy uwielbiają swoje gettery i settery :)).Jacek Romanowski edytował(a) ten post dnia 19.03.12 o godzinie 17:58
Tomasz Zadora

Tomasz Zadora programuję

Temat: Za co się teraz zabrać?

Jacek Romanowski:
koniec końców, obsługuje się wtedy niekończącego się switcha ;)

Nie trzeba się tak męczyć - to w końcu język dynamiczny więc nazwę zmiennej można np. zamienić dynamicznie na nazwę jakiejś metody i ją wywołać. Praktycznie jedna linijka w magicznej metodzie - pomijając ewentualny blok try/catch lub sprawdzenie czy metoda istnieje.Tomasz Zadora edytował(a) ten post dnia 19.03.12 o godzinie 18:08

konto usunięte

Temat: Za co się teraz zabrać?

Jacek Romanowski:
Dyskutować o akcesorach można w nieskończoność i do żadnego sensownego wniosku nie dojdziecie/dojdziemy, bez znaczenia o jakim języku jest mowa.

Nieprawda. Polecałem wcześniej C#, a jedną z jego niezaprzeczalnych zalet jest... całkowite pozbycie się problemów związanych z hermetyzacją/enkapsulacją oraz getterami/setterami, ponieważ sposób dostępu do atrybutów obiektu (tzw. properties) może być przez programistę nadpisywany. I to przy całkowitym zachowaniu interfejsu pobierania zmiennej bezpośrednio, nie przez metodę. Dlatego wskazane jest odnosić się do niej w ten sposób, a kiedy zajdzie potrzeba, można do niej dopisać gettera/settera, który będzie automatycznie wywoływany podczas pobierania/zapisywania danych. W PHP można sobie troszkę takie rozwiązanie zapewnić dzięki magicznym metodom, ale jednak ciężko się to implementuje, bo koniec końców, obsługuje się wtedy niekończącego się switcha ;)

kłania się znajomość programowania obiektowego

http://c2.com/cgi/wiki?SwitchStatementsSmell

konto usunięte

Temat: Za co się teraz zabrać?

Tomasz Zadora:
Jacek Romanowski:
koniec końców, obsługuje się wtedy niekończącego się switcha ;)

Nie trzeba się tak męczyć - to w końcu język dynamiczny więc nazwę zmiennej można np. zamienić dynamicznie na nazwę jakiejś metody i ją wywołać. Praktycznie jedna linijka w magicznej metodzie - pomijając ewentualny blok try/catch lub sprawdzenie czy metoda istnieje.

dokładnie

switch =(refactoring)=> algorithm =(refactoring extracting / OO)=> OO algorithm pattern

itd ...
Jacek R.

Jacek R. programista

Temat: Za co się teraz zabrać?

Nieważne jaką strukturę językową czy wzorzec projektowy się zastosuje, zawsze będzie to zbędne kodowanie, które nie będzie specjalnie czytelne. Celowo użyłem switcha w przykładzie, żeby zaznaczyć fakt, że nie jest to wszystko zbyt fortunne ani proste w napisaniu/utrzymaniu/rozszerzaniu.

konto usunięte

Temat: Za co się teraz zabrać?

Jacek Romanowski:
Nieważne jaką strukturę językową czy wzorzec projektowy się zastosuje, zawsze będzie to zbędne kodowanie, które nie będzie specjalnie czytelne. Celowo użyłem switcha w przykładzie, żeby zaznaczyć fakt, że nie jest to wszystko zbyt fortunne ani proste w napisaniu/utrzymaniu/rozszerzaniu.

zbyt generalizujesz, podobnie jak pozostali, są zastosowania gdy narzędzia takie jak magiczne metody sa potrzebne i ekonomiczne

i dysputa na ten temat to oddzielny wątek

namieszaliście juniorowi w głowie rozterkami senioraTomasz Grzechowski edytował(a) ten post dnia 20.03.12 o godzinie 11:08
Wojciech Soczyński

Wojciech Soczyński Programista
eksplorator -
blog.wsoczynski.pl

Temat: Za co się teraz zabrać?

Tomasz Grzechowski:
Jacek Romanowski:
Nieważne jaką strukturę językową czy wzorzec projektowy się zastosuje, zawsze będzie to zbędne kodowanie, które nie będzie specjalnie czytelne. Celowo użyłem switcha w przykładzie, żeby zaznaczyć fakt, że nie jest to wszystko zbyt fortunne ani proste w napisaniu/utrzymaniu/rozszerzaniu.

zbyt generalizujesz, podobnie jak pozostali, są zastosowania gdy narzędzia takie jak superglobalne sa potrzebne i ekonomiczne

i dysputa na ten temat to oddzielny wątek

namieszaliście juniorowi w głowie rozterkami seniora
Co do oddzielnego wątku, właśnie wrzuciłem na swojego bloga post w tematyce aktualnej dyskusji (akcesory etc). Także gdybyście chcieli się dalej kłócić (i nabić mi trochę wejść :P :P :P) to zapraszam :P -> http://blog.wsoczynski.pl/2012/03/19/the-context/

Następna dyskusja:

Jak się teraz pisze w PHP




Wyślij zaproszenie do