somekind
2019-07-09 17:19

Przynajmniej wreszcie wiadomo dla kogo jest to całe DDD: https://www.smyk.com/catalog/[...]onym-systemem-informatycznym/

WeiXiao

Dzieci najlepiej chłoną religię, więc trzeba przyznać, że know your market można zacheckować ;)

kzkzg

Ta książka jest idealna na bezsenność.

cerrato

Boję się tego, jaką odpowiedź mogę uzyskać, ale jednak zapytam ;) Powiedz proszę - w jaki sposób na to trafiłeś?

szarotka

Może dzidziuś w drodze? eh to by był news!

cerrato

Podobno muzyka, jakiej słucha matka w ciąży ma wpływ na rozwój oraz zachowanie płodu. Ciekawe, jak taki dzieciak zareaguje, gdy mu tatuś będzie czytał o DDD codziennie przez godzinę :D

PerlMonk

Wszyscy wiedzą, że naukę programowania należy zacząć już w jako płód, więc książka dla dziecka dobra rzecz.

Hispano-Suiza

Wszyscy wiedzą, że naukę programowania należy zacząć już w jako płód, więc książka dla dziecka dobra rzecz.

Ale zeby od razu faszystowskich ideologii?

Davros

@Hispano-Suiza: lepsze to niż ideologia lgbtqia(.....xyz)+

PerlMonk

@Hispano-Suiza: <sarkazm>Demoralizować młodzież można w każdym wieku</sarkazm>

LukeJL

DDD nie jest takie złe, jak się spojrzy z dystansem na to i próbując dostosować to podejście do konkretnych problemów. Problem w tym, że często staje się jakimś dogmatem, a DDD zamiast być filozofią wytwarzania oprogramowania (czyli tym, w czym zamierzeniu miało to być chyba), to staje się po prostu zestawem wzorców do szybkiego wrzucenia, żeby kod wyglądał bardziej profesjonalnie. Ludzie po prostu wrzucają to na siłę, bo są beginnerami i chcą, żeby ktoś im powiedział "jak mają programować" zamiast myśleć samodzielnie. Czyli DDD to trochę jak wzorce projektowe bandy czworga czy cokolwiek innego, czego ludzie używają zamiast mózgu.

cerrato

@LukeJL: słuszna uwaga. Tak samo jak wszelkie inne wzorce projektowe - mają one sens tam, gdzie mają. Ale wiele osób chce na sile zastosować w każdym projekcie przynajmniej 2-3, chociaż z niczego (poza tym, że jak się człowiek uprze, to da radę) to nie wynika, a takie pchanie na siłę może nieraz spowodować więcej problemów i zamieszania, niż jakby sobie ktoś odpuścił. Podobnie początkujące osoby od frontu - walą pełno efektów, animacji i innych ozdóbek, żeby pokazać, że umią ;)

LukeJL

@cerrato bo w nauce czegokolwiek trzeba wiele poświęcić czasu na próby i odkrywanie. Przeinżynierowanie albo wrzucanie efektów na oślep nie jest złe, jak się to robi w ramach nauki. Gorzej jak to idzie na produkcję. Gorzej też jeśli ktoś nie ma zdolności autorefleksji, samodzielnego myslenia (np.nie rozumiem ludzi, którzy czytają o jakimś wzorcu/technice a potem zamiast próbować samemu to ogarnąć, to pytają na forum typu "czy mogę użyć tego wzorca w taki sposób? Czy to będzie poprawne?". Tak jakby bali się że popełnią błąd (a to trochę jakby ktoś się uczył rysować i pytał "czy jak rysuję człowieka, to mam spędzić 5 minut czy pół godziny nad twarzą? A czy nogi powinny być pod kątem 80% czy 85% stopni w stosunku do podłogi? itp.). Kurczę, samodzielności trochę...

LukeJL

@cerrato może też wynika to z tego, że ludziom wydaje się, że programowanie to jakaś nauka w stylu matematyki, gdzie jest jedna prawidłowa odpowiedź - podczas gdy w rzeczywistości jest to raczej rzemiosło czy sztuka, gdzie niby też jest potrzebna teoria, ale koniec końców i tak trzeba to sobie samemu ogarnąć.

danek

@LukeJL: mam wrażenie, że ludzie boją się tego, że ktoś ich oskarży o to, że robią coś niezgodnie z "dobrymi praktykami". Bardziej wolą usłyszeć, że robią dobrze niż, robić dobrze :P

TomRZ

DDD to nie jest system gdzie mechanicznie powtarza się wzorzec, to system gdzie trzeba wykazać się przede wszystkim prawidłową analizą problemu, a nastepnie podzielić ten problem na odpowiednie składowe wg. DDD. To nie jest proste, trzeba się wykazać pewną inicjatywą i kreatywnością. O ile Encje będą podobne w każdym projekcie, to już np. usługi, fabryki i agregaty będą wyglądać dość indywidualnie dla każdego projektu. Osobiście z DDD nie używam jedynie repozytoriów w dokładym sensie w jakim proponuje DDD, bo to się trochę zgryza z CRUDem, ale poza tym to dobry system, ale żeby go docenić trzeba zrobić sporo projektów.

PerlMonk

@danek: No, M$ nie pyta czy robi winshit dobrze tylko robi...

leggo

Ja widzę trochę inną wartość z DDD czy wzorców. Pomagają zapanować nad kodem w sposób, który na pierwszą myśl nie przychodzi do głowy. Zamiast wynajdywać koło od nowa, masz do dyspozycji arsenał przetestowanych nomen-omen "wzorców", które mogą ułatwić implementację jakiegoś rozwiązania.... ale sam problem istnienia wzorców, to nie, że one są, czy są nadużywane, tylko, że nie są rozumiane w pełni i wrzucane na pałę tam, gdzie nie są potrzebne. Wystarczy zobaczyć jaka już jest tendencja wśród filmów na youtubie. dlaczego IoC to zło, dlaczego dziedziczenie to zło, dlaczego wszystko zło....
Uważam, że to własnie dlatego, że nie rozumiemy w pełni tego czego stusujemy.
Jak uporczywe wydzielanie kolejnej warstwy abstrakcji w kodzie, bo być może ktoś kiedyś zmieni jej implementację, co tak na prawdę nie następuje nigdy. :D

TomRZ

Chciałbym zobaczyć na YT kogoś kto twierdzi, że dziedziczenie w klasach to "zło", to musi być niezły kabaret.

danek

Problem z wzorcami jest, mam wrażenie taki, że ludziom bardzo mocno wbiło się do głowy wzorzec -> dobra praktyka i użycie wzorca stało się wartością samą w sobie, zamiast rozwiązywać faktyczny problem

LukeJL

@PerlMonk - M$ to nie wiem, ale Apple też nie pyta użytkowników i dobrze na tym wychodzi. Ludzie dalej kupują.

LukeJL

@PerlMonk chociaż to już trochę inna kwestia, bo dotyczy to interfejsu/designu a nie tego, co jest w kodzie.

scibi92

@TomRZ: dlaczego? Generalnie kompozycja >>>> dziedziczenie, choć bywają wyjatki. Ale kompozycja w 99% przypadków lepsza

PerlMonk

@LukeJL: Apple robi taki system, żeby ludzie sami z siebie chcieli z niego korzystać. Jeśli już ktoś przyzwyczai się do MacOS, to nie spotyka go zaskoczenie jak np. w Windows 8.

TomRZ

Faktycznie, kompozycja może być lepsza od dziedziczenia wtedy kiedy zakładamy możliwość częstych zmian gdzieś w łańcuchu klas. Natomiast kiedy mamy dość dojrzałą strukturę, która będzie się zmieniać rzadko lub w ogóle, to IMO dziedziczenie jest lepsze. Kolejna sprawa której mi brakuje w artykułach typu "composition vs inheritance", to procedury testowe, które powinny wykrywać problemy po zaawansowanych zmianach w łańcuchu klas.

scibi92

"Natomiast kiedy mamy dość dojrzałą strukturę, która będzie się zmieniać rzadko lub w ogóle, to IMO dziedziczenie jest lepsze." Niby dlaczego? Jaka tu jest przewaga dziedziczenia? Bo ja widze wady w postaci 1)Silnego związania 2)Złamania enkapsulacji 3)Dużej liczby zależności

somekind

Bo w starym kodzie jest więcej dziedziczenia, a stary kod jest dobry, nie to co ten nowy millanialsowy. ;)

somedev

mamy dość dojrzałą strukturę, która będzie się zmieniać rzadko lub w ogóle, to IMO dziedziczenie jest lepsze - a kiedy stwierdziłeś, że ta struktura będzie kiedyś dojrzała i niezmienna? Generalnie przez zakładanie pewnych aksjomatów potem powstają haki w kodzie bo jest za mało elastyczny. Zmiana warstw dziedziczenia z reguły jest bardziej problematyczna niż wymiana implementacji np. składowej danego interfejsu.

TomRZ

Słuchajcie, jest coś takiego w Javie jak Final prawda? Są struktury które są bardzo niezmienne - np. pierwiastki chemiczne, modele samochodów. No, chyba, że ktoś uważa, że np. Honda Civic z przed 10 lat, nagle będzie miała zmienioną specyfikację. Jaka jest przewaga dziedziczenia - np. mniejsza ilość kodu, większa oszczędność pamięci, pewnie znalazłbym więcej, ale wybaczcie, jestem w pracy.

somekind

final class HondaCivic - no nawet ma sens.

ccwrc

@TomRZ Znając userów Civica to zmiana specyfikacji zwie się tuning ;)

TomRZ

Przyznaje Wam na ten moment rację bo po prostu nie mam czasu dyskutować, i wyrzucać z głowy tego nad czym teraz pracuję. Pozdrawiam.

danek

A dziedziczysz po to zeby mieć wspólne pola czy po to, żeby dodawać nowe funkcje?

PerlMonk

@TomRZ: Nie denerwuj się, misiu pysiu.

somedev

@TomRZ: ale 4p nie obliguje do natychmiastowego odpisywania ;) Mi się wydaje, że HondaCivic to kiepska klasa. To tak jakby zrobił klasę JanKowalski, a powinno to być moim zdaniem klasa Obywatel dziedzicząca po ew. Człowieku z atrybutem imię i nazwisko. Dlaczego to nie może być klasa samochód dziedzicząca po pojeździe z polem interfejsu silnikAuta i atrybucie (nawet enumem) marka?

viader

przez dziedziczenie klas powstają największe potworki

danek

@somedev: najgorsze jest utożsamianie obiektów z faktycznymi rzeczami z rzeczywistości, bo to powoduje powstawanie potem struktur danych z metodami zamiast obiektów

somekind

Przecież każdy wie, że jedyne prawidłowe nazwy klas to: Merkury, Wenus, Mars i tak dalej: https://4programmers.net/Foru[...]netary_motion_visualiser_2012

somedev

A co zlego jest w klasie TcpSender lub CollectionObserver ? To są rzeczywiste byty które coś robią. To, kolega w dyskusji zaczął proponować klasy bazujące na samochodach ;)

danek

@somedev: Co innego TcpSender bo to juz jest jakaś odpowiedzialność, co innego Car gdzie tego nie ma

leggo

no jest różnica między POCO, DTO, Model a między Rich Model, Aggregatami i Handlerami.... a najlepsze i tak to są te z końcówką Utils, Manager oraz Helper

danek

no właśnie, POCO to wszystko

TomRZ

Klasa FormField i potem dziedziczenie typu FieldTextArea, FieldUploadImage, FieldSelectOption, to przychodzi mi do głowy na szybko, jeżeli chodzi o zasadność dziedziczenia.

TomRZ

@PerlMonk: nie spoufalaj się za bardzo

Hispano-Suiza

Na szczescie moj stack nie obsluguje dziedziczenia. Nie ma dziedziczenia - nie ma problemu.

nullpt4

@Hispano-Suiza: nie możliwe! tak się nie da! xD

viader

@TomRZ: z dziedziczeniem klas jest ten problem, że po chwili zaczyna klasa bazowa wyglądać jak syf, bo jakieś 4 klasy potrzebują czegoś, a inne 5 klas czegoś innego i puchnie całość. W interfejsach nie ma raczej tego problemu, bo można rozbić każdy duży interfejs na kilka małych. w każdym razie kompozycja > dziedziczenie

TomRZ

@viader: u mnie tak nie jest, ale to może dlatego, że pisanie kodu to umnie jakieś 5-10% czasu pracy, reszta to analiza. Efekt jest taki, że popełniam bardzo mało błędów, i bardzo mało muszę poprawiać. Natomiast w środowisku AGILE i innych gili, to faktycznie, może lepiej nie stosować dziedziczenia.

TomRZ

Generalnie zrobiłem w życiu ponad 100 projektów webowych, w tym kilka średnich i jeden naprawdę duży nad którym teraz pracuję, i nigdy nie miałem problemów z dziedziczeniem, przerostem klas bazowych, problemami związanymi ze zmianami w klasach w całym łańcuchu dziedzienia etc. Może po prostu ktoś tutaj nie umie korzystać z dziedziczenia? Myślę, że to kończy dyskusję, przynajmniej dla mnie. Bardziej poważnie mogę podyskutować jeżeli ktoś założy osobny wątek na ten temat już na forum.

Hispano-Suiza

Tylko 100? Podbijam. Zieloni 300.

viader

Też nie mam kłopotu z dziedziczeniem, jak mogę wolę nie używać :D

TomRZ

@Hispano-Suiza: a ile zapłacisz, jeżeli Ci to udowodnię? Możemy spisać umowę notarialną :) Pierwsze projekty robiłem pod koniec lat 90-tych dla takich firm jak wydawnictwo Pascal albo Optimus-Pascal Multimedia. To co idziemy do prawnika? Jeżeli nie to przestań pajacować.

nullpt4

@TomRZ: raczej chodziło o to, że argument ilościowy nie jest dobrym argumentem, przynajmniej w tym przypadku xd

somekind

No właśnie, czemu? Przecież wybitny niemiecki inżynier Karl Marx powiedział, że "ilość przechodzi w jakość". ;)

scibi92

@TomRZ: założę ale pewnie nie dziś. Login zapamiętany :)

nullpt4

@TomRZ: ja pracowałem w 300 projektach w tym 10 średnich i 2 dużych i zawsze się okazywało, że projekty które się rozrosły i w których było dziedziczenie miały więcej bugów, ciężej się je utrzymywało oraz trudniej było dodawać nowe funkcjonalności, niż w projektach gdzie dominowała kompozycja ... przerzucanie się tym, kto i ile projektów zrobił używając mechanizmu A czy B do nikąd nie prowadzi xd

scibi92

W sumie własnie ogarnąłem że ja robie dziedziczenie codziennie prawie... codziennie dziedziczę klase Object :D

danek

łe, forum dyskryminuje Wałęsizm :<

TomRZ

aha jeszcze mała uwaga - to, że bronię dziedziczenia, nie znaczy, że używam tego zawsze i wszędzie, żeby było jasne, każda rzecz powinna być używana zgodnie z jej przeznaczeniem / optymalnie. Taka to bezsensowna dyskusja, bez przykładów etc. Zróbcie normalny wątek na forum to pogadamy.

axelbest

Ja tam popieram @TomRZ +1. Dziedziczenia używa się tam gdzie jest potrzebne, tak samo jak i kompozycji, wzorców, ddd, tdd, bdd I innych dd :) nie wiem po co te kłótnie. No chyba ze ktoś jasno stwierdzi że "z dziedziczenia nie wolno korzystać, bo...." wtedy też z chęcią bym zobaczyl taki kabaret naYT o tym złym dziedziczeniu. @scibi92 pisałeś że w 99% kompozycja lepsza, OK, ale nawet w takim szacowaniau nadal mamy ten 1% I kto wie może TomRZ akurat zawsze trafia w ten procent. Ale to nadal nie wyklucza możliwości korzystania z dziedziczenia gdzieś indziej. Poza tym... Padł tutaj argument że jak projekt ma dojrzała strukturę... Ale projekt tak samo może być tworzony na szybko i tylko po to by go sprzedać, albo może to jakiś MVP.

"Jeden woli piwo, drugi żyto".

TomRZ

Jeżeli ktoś chce zobaczyć jak robię dziedziczenie, zapraszam looknąć na mój prosty mały projekt. Jest sobie interfejs, następnie jest implementowany przez klasę-adaptera, a z tej klasy-adaptera dziedziczą już konkretne sposoby keszowania. I teraz proszę: niech ktoś to przerobi na kompozycję i udowodni, że kompozycja jest tutaj lepsza. Link: https://github.com/tztztztz/p[...]ree/master/vendor/inopx/cache

scibi92

No cóż to je PHP więc nie będe wstanie tego zrobić xD

Hispano-Suiza

@TomRZ: każesz patrzeć ludziom na PHP. Obawiam się, że to Ty będziesz płacić za przebywanie w szkodliwych warunkach.

axelbest

@scibi92 @Hispano-Suiza jak się nie ma co powiedzieć to trzeba się doye..c do phpa, TomRZ opisał praktycznie funkcjonalność, wydaje mi się ze nawet pseudokodem można by było to opisać.

TomRZ

Ludzie którzy preferują jakiś język programowania, a inne wyśmiewają, to nie są osoby z którymi lubię rozmawiac, więc bardzo dobrze, nie patrz, najlepiej już nic nie pisz.

Hispano-Suiza

@axelbest: Bo Ci zwieracz zaraz puści z tego zdenerwowania, fanatyku jeden z drugim. PHP z jego fanaberiami to nie jest dla mnie żaden wzorzec do naśladowania / przeglądania czy pokazywania, że coś w nim można. To nie jest język do dużych projektów, a przynajmniej nie takie jego przeznaczenie było na początku. I to, że ktoś w tym stawia kij wie jak duże projekty również nie jest wyznacznikiem czegokolwiek.

axelbest

Masz rację :) brawo Ty. To nie jest język do dużych projektów, powiedział gość pisząc na forum pisanym w phpie i pewnie wieczorkiem zajrzy na fejsa....

scibi92

@TomRZ: moim celem nie było wyświewanie PHP tylko po prostu stwierdzenie że nie jestem wstanie zrozumieć tego kodu bo nie znam języka, tak samo byłoby gdyby to był C++, Scala czy Clojure. Nie wiem po co te zbędne nadinterpretacje moich słów

TomRZ

@scibi92: to nie było kierowane do Ciebie, Ty tutaj zachowujesz poziom, pisalem do mr Hispano

scibi92

No tak, ale @axelbest stwierdził że wyśmiewam PHP :(

axelbest

W takim razie przepraszam, za moje zbyt daleko idące przemyślenia/zalozenia :)

Hispano-Suiza

@axelbest: Czyli to forum to duży projekt? Aha. Jak powiesz kobiecie, że masz benka 20cm to dodaj automatycznie, że trzeba to podzielić jeszcze przez dwa. Gdyby nie fakt, że to miejsce publiczne to napisałbym bez gwiazdek ale p****olisz. Widać, że Twoje pojęcie zaczęło się, i zakończyło na php. Powtarzanie,głupot masz chyba wpisane w DNA cholerny ignorancie. Facebook still uses PHP, but it has built a compiler for it so it can be turned into native code on its web servers, thus boosting performance.. I dalej PHP, being a scripting language, is relatively slow when compared to code that runs natively on a server. HipHop converts PHP into C++ code which can then be compiled for better performance. This has allowed Facebook to get much more out of its web servers since Facebook relies heavily on PHP to serve content.
Jesteś kolejnym szczekającym, fanatycznym błaznem, któremu le cerveau est tombe avec la merde du matin, tfu!

viader

@TomRZ nie znam PHP, ale patrzę na AdapterInterfaceCacheMethod i pierwsze to unikałbym w klase abstrakcyjnej nazwy Interface, drugie formatowanie kodu nie wygląda spójnie, trzecia myśl, że raczej nie ma nic na tyle dziwnego by się nie dało zrobić z tego kompozycji.

TomRZ

@Hispano-Suiza: tą optymalizację Facebook wykonał na o wiele starszej wersji PHP, dawno temu. W tej chwili te problemy właściwie nie istnieją, co więcej jest np. Zephyr https://zephir-lang.com/en kiedy ktoś potrzebuje ultra-szybkości. Aha, np. takie Baidu w Chinach też jest oparte o PHP. Naprawdę nie pisz o rzeczach o których niewiele wiesz.

axelbest

@Hispano-Suiza: "cholerny ignorancie" , gadanie o długości penisa, zwieraczach... No piękny poziom dyskusji sobą reprezentujesz. @cerrato czy przetłumaczony tekst Pana Hispano nie podpada pod obrażanie?

TomRZ

@viader: tu już dotykamy trochę stylu programowania i gustów. Ja lubię bardzo czytelny kod, verbose - słowo klucz, ktoś mądry mnie kiedyś nauczył, żeby jak najwięcej pisać komentarzy w kodzie, a nazwy klas oraz zmiennych powinny być samo wyjaśniające się. Dlatego kiedy przeczytasz "AdapterInterfaceCacheMethod" to od razu wiesz, że to klasa-adapter która implementuje taki a nie inny Interfejs, nie trzeba szukać, nie trzeba pamiętać. Natomiast ten projekcik to nie jest coś nad czym długo siedziałem, i dopieszczałem - to jest w końcu darmowe, więc nie ma tam tak wielu np. komentarzy jak robię normalnie w kodzie komercyjnym, formatowanie też nie jest idealne.

nullpt4

formatowanie też nie jest idealne. jak coś to są przecież autoformatery :)

TomRZ

@nullpt4: to rób forka i formatuj ;)))

PerlMonk

Zatrzymajcie tę karuzelę śmiechu!

Hispano-Suiza

@TomRZ: Baidu w Chinach też jest oparte o PHP. Naprawdę nie pisz o rzeczach o których niewiele wiesz. - There is a whole host of services offered by Baidu search engine, and they have used different programming languages to develop them to the perfection. But if one programming language has to be chosen which has been most used, it has to be C++. Even Google mentions C++ as its one of the main languages though it has made a shift to Python for most parts now to go along the modern trend. Even though Baidu has used Python is some parts, but C++ is used more overwhelmingly.
Wstawaj! Z***ałeś się! https://github.com/baidu + na pewno ich zaawansowane AI stoi na PHP.

leggo

Chyba zaraz będzie mi głupio, że poruszyłem ten temat :D

somedev

@Hispano-Suiza: gość podał Tobie przykład a ty zaczynasz szydzić z php i odwracasz kota ogonem. Czy to php czy C++, czy Java - idea dziedziczenia zbierana. Mógłby to napisać nawet w pseudokodzie. Jeśli nie potrafisz zrozumieć kilku linii php i idei tejże hierarchii to dużo mówi o tobie. Zawsze byłeś bezczelny ale dziś przeginasz a te posty moim zdaniem juz dawno zapracowały na urlop. Sam mam raka od php i tylko 4 razy w życiu musiałem coś w nim rozwijać i fakt jest dużo luk bezpieczeństwa i sama idea dość kiepska ale na tym stoi sporo internetu i trzeba być ignorantem żeby to ignorować. I nie wyskakuj z milionem much ... to jest napisane i ten ekosystem musi żyć jak cobol, Java, C++. Za tym masturbowania się technologia i ego programistów stoi biznes i to ob dyktuje co i jak bo bez biznesu programiści nie wyszli by z piwnicy.

Hispano-Suiza

@somedev: bawisz sie w matke Terese? Bedziesz mnie wychowywac, i umoralniac, bo Twoim zdaniem (...). Wiesz gdzie mam Twoje zdanie? Juz raz mialem okazje z Toba dyskutowac wraz z innymi odnosnie systemow, i zrobiles tam z siebie gamonia bez podstawowej wiedzy o systemach Unixowych zaczynajac wytykac im problemy, ktore nie istnieja. Kilka osob Ci pisalo, ze gadasz glupoty to ich olales rowno Panie znawco.
Jak rozumiem zakladacie klub wzajemnego samozaorania? Podsmiewam sie z php na bazie wlasnych doswiadczen, i mam ku temu pelne prawo, i podstawy.
Jak na razie to masturbuja sie Twoi kumple z koła hurr durr fejsbuk stoi na php, baidu tez na php. Cos im mrugnelo przed okiem, a nie maja pojecia co. Ich wiedza skonczyla sie nim zdazyla sie zaczac. Specjalisci jednego stacku sa najgorsi. Tak samo jak fanatycy JS, ktorzy zaprogramowaliby w nim wlasna matke gdyby tylko ktos dal im do tego odpowiedni framework.
Zarowno Baidu jak i FB kiedys staly na php. Ale mamy 2019 rok. Swiat sie rozwija. Java w wersji 12, MS ma .NET Core w wersji 3.0. Za rogiem C++ 20, a PHPowcy dalej bija piane przerabiajac swoj jezyk na Java style.

somedev

@Hispano-Suiza: jak ma razie to Ty przedstawiasz chamstwo i szczeniackie zacięcie. Ja nigdzie nie wspominam o FB bo tu akurat masz racje - ich zastosowanie php i ich backend jest specyficzny i ich na to stać. Ale co ma samo php do tego ze najpierw wymaga się od gościa przykładu a potem się go ignoruje wymawiając technologia która nie ma nic do samej idei tejże hierarchii? Tak kiedyś dyskutowaliśmy ale to ze w ogóle używasz takich slow jak zaoranie świadczy o Twoim poziomie - ale dobrze jak sprawia to Tobie przyjemność to musisz mieć smutne i gnuśne życie wiec cieszę się ze dałem Tobie promyk radości. Wstyd ze ktoś z naszego fachu ma usposobienie dresa i wyzywa kogoś jak tylko brakuje mu argumentów EOT idę się zesrać wiec już się nie fatyguj i nie strzęp klawiatury.

LukeJL

@TomRZ - np. pierwiastki chemiczne, - pierwiastki chemiczne to akurat słabiutki kandydat na dziedziczenie, przecież dany "pierwiastek" to po prostu logiczny zbiór wszystkich atomów, które mają odpowiednia liczba protonów w jądrze (dobrze mówię? Aż spojrzałem na wiki, żeby się upewnić, i chodzi zdaje się o liczbę protonów), i to jeśli będzie miał 6 protonów to będzie to węgiel, jak 8 to tlen itp. Więc nie ma sensu robić stu iluś klas dla każdego pierwiastka - tylko raczej należałoby to zamodelować poprzez dane - liczba protonów, liczba neutronów (odpowiadająca za określony izotop), ile elektronów i jak rozmieszczone itp. jeśli dziedziczenie to prędzej widzę tu szansę na dziedziczenie prototypowe niż klasowe. O ile w ogóle potrzebujemy obiektowości - bo tu obiektowości nie widzę za bardzo - jakie metody może mieć pierwiastek? (może i może mieć jakieś, jakby iść w głębszą symulację, to mógłby mieć metody np. do przeprowadzania reakcji - ale znowu - czy nie jest tak, że prawidła chemiczne są uniwersalne i wynikają z praw fizyki, i są dla każdego pierwiastka takie same? Więc wystarczyłoby zrobić jedną klasę ChemicalElement i już.

LukeJL

@TomRZ - struktury które są bardzo niezmienne - np. pierwiastki chemiczne - BTW założenie, że pierwiastki są niezmienne neguje istnienie reakcji jądrowych, więc nie jest to pogląd do utrzymania dzisiaj.

scibi92

@somekind @Shalom @aurel proszę o przyjrzenie się ten "dyskusji" bo mam wrażenie że niektórzy chcą odpocząć od forum, może im pomóc?

Shalom

tl;dr, proszę się zachowywać! :P

LukeJL

(autosprostowanie - że zapędziłem się trochę w tym: widzę tu szansę na dziedziczenie prototypowe niż klasowe. O ile w ogóle potrzebujemy obiektowości - w sumie dziedziczenie prototypowe nie musi być związane z obiektówką w ogóle. Po prostu wzorzec kreacyjny - jak fabryka - to możemy dla wygody trzymać prototypy zawierające domyślne dane czegoś, żeby nie przypisywać tych samych właściwości ciągle. Ale nie musi to być związane z OOP, można operować na tym bardziej w stylu data oriented. Co do dziedziczenia klasowego to nie wiem - czy dziedziczenie klasowe jest związane z OOP (implikuje OOP) czy niekoniecznie? Chociaż ludzie czesto piszą kod na klasach i z dziedziczeniem, który OOP nie jest, tylko proceduralny, więc pewnie nie)

TomRZ

@LukeJL: te dwa przykłady z pierwiastkami i hondą napisałem naprawdę szybko nie zastanawiając się bo pracowałem. Później podałem inny przykład który jest chyba sensowniejszy (sam tak robie) dotyczący pól formularza, plus mój skromny system cache z synchronizacją procesów PHP gdzie też robię dziedziczenie - tym razem z adaptera interfejsu. To są właściwsze przykłady do skrytykowania/przeanalizowania.

tdudzik

No nie, ledwo co udało mi sie w końcu kilka razy zamienić po ludzku pare zdan z @Hispano to tak to się skończyło. :D Choć cieszę się, że w końcu inni zauważyli problem, czułem się w tym trochę osamotniony. :D

LukeJL

@TomRZ: no jeśli to dziedziczenie jednostopniowe - klasa bazowa FormField i wszystkie, które z niej wychodzą, to ja jeszcze uznaję takie coś, ale mam wrażenie, że to co naprawdę chcemy w tym przypadku to 1. żeby wszystkie pola traktować jednakowo z zewnątrz, można to osiągnąć na inne sposoby niż dziedziczenie po klasie - można np. zaimplementować interfejs jeśli język programowania wspiera interfejsy, w językach kaczo typowanych można by po prostu zaimplementować odpowiednie metody (np. metodę validate). Można też potraktować pola formularza przedmiotowo i zamiast tworzyć instancję klasy FormField, po prostu by się przekazywało gdzieś do jakiegoś renderera formularzy dane o polach do wyświetlenia. Każde pole mogłoby być reprezentowane przez jakąś funkcję, która definiuje jak pole ma się wyświetlać i jak się ma odbywać interakcja (czyli mniej więcej to, co jest w React, zakładając, że korzystamy z obiektów funkcyjnych).2. być może też istnieje potrzeba, żeby od wewnątrz użyć jakiegoś kodu (np. użyć metody klasy bazowej) - ale to moim zdaniem słaby argument za dziedziczeniem - bo wystarczy przecież "wyciągnąć" kod, który chcemy użyć do osobnej klasy albo do funkcji - i już nie musimy korzystać z dziedziczenia.

LukeJL

@TomRZ czyli jak dla mnie dziedziczenie ma sens jeszcze do tego, żeby od zewnątrz obiekty wyglądały na takie same (miały ten sam typ, ale inaczej się zachowywały wśrodku - czyli polimorfizm). Przy czym jest to tylko jedna i dość niewygodna metoda osiągnięcia polimorfizmu. Natomiast jeśli chodzi o samo użycie ponowne kodu, to jest to dla mnie słaby powód dla dziedziczenia.

TomRZ

@LukeJL: z interfejsami jest ten problem, że kiedy coś w interfejsie zmieniasz, to bez pośredniczącego adaptera musisz wykonać zmiany także we wszysktich klasach które go implementują. Dlatego ja często używam adapterów szczególnie do rozbudowanych interfejsów. Potem z tego adaptera dziedziczę, kiedy zmienię coś w interfejsie, najcześciej wystarczy, że zmienię sam adapter, be zpotrzeby zmian we wszystkich klasach dziedziczących z adaptera. Dziedziczenie w przypadku pól w swoim systemie stosuję dlatego, że wydaje mi się to bardzo naturalne podejście, aż się prosi aby to robić. Natomiast wszystko można realizować na różne sposoby. Mam swój prywatny projekt generatora backendów/administratorów gdzie wszystko jest mocno abstrakcyjne, i tam to dziedziczenie się sprawdza. Myślę zresztą o zrobieniu swego radzaju klonu tego projektu już publicznie, z pewnymi zmianami, ale brak czasu... wtedy na pewno możnaby sensowniej porozmawiać.

danek

rozbudowanych interfejsów. to może być problem

TomRZ

@danek: czasem trzeba zrobić interfejs który składa się więcej niż tylko z kilku metod. Mam na przykład w projekcie interfejs dystrybutora produktów / hurtowni, który dostarcza cyklicznie dane do sklepu (a raczej sklep ciągnie od niego dane). Dystrbutorzy są bardzo różni, na różne sposoby dostarczają dane, w różnych formatach, asortyment też jest bardzo różny: od RTV po cyfrowe klucze aktywacyjne, czy np. meble, albo czapki. Tutaj jest sporo abstrakcji, i nie wystarczy interfejs z kilkoma metodami.

danek

A czemu jeden interface, a nie kilka mniejszych?

TomRZ

@danek - ale po co mi kilka mniejszych interfejsów? To jest jeszcze większe zamieszanie. Dystrybutora nie da się podzielić na mniejsze kawałki, to znaczy na upartego można tylko po co. Wszystko doskonale działa i się sprawdza. Co pewien czas dochodzą nowi dystrybutorzy i dzieki abstrakcji nie ma żadnych problemów z ich dodawaniem, i implementowaniem metod interfejsu.

LukeJL

@TomRZ że kiedy coś w interfejsie zmieniasz, to bez pośredniczącego adaptera musisz wykonać zmiany także we wszysktich klasach które go implementują. w ActiveX robiło się tak, że każdy interfejs był niezmienny i jak były zmiany w API to po prostu robiłeś nową wersję interfejsu (tzn. nowy interfejs np. Foo1, Foo2, Foo3 itp.). A dostęp do interfejsu się uzyskiwało przez dynamiczne odpytanie obiektu o konkretny interfejs.

TomRZ

@LukeJL: to też jest jakieś wyjście chociaż trochę harcorowe :) Z ActiveX to ja tylko kojarzę kontrolki do przeglądarki IE z którymi muszę czasem grzebać, np. jedna z nich obsługuje mi automatyzację drukarki fiskalnej.

LukeJL

ActiveX i COM to była zabawa. DirectX można było tym obsługiwać z tego co pamiętam, DirectShow (biblioteka do multimediów), można też było integrować się z powłoką i robić dodatki do eksploratora windows, czy coś takiego.

TomRZ

To jeszcze czasy Acitve Server Pages, musiałem w tym kiedyś grzebać bo mi zabronili PHP (argumenty a'la Hispano), no to męczyłem, to była masakra.... w końcu udało mi się ich namówić na Javę, i już było lepiej. Stare dzieje.

somekind
  1. Jest coś takiego jak SOLID, w szczególności Interface Segregation Principle. Ja osobiście nie mam problemu z interfejsami z jedną metodą, rzadko zresztą potrzeba więcej. Po pierwsze dlatego, że takiego interfejsu z dwiema metodami często nie da się sensownie nazwać. Po drugie dlatego, że więcej metod w interfejsie, to więcej publicznych metod w klasie... a więcej niż jedna metoda publiczna w klasie ma sens jeszcze rzadziej niż dwie metody w interfejsie. To, co potrzeba, to raczej mniej interfejsów w ogóle, bo niektórzy koproprogramiści się naczytali, że wszędzie wszystko trzeba oddzielać interfejsami, a potem piszą jakieś porąbane konfiguracje IoC bazujące na kolejności argumentów w metodach albo ich nazwach. A potem pojawiają się ludzie, którzy twierdzą, że kontenery IoC to zło.
  2. Dziedziczenie jest podstawą niektórych wzorców projektowych, np. template method. Nie wiem jak u Was, u mnie tak na oko połowa klas jest elementem implementacji tego wzorca. Dziedziczenie jest ok, jeśli jest dobrze użyte. I ogólnie mam taką teorię, że jak używamy dziedziczenia w klasie, która nie łamie SRP, to nie rodzi to żadnych zagrożeń. Problemy pojawiają się, gdy klasa robi za dużo, a potem pojawiają się jej dzieci, które robią jeszcze więcej przy użyciu ifów i sprawdzania typów argumentów.
viader

Szczerze, nie podoba mi się podany wzorzec Template Method, nie rozumiem przewagi jego nad kompozycją, w projekcie przy którym obecnie pracuję liczba naszych klas abstrakcyjnych wynosi zero. Dla mnie twór pod tytułem klasa abstrakcyjna mógłby zniknąć, interfejsy tylko tam gdzie wymagany polimorfizm, a dalej kompozycja.

viader

@TomRZ jeśli chodzi o AbstractAdaptery by nie implementowac wszystkich funkcji to interface masz duże i najwidoczniej specyfika PHP. Ponieważ w Javie/Kotlinie możesz mieć w interfejsie defaultowa implementację metody.
W przeszłości jeszcze używałem abstrakcyjnych klas przy bazowych modelach jeśli potrzebowalem polimorfizmu w modelach, ale teraz w Kotlinie są sealed classy, które lepiej do tego się nadają.

somekind

@viader: gdy zastępujesz template method kompozycją, to co robisz, aby nie mieć powielonego kodu?

viader

Oddzielną klasę, która implementuje tylko "template method", a w konstruktorze przyjmuje obiekty typu konkretnej klasy albo interfejsu mające wykonywać poszczególne kroki.

somekind

Masz pięć kroków algorytmu i osiem rodzajów danych wejściowych, pierwsze dwa i ostatnie dwa kroki są takie same, tylko środkowy się różni w zależności od wejścia. Jak rozumiem, przy Twoim podejściu masz wywołania konstruktora powielone 8 razy, za każdym razem różniące się tylko środkowym parametrem?

viader

Nie, uzylbym interfejsu na srodkowe pola w postaci strategii wyboru implementacji w zaleznosci od wejscia

somekind

Załóżmy zatem, że trzeci i czwarty krok są zmienne w zależności od typu wejścia (do całego procesu). 1. Czyli robisz osiem strategii na trzeci krok, osiem na czwarty krok i w sumie masz 64 kombinacje, które można dowolnie łączyć, nawet jeśli to nie ma sensu? 2. Każda Twoja strategia musi poznać typ wejścia, nawet jeśli w ogólności nie jest to potrzebne, bo może pracować na jakichś pośrednich wynikach?

viader

@somekind się rozpedziles z fantazją :D nie rozumiem dobrze tego przykładu, ale mam pomysł napisz przykladowy Template Method z wejściem i wyjściem używając do tego swoich klas abstrakcyjnych, a ja dopisze do tego swoją wersje z kompozycją.

somekind

No też mi się tak wydaje, że bez kodu będzie ciężko to rozwikłać, bo sam się powoli gubię. ;) W wolnej chwili coś podrzucę.

somekind

@viader: no kodu z pracy wyciągnąć oczywiście nie mogę, więc taka uproszczona wersja. W rzeczywistości te wszystkie ordery i itemy są większe, więc też metody na nich operujące są większe i mają więcej sensu. ;) Ale mam nadzieję, że pokazuję ideę: https://ideone.com/3MrSUo Chętnie zobaczę Twoje rozwiązanie w pełni oparte o kompozycję.

viader

@somekind: postarałem się być jak najbliższy Twojej wersji kodu (podobne nazwy wszędzie itp) i nie starać się analizować wymagań tych converterów tylko przerobić z klas abstrakcyjnych to co masz na kompozycje. Wyszło mi takie coś: https://pl.kotl.in/sj4ei9kVL

somekind

Ok, nieźle. A jak wygląda konfiguracja kontenera IoC do tego?

danek

A czy wszystko trzeba robić kontenerem IoC? ;)

tdudzik

O to samo chciałem zapytać. :D

somekind

Owszem, trzeba. Może nie wszystko, ale tam gdzie i tak jest używany, to wypada.

viader

@somekind naprawdę tutaj dużo więcej zależy od wymagań biznesowych, ale jeszcze nie zdarzyło mi się by jakieś wymagania biznesowe sprawiło mi jakieś problemy z konfiguracją IoC

viader

jeśli jakiś szczególny case Cię interesuje, to jak zapodasz kod postaram się pokazać jakbym to w IoC u siebie umieścił

somekind

@viader - no masz dwie klasy, jedna potrzebuje przetwarzania StandardOrderów, druga IndustryOrderów, ja do jednej wstrzyknę StandardOrderProcessor, a do drugiej IndustryOrderProcessor. A co Ty zrobisz z tą kompozycją?

tdudzik

@somekind: w sumie te processory wyglądają jak domain service. Nie widze powodu, żeby nie skorzystać ze zwykłego new, nawet jak gdzie indziej kontener IoC jest wykorzystywany. Wręcz uznałbym, że wstrzykiwanie byłoby nadużyciem.

viader

@somekind w moim kontenerze raczej IoC odróżni tworzenie dwóch klas template'owych na podstawie typów, jeśli jednak nie odróżniałby użyłbym na przykład tagów

viader

ogólnie bardzo mało wykorzystuję templaty, ale jeśli potrzebuję wstrzykiwać różne implementacje 1 interfejsu do różnych klas, a jednocześnie nie upubliczniać nigdzie czegoś innego niż interfejs to używam tagów

somekind

@tdudzik: ja zazwyczaj mam jednak jakiś graf zależności, więc pisanie kilkunastu new i aktualizacja w razie jakiejś zmiany uznaję za sporą stratę czasu. @viader: no ja chyba nie mam kontenera, który by OrderProcessor(StandardOrderProcessorConverter() od OrderProcessor(IndustryOrderProcessorConverter() odróżnił, dlatego pytam. Co nazywasz "tagami"? Jakies magiczne stringi?

danek

@somekind: trochę nie rozumiem, w ogóle nie używacie new?

viader

OrderProcessor(StandardOrderProcessorConverter()) to tak naprawdę ma typ OrderProcessor<StandardOrder, StandardOrderItem>, a ten drugi to OrderProcessor<IndustryOrder, IndustryOrderItem> także być może by zaśmigało.
Ogólnie graf składam z modułów i każdy moduł dorzuca swój kawałek grafu, każdy taki kawałek to pojedyńczy plik z kilkoma linijkami, jeśli wewnątrz modułu chce przekazać prywatnie jakąś zależność to używam tagu, który jest Stringiem, Inna sprawa jakbyś chciał korzystać z różnych modułów z takich obiektów, dałbym chyba opakowanie w stylu StandardOrderProcessorProvider (zawierający OrderProcessor odpowiedni) i IndustryOrderProcessorProvider (zawierający OrderProcessor odpowiedni)

somekind

@viader: zarejestrować w kontenerze jako oddzielne typy to dla mnie nie jest problem, problem z wstrzyknięciem tego do konstruktora, który przymuje generyki. Mój kod nie ma tego problemu, konkretna klasa jest wstrzykiwana w konkretne miejsce. @danek: używamy, ale nie po to, aby utrudniać sobie życie.

viader

@somekind nie rozumiem niestety problemu, musiałbyś znowu mi kawałek kodu napisać c:

somekind

@viader - ale co mam napisać? Mój kod jest wstrzykiwalny przez IoC out of the box., Twój jak sam twierdzisz "może by zaśmigał", a jak nie to będziesz jakieś providery pisał.

viader

W sensie zrobienie providera to kłopot? Czy taki provider nie sprawdziłby się u Ciebie z jakiegoś powodu?