Cześć, programuję w php, js, html, css, czyli taki standard jeżeli chodzi o strony www, frameworki to: laravel, vue.js, materializecss, może niektórzy mnie kojarzą po nicku.

Spotykam się czasem podczas pisania aplikacji z tym, że w pewnym momencie np. w połowie prac, uświadamiam sobie, że kod jest bardziej zawile napisany niż mógłbym być.
Załóżmy, że chciałem zastosować do kilku funkcjonalności tą samą część kodu i teraz okazuje się, że, aby tą część wykorzystać, komplikuję sobie świeżo pisane rzeczy, żeby je dostosować do tego co już mam. Teraz przyszło mi na myśl, czy aż tak ważne jest to, aby nie powielać kodu, bo w sumie kierując się taką genezą, wszystko mam (tak mi się wydaje) napisane bardziej zawile, ostatecznie tylko po to, żeby wykorzystać istniejące elementy i dostosować do nich nowe.
Przeważnie znajdują się jakieś mini różnice w poszczególnych funkcjonalnościach, które po zsumowaniu robią o wiele większy bałagan niż jakby napisać dla każdej funkcjonalności oddzielnie ten "uniwersalny kod".
Dodatkowo, jeśli teraz chciałbym zmienić rzeczy, które są używane w kilkunastu miejscach, to te kilkanaście miejsc przestaje działać z automatu i muszę je wszystkie poprawiać.
Nie wiem, czy przedstawienie sprawy w tak ogólny i teoretyczny sposób pozwoli Wam się odnieść do tematu, jeśli nie to podam jakiś przykład.

Druga rzecz, to np. 5 lub więcej rozwiązań jednego problemu, gdzie większość wydaje się być niezła.
Jak podejmujecie decyzje, czy na szybko, czy jakoś bardziej analizujecie, bo mi schodzi trochę czasu na takie analizy i jest to dość irytujące?

Mam w sobie jakąś taką cechę, że strasznie drażni mnie jak zaczyna się robić bałagan i zależy mi bardzo na prostocie i przejrzystości tego co piszę, zarówno od strony użytkownika jak i programisty, chciałbym, żeby to co piszę było idealne i jak mi się nie udaje to mam nerwy.

Czy macie podobne problemy, jeśli tak, jak sobie z nimi radzicie?

Może to kwestia doświadczenia, programuję zawodowo już praktycznie 2 lata, więc trochę doświadczenia nabrałem, ale to jednak nie 10 lat:p
Próbuję sobie wytworzyć jakieś standardy i rozwiązania powtarzalnych problemów, czyli np. stosować jeden lub dwa typy formularzy we froncie, na upload filmów mieć jeden sprawdzony sposób po stronie użytkownika i serwera, usuwanie zasobów też działające w konkretny sposób do wielokrotnego stosowania.

Tylko teraz pytanie się pojawia, czy chcąc budować taką swoją bazę rozwiązań nie zostanę w tyle, przez to, że nie zapoznaję się z innymi narzędziami, a pracuję cały czas na tych samych, oczywiście aktualnych wersjach.

Co sądzicie?

Stosuj dziedziczenie, kompozycję, SOLID i wzorce projektowe. Pisz małe funkcje, zamykaj je w klasach które mają pojedynczą odpowiedzialność. Pisz testy jednostkowe/integracyjne.

Polecam Ci przeczytać (i podumać nad) Clean Code. Jak zaczniesz ogarniać wzorce, i zobaczysz po co tak na prawdę jest singleton czy factory, oraz jakie niebezpieczeństwa się z tym niosą, to zaczniesz pisać ładniej.

Mrc, używam frameworka (Laravel), tam pewna stylistyka pisania jest już narzucona i pewne wzorce są wykorzystywane.
Czytałem kiedyś o różnych wzorcach i robiłem różne przykłady, ale korzystając z frameworka, mam to gotowe, więc się zapomina siłą rzeczy.
Na jakich frameworkah pracowałeś i ile czasu, jeśli można wiedzieć?

Mam na swoim koncie kilka większych aplikacji.
Półtora roku doświadczenia w pracy z Laravel, więc to nie tego typu problemy, żeby stosować obiektowe programowanie

Mimo to dzięki za odpowiedź.

Może na przykładzie:
Mam multiformularze w większości widoków zasobów.
Formularz jest generowany vue.jsem.
Lista zasobów tak samo, więc dane dla listy muszą być w jsonie.
Natomiast dane z formularza mogę przesłać w jednym polu w jsonie, albo normalnie, albo połączyć obie metody, wszystko zależy od rodzaju zasobu.
Jeśli mam dane tekstowe tylko, to json jest okej, nawet kiedy mam obraz do przesłania to html 5 również umożliwia przesłanie go jsonem, ale co np. kiedy chcę przesłać pdf, lub film, wtedy muszę przy wybraniu pliku, przesłać go do tymczasowego folderu ajaxem, najlepiej wyświetlić go w formularzu i jeszcze dodać opcję usunięcia i wybrania ponownie pliku, tak dla każdej pozycji w formularzu, bo jak wspomniałem są to multiformularze.
Już w tym momencie jest kilka możliwości rozwiązania tych zagadnień i załóżmy, że upload jest wykorzystywany w kilku miejscach. Zgodnie z zasadą niepowielania kodu dobrze byłoby stworzyć narzędzie (metody, widok w vue.js) do uploadu filmików i obrazów, ale później przychodzi kolejna funkcjonalność: upload kilku obrazów na raz i to po przez upuszczenie, a nie tylko wybór plików standardowy i co, modyfikować to co mamy, pod następną funkcjonalność komplikując sobie jeszcze bardziej to co i tak już dość zawiłe przez to, że obsługuje i filmy i obrazy?

to jest chyba słowo klucz

2 lata Zend (edit), 2 lata Kohana, rok Symfony i 3 miesiące Laravel. Framework nie jest tak ważny. Własną logikę biznesową budujesz w każdym fw. Jeżeli jej nie budujesz, to znaczy że robisz to źle. Co do wzorców, pamiętaj że np. samo stworzenie jednolinijkowej statycznej funkcji factory() nie powoduje jeszcze, że tworzysz fabrykę (dobrą fabrykę). Niestety, nawet popularne frameworki czy biblioteki mają sporo takich udziwnień.


--Edit--

Przepatrzyłem swój profil na LinkedIn. Dwa lata zenda poproszę.

Zenda nie znam, na Kohanie niestety, albo stety dane mi było pracować chwilę, przynajmniej wiem jaka jest kiepska , jak CodeIgniter lub gorzej
Rok Symfony i 3 miesiące Laravel można porównać do mojego półtora roku na Laravel.

Odnośnie tego, że framework nie jest tak ważny nie zgodzę się, wystarczy porównać Kohanę lub CodeIgnitera z Laravelem, albo Symfony - zupełnie inny poziom pisania, choćby przez composera i artisana w laravel, ale to inny temat.

Nie ma co porównywać doświadczeń. Moje doświadczenia są takie, że wszędzie jest jakaś logika biznesowa, o którą trzeba dbać - pisać testy, refactorować itp. Jeżeli rozmieszczasz wszystko w akcjach i klasach modelowych, to współczuję. Wtedy nie masz logiki.

Umieszczam kod w miejscach uzależnionych od potrzeb, ale w ogromnej przewadze są to jednak kontrolery i modele, używam zdarzeń, middlewarów, jobsów praktycznie nigdy, bo są rzadko potrzebne, walidacji w requestach, jednak request nie zwróci mi obiektu z danymi jakie dostał plus z tablicą z errorami, dlatego mam to w kontrolerach w ostatnich projektach.
Oprócz tego są przecież widoki, tłumaczenia, są configi, migracje, seedy, to wszystko też się składa na logikę aplikacji, jest storage ogarniający pliki, composer, artisan...

Moje rozterki nie są raczej banalne, ale rzeczywiście ta pojedyncza odpowiedzialność w metodach u mnie rzeczywiście trochę na bakier, muszę nad tym popracować.

Stosuj wyżej podane techniki, a na pewno polepszy się Twój ogólny proces programowania. Do tego staraj się nazywać zmienne lepiej, nie komentuj rzeczy, które w oczywisty sposób wychodzą z kodu. W ogóle, to wszystko co mówię - to jest napisane w Clean Code. Ta książka zmieniła moje postrzeganie kodu, odkąd ją zrozumiałem (!= przeczytałem) nie mam problemów z czytelnością kodu.

dzięki za informację


dochodzi do tego jeszcze odpoczynek (dużo odpoczynku)

+1 ZenekN

Do odpoczynku dochodzi uprawianie sportu, życie poza komputerem, wychodzenie z domu i wiele innych, które sprawiają że jesteś świeży.

Okej mrc, zastanawia mnie tylko dlaczego wychodzisz z założenia, że ich nie stosuję, przynajmniej zdecydowanej większości.

Bo te techniki zapobiegają problemom z nieczytelnym i skomplikowanym kodem - a Ty z tym masz problem. Ok, może źle mówię, może stosujesz (tego nie wiem) - ale coś w takim razie idzie Ci z tym nie tak jak potrzeba.

Sądzę, że większość programistów ma z tym problem nie tylko Ja, są tego może mniej świadomi, miałem do czynienia z kodem różnych ludzi, nawet z większym doświadczeniem od siebie i to chyba oczywiste, nie był idealny.

Dobra ogarnę książkę o czystym kodzie, ale wątpię, że będzie do zastosowania z niej wiele rzeczy na frameworku, obym się mylił, zobaczymy.

Ogólnie mam podobny problem ale chyba dlatego że jestem dość roztargniony i nie podchodzę do tematu tak jak potrzeba.

Prosta odpowiedź


Miałem problem o którym pisałem na forum (jestem samoukiem) zleciłem projekt dobremu programiście na początku byłem zachwycony tym człowiekiem myślałem że jest świetnym programistą.
Tylko pamiętam ciągle słowa "Nie będę ciągle wprowadzał poprawek" czyli że coś było ciągle ze mną nie tak,

Po kilku latach nauki z mojej strony kiedy już znacznie rozumiem wzorce

A wystarczyło wprowadzić prawidłowo relacje w bazie danych np.(n:n) i voila problem rozwiązany.


Czyli tak jak autor wyżej napisał wracajmy do wzorców i analizujmy je krok po kroku

@mrc mowisz o tej ksiazce?
http://ricardogeek.com/docs/clean_code.pdf

@nospor

Tak, ta książka. Osobiście, wolę drukowaną wersję I niebiesko-czarną okładkę

Teraz mam np. problem tego typu, że w systemie, nad którym pracuję, jest kilka zasobów wykorzystujących obrazy i filmy.
Przykładowo:
1. Slider
- upload filmów z wyborem miniaturki z filmu,
- obrazy również z miniaturkami.
2. Galeria
- obrazy z miniaturkami.
3. Klipy
- upload filmów z wyborem miniaturki z filmu,

Zrobiłem to na zasadzie takiej, że każdy zasób, nazwy swoich plików przechowuje we wlasnej tabeli i teraz zastanawiam się, czy nie było by lepiej zrobić dla każdego rodzaju pliku oddzielną tabelę, a w tabelach zasobów przechowywać tylko referencje, wtedy miałbym tylko jeden model od filmów i nie musiałbym ogarniać obsługi plików filmów w sensie uploadu, czy usuwania w kilku miejscach.
Natomiast minus jest taki, że przy wprowadzeniu np. 10 slidów jednocześnie, najpierw muszę dodać filmy do tabeli z filmami, obrazy do tabeli z obrazami, później dopiero wprowadzać same slidy z odpowiednimi referencjami.

Nie jest trochę tak, że szukasz rozwiązania na problemy implementacyjne?

Przykłady, które podałeś nie są raczej przypadkami natury warsztatu, architektury etc. Tylko bardziej szukanie rozwiązań konkretnych zagadnień, a tych w programowaniu może być bardzo dużo. Przy tym wiele z nich będzie poprawnych, nie będzie jednego najlepszego.

Właśnie o to mi chodzi, że to moje problemy nie dotyczą tylko warsztatu, a sięgają trochę głębiej, niemniej jednak pozycja http://helion.pl/ksiazki/czysty-kod-podrec...rtin,czykov.htm sądzę, że się przyda i odświeżenie sobie wzorców też.

Pracując na frameworku całą strukturę mam gotową praktycznie. Korzystam z wzorców, nie tworząc ich, przez co zapominam jak działają.
Kiedyś uczyłem się o wzorcach analizując dokładnie przykłady z książki, a na dzień dzisiejszy ta wiedza jakby wyparowała .
Wychodzi na to, że ta na nauka, była stylu, zakuć, zdać, zapomnieć, a nie cierpię się tak uczyć.
Wiele bardziej wolę zapamiętywać w trakcie używania.

http://helion.pl/ksiazki/php-wzorce-projek...ders,phpwzo.htm

Ten tytuł sobie również przestudiuję, zobaczymy co przyniesie.

Omenomn może ucz się tak: dowiedz się, czym jest fasada, i zacznij w swoim projekcie (projektach) szukać miejsca, gdzie fasadę można wstawić. Rób refactory i wstawiaj fasady. Później poczytaj czym są fabryki i zastanów się, gdzie u siebie możesz takie fabryki wstawiać.

Oczywiście, do tego trzeba mieć logikę biznesową - zestawy klas które realizują algorytmy, połączenia z bazą czy innymi elementami jak np. curl, guzzle, websockety, systemy kolejkowe.

z góry przepraszam za lekki spam, ale z tematu pod KOD zajebiście podchodzi ;D
zabrakło mi doświadczenia i ostrożności - oby i Tobie nie zabrakło doświadczenia i ostrożności ;D

Nie ma idealnego kodu, ale za to jest Refaktoryzacja. Magiczne i jakże przydatne słowo. Polecam. I nie na uraaaa za wszystko się brać, tylko małymi kroczkami powoli, do przodu.

Omenomn

Pierwsze co zrób to zapomnij o frameworku. Nie ważne czy używasz Laravela, Zenda, Symfony, to tylko baza dla resposne i request i tam się sprawdza, ale nie jako logika biznesowa. Twój model biznesowy, który powinieneś poznać zanim tak naprawdę zabierzesz się za tworzenie czegokolwiek, nie zależy od języka programowania, a tym bardziej o jakieś wymyślonej w nim implementacji w postaci Frameworka. Myślenie skoro gość X od fw y robi to tak to ja tez mogę, jest bardzo zgubne. Nie da się stworzyć gotowca na tyle uniwersalnego, żeby dla każdego problemu jaki istnieje dało się w nim stworzyć najlepsze rozwiązanie. Uniwersalne są tylko wzorce projektowe. Dlatego analizując Twój przypadek z dużym prawdopodobieństwem mogę stwierdzić, że zacząłeś typowo, mam do zrobienia projekt X, no to stawiam nowa instancje Laravela, potem co, pewnie baza danych. Po tygodniu/ miesiącu, okazuje się ze czegoś zapomniałeś nie uwzględniłeś, bazę trzeba zmienić i pól kodu. No i pojawiają się takie problemy jak tym masz, a wszystko przez to, że zacząłeś od złej strony. Zanim napisałeś pierwsza linijkę kodu powinieneś poznać swój model domenowy, jak już go poznasz to dopiero wtedy do niego dobierać odpowiednie narzędzia które pozwolą Ci go stworzyć łatwiej, a nie na odwrót. Wtedy dostrzeżesz znacznie więcej, kod będzie dużo bardziej czysty i reuzywalny niż wcześniej.

Sądzę, że umniejszasz trochę frameworkom jednak.

Już wymyśliłem jak ogarnąć to uploadowanie, żeby miało sens i wykorzystałem wzorzec dekorator do tego.
Przykładowe przesłanie pliku wygląda tak:

[PHP] pobierz, plaintext 
$thumbnail = new Property(new ContentImage(new Thumbnail(new Encoder(new File())));
$thumbnail->make($request->file);
[PHP] pobierz, plaintext 

1. Property - pobieranie właściwości pliku (nazwa, path, rozszerzenie).
2. ContentImage - pobiera treść pliku.
3. Thumbnail - pomniejsza treść.
4. Encode - określa rozszerzenie.
5. File - tworzy plik.

Tylko mam teraz taki problem, że chciałbym w każdym z tych obiektów mieć dostęp do właściwości pobranych w obiekcie Property i nie mam pomysłu dobrego jak to zrobić.
Encode potrzebuje rozszerzenie, File potrzebuje nazwę pliku, ContentImage wymaga ścieżkę.

Mógłbym przekazywać właściwości dalej w każdym wywołanym obiekcie:

[PHP] pobierz, plaintext 
$this->maker->properties = $this->properties
[PHP] pobierz, plaintext 

jednak to trochę powielanie kodu, mam parę pomysłów, ale żaden jakiś specjalny, a Wy?

Spróbuję się wspomóc obserwatorem.

Nie, framework to tylko narzędzie coś jak IDE, i tak samo jak one może być lepsze lub gorsze, ale to tylko narzędzie ułatwiające prace, nie sprawi, że kod się sam napisze i będzie dobrej jakości.



Jesteś pewny, że dobrze go zrozumiałeś?

https://github.com/domnikl/DesignPatternsPH...tural/Decorator

Tak, a według Ciebie nie?

http://blogophp.com/2009/08/16/dekorator/#more-40
http://stackoverflow.com/questions/1234554...e-re-sizing-etc



Tylko, żeby nauczyć się dobrych praktyk na frameworku potrzeba kupę czasu. Jak ktoś jest oblatany w jednym to nie siądzie na inny i po dwóch miesiącach nie będzie w nim wymiatał, na poznanie frameworka i różnych w nim patentów trzeba czasu.
Framework to nie tylko narzędzie, to w pewnym stopniu narzucona struktura i pewne podejście do programowania.

Dekotator tutaj jest definitywnie złym rozwiązaniem skoro obiekty potrzebują zależności z innych dekoratorów.

Dekoratorem może być tutaj tylko Thumbnail bo on faktycznie coś tam robi na źródłowych danych.

Dobrym rozwiązaniem jest, do przekazywania atrybutów wykorzystałem obserwator, więc mam kombo dekorator-obserwator i jestem Hardkorem

Omenomn, skoro coś Ci w decoratorze nie pasuje, to znaczy że nie jest to dobre rozwiązanie.

Co do frameworków. Możesz być specjalistą w Laravel i 5 lat tłuc jego dobre praktyki. W pomiędzy czasie świat się zmieni. Laravel przestanie mieć większość udziałów na rynku. Będziesz miał problemy w znalezieniu pracy, bo umiesz pisać tylko tak jak uczył Laravel. Moim zdaniem programista to osoba, która nie przyzwyczaja się do rozwiązań, ma otwarty umysł na nowe/inne technologie, języki.

Tak jak wyżej koledzy pisali, fw to tylko fw. Request-Response + MVC. Tak samo, jak PHP to tylko PHP i może się okazać, że za kilka lat będzie trzeba się przebranżowić, albo chociażby zmienić języki. Co wtedy?

10 lat temu ktoś powiedział, że trzeba porzucić PHP, bo z tego języka już nic nie będzie.

Dekorator to dobre rozwiązanie, ale nie wystarczające, więc musiałem je połączyć z innym.
Swoją drogą zadanie dla Was.
Jak we wzorcu dekorator przekazywać pomiędzy obiektami atrybuty elementu dekorowanego, tak, żeby każda klasa miała do nich dostęp i mogła je modyfikować i, żeby każdy obiekt widział te zmiany.

[PHP] pobierz, plaintext 
Co do frameworków. Możesz być specjalistą w Laravel i 5 lat tłuc jego dobre praktyki. W pomiędzy czasie świat się zmieni. Laravel przestanie mieć większość udziałów na rynku. Będziesz miał problemy w znalezieniu pracy, bo umiesz pisać tylko tak jak uczył Laravel. Moim zdaniem programista to osoba, która nie przyzwyczaja się do rozwiązań, ma otwarty umysł na nowe/inne technologie, języki.
 
Tak jak wyżej koledzy pisali, fw to tylko fw. Request-Response + MVC. Tak samo, jak PHP to tylko PHP i może się okazać, że za kilka lat będzie trzeba się przebranżowić, albo chociażby zmienić języki. Co wtedy?
[PHP] pobierz, plaintext 

Powiem Ci tak, jeśli pracujesz na Symfony, albo Laravel, przesiądź się na CodeIgnitera, albo Kochane i zacznij pisać takie same systemy.
Jeżeli nie sprawia Ci to różnicy, to okej, nie wszystkim musi zależeć na jakości pracy, ale jeśli komuś zależy to rękami i nogami będzie się bronił przed taką przesiadką, więc to nie tylko narzędzie request-response + mvc, bo configi, routing, seedy, migracje, storage, env, blade, eventy, jobsy, composer, paczki, artisan, helpery, walidacja, translatory itd.

Więc zdecydowanie uproszczacie, CodeIgniter i Kochana nie ma nawet połowy z tego.
Framework to owszem narzędzie, ale można używać samego młotka, albo wielu wyspecjalizowanych narzędzi, jakich dostarczają dobre frameworki.

[PHP] pobierz, plaintext 
W pomiędzy czasie świat się zmieni. Laravel przestanie mieć większość udziałów na rynku. Będziesz miał problemy w znalezieniu pracy, bo umiesz pisać tylko tak jak uczył Laravel.
[PHP] pobierz, plaintext 

To jest właśnie myślenie ludzi, którzy uczą się miliona rzeczy, a w żadnej nie są specjalistami.
Każdy z osobna ma wpływ na rynek, jeśli zmieniasz to co lubisz na coś czego nie chcesz robić, tylko po, żeby znaleźć pracę, to dostaniesz pracę, ale się nie rozwijasz i w dłuższym czasie jesteś na minus.

Ja np. nienawidzę wordpressa, bo jest zaprzeczeniem obiektowego programowania i ukazuje hipokryzję ludzką, ponieważ wszyscy mówią o obiektowym pisaniu kodu, a później jadą na wordpressie, który jest funkcyjny. Jednak jeśli lubiłbym worpressa, to śmiało mógłbym się w nim rozwijać i cisnąć cały czas, a zmienianie co 4 miesiące cmsa na joomlę, albo drupala, albo jeszcze coś innego, byłoby staniem w miejscu, bo w żadnym z tych narzędzi nie byłbym specjalistą.

Jeżeli siedzi się w czymś np. 2 lata i uzna się, że już osiągnęło się poziom mastera, wtedy można zmienić framework lub narzędzie i można o sobie powiedzieć np. "jestem specjalistą w Laravel, robiłem na nim mnóstwo rzeczy i znam wiele rozwiązań", a nie mówić: "znam Laravela, pracowałem na nim 3 miesiące, zrobiłem jeden mały projekt" - nie znasz, liznąłeś.

Jest takie powiedzenie: "jak coś jest do wszystkiego, to jest do niczego".

Pracuję w Kohana 3.2/3.3 od 2 lat. A nie starszej wersji na linii 2.x. W standardzie pobierając to z githuba Kohana 3.3 ma tylko to co jest potrzebne do realizacji w miarę prostych aplikacji, resztę trzeba albo pobrać z innych repo na githubie (a są ciekawe moduły), albo po prostu napisać samemu. Wymagana jest tu jednak gruntowna znajomość tego jak działa ten FW. Bardzo przyjemnie się z tym frameworkiem pracuje. Na pewno nie tylko ja mam taką przyjemność. Jest jeszcze na pewno jakaś wąska grupa programistów PHP która się tym zajmuje.

Ale do czego zmierzam. Dobry kod? Rzecz w tym że KO3 ma dość specyficzne założenia, między innymi CFS, inny styl nazewnictwa (oparty o underline a nie camelCase), jest inaczej niż w Laravelu czy tam Symfony. Jest to dość prosty, lekki i szybki FW. Ale wystarczy przejrzeć inne oprócz Symfony i Laravela, np. Yii, FuelPHP i jeszcze parę innych. I co każdy inny to i inna filozofia i przyjęte założenia w architekturze.

Jakim to trzeba być ekspertem żeby (i tu bardzo istotna sprawa) we właściwy i praktyczny sposób stosować te różne wzorce typu dekorator czy tam inne? A pytam o to dlatego, że po roku jak się spojrzy na to co się pisało wcześniej (i tu nie ważne na jakim FW czy też bez niego) to można mieć wrażenie, że wcześniejszy kod można było napisać inaczej. I najprawdopodobniej lepiej albo bardziej praktycznie, bo człowiek się uczy.

Dokładnie, a jakim trzeba być ekspertem, żeby traktować framework jako młotek, że mogę się z jednego przesiąść na drugi i zrobić w nim miazgę.

Trzeba by na każdym jednym z tych młotków pracować po minimum dwa lata i mieć je ogarnięte do maksimum możliwości.

@Omenomn

To co mówisz, składa się na to, co już wcześniej pisałem (inny wątek): Ja uczę się programować, a Ty uczysz się używać czegoś, co ktoś zaprogramował.

No to oznacza, że coś jest nie tak z użyciem jego w tym miejscu, skoro zamiast rozwiązać problem pojawił się nowy wynikający z użycia tego wzorca, a dekorowanie dekoratorów, można ale to raczej mija się z celem.



I to jest dobre podsumowanie. Bo tu wcale nie chodzi o to czy się przesiadasz z jednego na drugi, napisałem są lepsze i gorsze narzędzia(frameworki). Po jakimś czasie stawianie projektu opanujesz do perfekcji, ale fw za Ciebie dobrego, czystego kodu nie napisze. Jasne masz masę helperów, które dostarcza w pudełku, ale one są uniwersalne, a nie stworzone dla Twoich potrzeb. Skupiając się tylko wokoło nich, produkt który powstanie będzie dostosowany do narzędzia które użyłeś i automatycznie przestanie być uniwersalny. Używasz Laravela, wiec jeśli znasz trochę jego historii tam zdarzały się BC Breaki co wersje, wiec automatycznie w krótkim czasie rośnie w projekcie dług technologiczny, bo nie wielu stać na to, żeby co nowe wydanie zmieniać projekt i dostosowywać pod nowsze jego wersje. Dlatego u nas na forum znajdziesz osoby pracujące np w Zend 1 chociaż mamy już 3, podobnie jest z innymi tego typu narzędziami.

Nie potrafię zrozumieć po co tyle zachodu. No ale spoko, to Twoje podejście.
Ale np. KO3 daje coś takiego:
https://kohanaframework.org/3.2/guide/api/Upload

no i jeszcze do obrazków (i np. zmiany rozmiaru)
https://kohanaframework.org/3.2/guide/api/Image

W tym sensie framework ma swoje helpery do tych operacji. Laravel i inne pewnie też.

Bardzo chciałbym wiedzieć jak tego typu rozwiązania (i wzorce jakich użyjesz) przekładają się na praktykę
i czy nie będzie problemów z kodami.

Chodzi o to, że kod ma rozwiązywać między innymi takie problemy:
- upload jakiegokolwiek pliku
- upload obrazka
- upload minaturki
- upload obrazka z minaturką
- upload wideo
- upload wideo z miniaturką
- upload wideo z trzema miniaturkami
- plus mogą wystąpić dodatkowe rodzaje plików lub inne konfiguracje

Teraz:
- do operacji na plikach mam bibliotekę
- do operacji na obrazach mam bibliotekę
- i do operacji na filmach mam bibliotekę

Wszystkie wykorzystuję w obu rozwiązanich.

Zwyczajne podejście to:
- Robię kontroler do uploadu plików z metodami np.: uploadVideo, uploadVideoWithThumbnail, uploadImage, uploadImageWithThumbnail i to jest okej, ale:
- muszę pobierać za każdym razem atrybuty pliku:
'name' => $file->getClientOriginalName(),
'extension' => $file->getClientOriginalExtension(),
'path' => $file->getRealPath(),
- muszę za każdym razem ustawiać kontent:
$content = GrImage::make($path); lub $content = \File::get($file); w zależności od typu pliku
- muszę kodować:
$content->encode($extension); lub nie, jeżeli to video
- i wreszcie wrzucić plik:
if ($disk->exists($name))
$disk->delete($name);

$disk->put($name, $content);

Opisałem najprostszą konfigurację.
Standardowym podejściem mogę wszystkie metody przechowywać w kontrolerze i w zależności od potrzeb dopisywać następne (co już jest złym podejściem, bo kod powinno się nadbudowywać, a nie zmieniać już napisany).

- function putFile()
- function getProperties()
- function resizeToThumbnail()
- function makeThumbnail()
- function makeVideo()
- function getThumbnailFromVideo()
itd. itd...

Przez to mam milion metod w kontrolerze i robi się mega bałagan.

Natomiast podejście dekoracyjne wygląda tak:
- zwykły obraz:
$image = new Property(
new ContentImage(
new Image(
new Encoder(
new File))));
$image->make($request->file);
- miniaturka:
$thumbnail = new Property(
new ContentImage(
new Thumbnail(
new Encoder(
new File))));
$image->make($request->file);
- video:
$video = new Property(
new Content(
new Video(
new File)));
$video->make($request->file);
- video z miniaturką
$video = new Property(
new ThumbnailFromVideo(
new Content(
new Video(
new File))));
$video->make($request->file);
- video z trzema miniaturką
$video = new Property(
new ThumbnailFromVideo(
new GetThumbnail(
new ThumbnailFromVideo(
new GetThumbnail(
new ThumbnailFromVideo(
new GetThumbnail(
new Content(
new Video(
new File))));

lub
$video = new ThreeThumbnailsFromVideo(
new Content(
new Video(
new File))));
$video->make($request->file);

Mogę to nadbudowywać jak mi się żywnie podoba. Dodatkowo wszystkie te klasy są obserwatorami obiektu przechowującego konfigurację pliku, więc jeśli będę chciał dodać obiekt zmieniający nazwę Renamer

$video = new ThreeThumbnailsFromVideo(
new Content(
new Video(
new Renamer(
new File)))));
$video->make($request->file);

Wtedy wszystkie obiekty dostają o tym informację (Obserwator).

Ostatecznie dekorator wywołuję przez klienta, więc stworzenie miniaturki będzie wyglądało tak:
use Acme\MakerClients\Thumbnail;

$thumbnail = new Thumbnail;
$thumbnail->make($request->file);

i tak z każdą zawartością.

Chyba macie zbyt sztywne podejście do wzorców, czemu mam stosować jeden, skoro mogę połączyć dwa, to jest o wiele bardziej konstruktywne i ciekawe niż trzymanie się konkretnego wzorca jak sztywnych zasad 10-ciu przykazań.

Skoro chcesz obsługiwać upload po typie pliku to Factory będzie lepszym rozwiązaniem lub Strategia.

Też mi się wydaje że coś na wzór tego mogło by był dobrym rozwiązaniem. Np. tak:

[PHP] pobierz, plaintext 
$files = $_FILES['attachment'];
 
//upload zdjęć
$result = Uploader::factory('Image')
        ->data($files)
        ->execute();
 
//upload filmów
$result = Uploader::factory('Video')
        ->data($files)
        ->execute();
 
//upload muzyki
$result = Uploader::factory('Music')
        ->data($files)
        ->execute();
 
[PHP] pobierz, plaintext 

W tym założeniu (tylko że ja biorę pod uwagę KO3) musiałbym mieć w katalogu application/classes podkatalog Uploader a w nim odpowiednio:
Image.php
Video.php
Music.php

i wszystkie te klasy musiałyby rozszerzać:

[PHP] pobierz, plaintext 
abstract class Uploader {
 
	public static function factory($name)
	{		
		$class = 'Uploader_'.$name;
		return new $class;
	}
 
}
[PHP] pobierz, plaintext 

która to klasa musiałaby być w katalogu classes

Odrębna sprawa to identyfikacja co i czym jest bo po rozszerzeniu pliku to dość prosta sprawa.

Po typie pliku jest tylko jeden upload, który ma zdecydować po rozszerzeniu, czy uploadować wideo z thumbnailem, czy obraz z thumbnailem dla sliderów, ale rzeczywiście, może do decyzji o tym użyję innego wzorca.

Jednak to co pokazałeś daro0 w jaki sposób wykorzystuje kod klas poniższych, jak w dekoratorze?

Czyli, że upload obrazu wykorzystuje ten sam kod do uploadu pliku co wideo:

if ($disk->exists($name))
$disk->delete($name);

$disk->put($name, $content);

i jak w jednym miejscu ogarniesz metodę do pobrania atrybutów pliku, żeby zrobić z nim później co się chce?

Jak to rozwiążesz strategią lub factory?

Przede wszystkim obsługa zapisu/usuwania pliku powinna być oddelegowana do oddzielnej klasy np. StorageHandler(new LocalStorage());
I tam sobie dajesz np.

$storage->store((File)$file);

Czyli defacto masz 2 fabryki: 1 do obsługi pliku samego w sobie a 2 do zapisu/odczytu/usuwania.

Wynikiem 1-szej powinien byc obiekt z którego pobierzesz sobie jakieś tam atrybuty. Wew. niego możesz mieć obiekt np. miniaturki itd itd.

Zakładam że są trzy klasy: Uploader_Image, Uploader_Video oraz Uploader_Music, trzy osobne pliki PHP. Zakładam że rozszerzenie będzie w jakiś sposób ustalane na podstawie tego co jest w $_FILES['attachment']['name'] i jest wyciągane i na podstawie np tego:

[PHP] pobierz, plaintext 
$files = $_FILES['attachment'];
$path = $_FILES['attachment']['name'];
$ext = pathinfo($path, PATHINFO_EXTENSION);
 
$uploaders = array(
    'jpg' => 'Image',
    'png' => 'Image',
    'gig' => 'Image',
    'bmp' => 'Image',
    'avi' => 'Video',
    'mp4' => 'Video',
    'mp3' => 'Music',
);
 
if (array_key_exists($ext, $uploaders))
{
    $uploader = $uploaders[$ext];
    $result = Uploader::factory($uploader)
        ->data($files)
        ->execute();
}
else
{
   // jakis komunikat
}
 
[PHP] pobierz, plaintext 

To tylko jeden z możliwych sposobów.

ale Wy się cały czas rozszerzeniem zajmujecie, a to jest tylko jeden z problemów i to nie aż tak istotny, nie kumacie, czy nie wiem co...

Opisałem to wcześniej.

Jak daro0 chciałbyś utworzyć tym rozwiązaniem sam obraz, albo obraz z miniaturką?
albo samo wideo, albo wideo z miniaturką, albo wideo z trzema miniaturkami?

Czy dekoracja, sama w sobie nie nasuwa się na myśl?

Masz plik i go dekorujesz, "tu mu zmienię rozmiar, tu mu zmienię rozszerzenie, tu mu zmienię nazwę, tu jeszcze coś innego mu zmienię"

i tak sobie zmieniam jak mi się podoba.

Tak w ogóle jak czytam te tutoriale z nazwami klas, metod i zmiennych po polsku, to od razu wiem, że taki tutorial to śmieć.
Jaki dobry programista używa polskich nazw w programowaniu.

Sądzę, że każdy ma podobne rozterki do Twoich.

Pisząc prywatne projekty zawsze biorę pod uwagę "czystość kodu" do "czasu pracy".

Każdy ma jakieś wyobrażenie o tym jaki powinien być kod, a także każdy ma swoje nawyki. Wydaje mi się, że większość z nas ma lepsze wyobrażenie o swojej pracy, niż ona w rzeczywistości wygląda - a widać to najlepiej przy prywatnych projektach. ; )

Uczymy się wzorców, mówimy sobie, że testy i czystość kodu (znana książka "Czysty Kod") są ważne, ale gdy zaczynamy pracę nad jakimś projektem, to nie zawsze trzymamy się idealnie swoich teorii.

Ja osobiście ciągle podejmuję decyzje typu: "zostawić tutaj drobny bałaganik do posprzątania na później czy posprzątać już teraz?".

Najważniejsze to najpierw nauczyć się pokory - pamiętam doskonale czas, kiedy uczyłem się bardzo dużo nt. programowania, wzorców, czystego kodu, testowania. Sam siebie uważałem za wybitnego programistę.
Jednak podczas pewnego projektu śpieszyłem się z dostarczeniem pewnego oprogramowania. Po dwóch miesiącach pisania kodu nagle zdałem sobie sprawę, że złamałem prawie wszystkie zasady, w jakie głęboko
wierzyłem - dostrzegłem wtedy jaką byłem żałosną istotą... ; )

Pomyślałem sobie - Damianie, Ty tępy ch#&$^, uważasz się za tak dobrego programatora, a tutaj tworzysz takie g$%#$, że smród rozchodzi się po całości.

Pamiętam także jedną aplikację, dość dużą. Pisałem ją przez jakiś rok (prywatny projekt). Po długiej przerwie bylem zmuszony do pewnych modyfikacji, zajrzałem więc do starego kodu i...
ni cholery nie mogłem się połapać w jednej części kodu. Po prostu stworzyłem tak cholernie skomplikowany kawałek kodu, że musiałem przez prawie dwie godziny go analizować, aby połapać się
o co w nim chodziło.

Jaka jest moja rada? Nie ma kodu doskonałego. Goni nasz wszystkich czas. Nawet jeśli masz dobre zamiary, to często robisz małe grzeszki. Małe grzeszki nie są złe, o ile się nie rozrastają.

Ze swojej strony powiem tylko tyle, że wszystko zależy od nastroju i nastawienia.

Pisałem prywatne projekty, w których naprawdę działałem według swoich zasad, tj. pełne skupienie na "czystości" i "otestowaniu".
Wielbię Wujka Boba, więc tworzyłem soft otestowany w 90-kilku procentach. Siedziałem nad nim długo, starałem się go ciągle refaktoryzować, nawet gdy
niektóre rozwiązania zabierały dużo czasu. Widziałem tego efekty. Widziałem, że warto mieć testy.

Ale... nawet teraz po latach doświadczenia potrafię się śpieszyć i tworzyć oprogramowanie "na szybko", bez testów, z "małymi grzeszkami".

Ważne, aby mieć jakieś standardy.

Gdy łamię zasady, wtedy coś za uchem mówi mi "grzeszysz". Popełniam grzeszki. Ale mam jednak pewne "standardy grzeszenia".
Mogę pisać kod, który nie jest otestowany. Mogę czasem wprowadzić jakąś mała zawiłość. Ale jesli widzę, że coś staje się zbyt
skomplikowane, albo zbyt nieczytelne, wtedy włącza się alarm i wprowadzam porawki.

W końcu większość z nas wie jakie problemy wiążą się z nieczystym kodem. Doświadczyliśmy tego.
Wiemy co robić, aby nie kopać pod sobą dołków. Czasem grzeszymy. To normalne.

Ważne, aby mieć jakieś normy.

Zajrzy do baz danych takich programów jak optima lub xl od comarch-a, subiekt od insert-tu czy wf-mag od wapro.
W ich bazach nie znajdziesz słowa po angielsku, a nie ukrywajmy są to jedne z większych firm w Polsce.
Idąc Twoim tokiem rozumowania ich produkty które zarabiają pewnie niezłe melony to śmieci....
Ale to temat na nieco inną rozmowę

Chcesz mi wmówić, że stosowanie polskiego nazewnictwa jest okej?

Zarabianie oprogramowania, nie jest równe z tym, że jest dobrze napisane.
Strony na wordpressie też zarabiają

Omenomn
A Twoim gdzie niby stwierdzę, że mam wybrać te a nie inne rozwiązanie.


Nie, za to strategia już tak

Przyjrzyjmy się definicji:
Dekorator, pozwala na dynamicznie dodawanie nowych funkcjonalności do istniejących klas podczas działania programu.

Strategia, tworzy wspólny interfejs z dozwolonymi operacjami oraz listę klas implementujących dany interfejs dostarczających konkretne algorytmy.

Factory, dostarcza interfejs do tworzenia obiektów nieokreślonych typów, pozwala podklasom zdecydować, jakiego typu będzie obiekt

I powiedz mi gdzie tu pasuje Twój kod. Co z tego że udekorujesz sobie jakaś klasę jak nie stwierdzisz, że w tym konkretnym miejscu ona ma być tak udekorowana. Pomijając fakt, że zamieniłeś znaczenie modelu w Twoim rozwiązaniu, bo teraz dekorujesz obiekt własnościowi a to miał być podobno upload.

upload, a przed uploadem odpowiednio się plik, a teraz uwaga ------ dekoruje.



Własności też, nie tylko funkcjonalności.



Stwierdzę. Kontroler ma metodę przypisaną do routingu, więc jak wyślę coś postem na strona.com/image, to mam w kontrolerze metodę image(), w której wywołuję $image = new PropertyGeter(
new ContentImageGeter(
new ImageNoResizer(
new Encoder(
new FilePuter))));
$image->make($request->file);
i mam upload obrazu,

jak chcę obraz z jego miniaturką to strona.com/image-with-thumbnail, metoda imageWithThumbnail()
$image = new PropertyGeter(
new ContentImageGeter(
new ThumbnailResizer(
new Encoder(
new FilePuter))));
$image->make($request->file);

itd.

Nie potrzebuję wzorca decydującego o tym jaki plik ma zostać stworzony, bo doskonale wiadomo jaki.

http://stackoverflow.com/questions/1234554...e-re-sizing-etc

To nie moja definicja, ok własności tez mogą być. Ale nie to jest ważne a słowo nowe własności/funkcjonalności.

Spójrz na swój kod i co można tam zauważyć


$image = new PropertyGeter(
new ContentImageGeter(
new ImageNoResizer(
new Encoder(
new FilePuter))));


$image = new PropertyGeter(
new ContentImageGeter(
new ThumbnailResizer(
new Encoder(
new FilePuter))));

95% tego kodu to tak naprawdę spójny interfejs, który mógłby tworzyć jedna całość, a reszta to już tylko odpowiedni wybór ścieżki dla algorytmu.

No czyli masz jakaś strategie o niespójnym interfejsie do obsługi i daj to komuś żeby zrozumiał taki kod, a potem użył z nowym schematem bo klient wymyślił sobie że teraz nie 3 miniaturki a 4.

Załóżmy, że piszesz testy, jak taki kod przetestować skoro nie wiesz co tak naprawdę uzyskasz, bo w zależności od tego jak go wywołasz otrzymasz inny wynik, i co jeśli o czymś po drodze zapomnisz, bo dodałes nowe funkcjonalności i zamiast tych 5 dekoratorów masz już ich 20/30/100.

No to wtedy robi się nakładkę.



Co można zauważyć? że za każdym razem jest pobierana właśność do pliku i ustalany content, kodowanie i zapis?

Sprawdź sobie jak wygląda upload video z miniaturką:

[PHP] pobierz, plaintext 
$video = new PropertyGeter(
       new ThumbnailFromVideoCuter(
            new ContentGeter(
                    new FilePuter)));
$video->make($request->file);
[PHP] pobierz, plaintext 

lub samo video. czy inny plik:

[PHP] pobierz, plaintext 
$file = new PropertyGeter(
            new ContentGeter(
                    new FilePuter));
$file->make($request->file);
[PHP] pobierz, plaintext 

i jakie teraz własności kodu wywnioskowałeś?



Każdy framework tak ma, nie wiesz?