Kod doskonały vs rzeczywistość Opcje

[Pyton_000]

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.

[daro0]

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.

[Omenomn]

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.

Ten post edytował Omenomn 10.01.2017, 21:48:42

[Dejmien_85]

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.

[sazian]

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.

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ę

[Omenomn]

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ą

Ten post edytował Omenomn 10.01.2017, 22:49:31

[com]

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?

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

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

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.

[Omenomn]

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

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

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

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.

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

Ten post edytował Omenomn 10.01.2017, 23:15:07

[com]

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

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.

Stwierdzę. Kontroler ma metodę przypisaną do routingu, więc jak wyślę coś postem na strona.com/image

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.

Ten post edytował com 10.01.2017, 23:27:17

[Omenomn]

No to wtedy robi się nakładkę.

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

[PHP] pobierz, plaintext 
$image = new PropertyGeter(
new ContentImageGeter(
new ImageNoResizer(
new Encoder(
new FilePuter))));
 
 
$image = new PropertyGeter(
new ContentImageGeter(
new ThumbnailResizer(
new Encoder(
new FilePuter))));
[PHP] pobierz, plaintext 

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ś?

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.

Każdy framework tak ma, nie wiesz?

Ten post edytował Omenomn 10.01.2017, 23:40:04

[com]

No dokładnie te same dla tej grupy wideo, tak samo będzie dla audio i czego sobie tam jeszcze nie wymyślisz.

Każda grupa to jakiś schemat, który dodatkowo rozbudowujesz i zależnie od tego jak skomponujesz te obiekty taki uzyskasz context, ale dla każdej operacji będzie on inny choć operujesz dalej na tym samym obiekcie, wiec oczekujesz dostać ten obiekt, a nie cokolwiek.

Każdy framework tak ma, nie wiesz?

Wskaż mi gdzie framework ma coś nie udokumentowane i nie wiesz co uzyskasz jak wykonasz dany fragment jego kodu.

To trochę tak jakbyś z kota chciał zrobić mysz

To jak się uparłeś już na te twoje "dekoratory" to zrób chociaż Fasade, żeby to można było produktywnie wykorzystać. Tylko to jest trochę bez sensu.

Bo ile teraz ktoś kto chce dodać głupi obrazek musi pamiętać, żeby taki plik dodać. A wzorce maja dawać te możliwość, że jedno rozwiązanie możesz wprost wyjąc z tego projektu i dodać do innego i tam też będzie działać i teraz zamiast kod się sam dokumentować, piszesz how to use.

Dekorator jest rozwiązaniem które można tu zastosować ale tak jak już zostało napisane:

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

czy jak na tym stacku który podrzucałeś:

[PHP] pobierz, plaintext 
process = new Upload(myImage);  // concrete component
process = new Resize(process);  // decorator
process = new Clip(process);    // decorator
process->run();  
[PHP] pobierz, plaintext 

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.

Tak:

http://blogophp.com/2009/08/16/dekorator/#more-40

Pierwsze co powinno To Cie właśnie zastanowić, że coś jest tutaj nie tak, skoro tak nie jest. Jak już używamy wzorców to trzeba ich używać dobrze, bo inaczej zamiast kod rozjaśnić zaciemniamy go.

Podsumowując, właściwości nie powinny wędrować miedzy dekoratorami, bo wtedy już to nie jest dekorator! Dekorujesz konkrety obiekt bazę która rozszerzasz, a nie budujesz nad obiektem bazy nowego obiektu do rozszerzeń. Każdy dekorator to niezależny byt, który możesz wywołać bezpośrednio na obiekcie bazowym zawsze i nie potrzebujesz do tego więcej dekoratorów po drodze.

To:

[PHP] pobierz, plaintext 
$video = new PropertyGeter(
       new ThumbnailFromVideoCuter(
            new ContentGeter(
                    new FilePuter)));
 
[PHP] pobierz, plaintext 

i to:

[PHP] pobierz, plaintext 
$video = new ThumbnailFromVideoCuter(
 new PropertyGeter(       
            new ContentGeter(
                    new FilePuter)));
 
[PHP] pobierz, plaintext 

Ma dać ten sam efekt, daje, zapewne nie bo ThumbnailFromVideoCuter() zależy pewnie od obiektu PropertyGeter(), skoro potrzebny był Ci obserwator.

Ten post edytował com 11.01.2017, 00:52:22

[Omenomn]

Wskaż mi gdzie framework ma coś nie udokumentowane i nie wiesz co uzyskasz jak wykonasz dany fragment jego kodu.

To trochę tak jakbyś z kota chciał zrobić mysz

Mówię o routingu. Dziwnie Cię zdziwiło, że są metody przypisane do konkretnej akcji z urla.

Podsumowując, właściwości nie powinny wędrować miedzy dekoratorami, bo wtedy już to nie jest dekorator! Dekorujesz konkrety obiekt bazę która rozszerzasz, a nie budujesz nad obiektem bazy nowego obiektu do rozszerzeń. Każdy dekorator to niezależny byt, który możesz wywołać bezpośrednio na obiekcie bazowym zawsze i nie potrzebujesz do tego więcej dekoratorów po drodze.

Miedzy dokoratorami będę przekazywał obiekt, w którym będzie się znajdował kontent pliku plus inne atrybuty, które można modyfikować, a nie jak do tej pory sam kontent. Dlatego musiałem rozwiązać problem przekazywania właściwości, ale z obiektem będzie prościej o wiele.

To:

[PHP] pobierz, plaintext 
$video = new PropertyGeter(
       new ThumbnailFromVideoCuter(
            new ContentGeter(
                    new FilePuter)));
[PHP] pobierz, plaintext 

i to:

[PHP] pobierz, plaintext 
$video = new ThumbnailFromVideoCuter(
 new PropertyGeter(       
            new ContentGeter(
                    new FilePuter)));
[PHP] pobierz, plaintext 

Ma dać ten sam efekt, daje, zapewne nie bo ThumbnailFromVideoCuter() zależy pewnie od obiektu PropertyGeter(), skoro potrzebny był Ci obserwator.

Nieprawda, znajdź mi informację, że w dekoratorze kolejność dekoratorów ma nie mieć znaczenia.
Choćby zawsze musi istnieć końcowy dekorator, który nie przyjmuje wartości do konstrukora, więc jeżeli musi istnieć końcowy, to może istnieć początkowy i może istnieć ustalona kolejność.

[daro0]

Prawda jest taka, że gdybym miał się tak zastanawiać nad tym wszystkim to bym nigdy nie skończył w terminie żadnego projektu a wymagania są określone przez klienta. Owszem czasem trzeba coś dodać, coś nie było przewidziane, jednak na ogół nie jest to problemem. Tak na szybko (pierwsze co mi przychodzi na myśl). Zakładam że jest formularz typu Multipart/Formdata w widoku a w nim daje się jakiś opis w pole tekstowe, jest pole do wybierania obrazka do uploadu oraz opcja checkbox, czy ma być miniaturka czy też nie a rozmiary są określone w konfiguracji frameworka.

application/classes/Request.php

[PHP] pobierz, plaintext 
    <?php defined('SYSPATH') OR die('No direct script access.');
 
    class Request extends Kohana_Request
    {
         public function files($key = NULL)
         {
             if ($key === NULL)
      	     {
    	         return $_FILES;
    	     }
    	     else
    	     {
    	         return Arr::path($_FILES, $key);
    	     }
         }
    }
 
[PHP] pobierz, plaintext 

i metoda kontrolera

[PHP] pobierz, plaintext 
    public function action_upload()
    {
        if ($this->request->method() == HTTP_Request::POST)
        {
            if ($this->request->files('attachment'))
            {
                $config = Kohana::$config->load('app.uploads.images');
                $options = array(
                    'image' => array(
                        'width' => Arr::path($config, 'image.width'),
                        'height' => Arr::path($config, 'image.height'),
                    ),
                    'thumbnail' => array(
                        'width' => Arr::path($config, 'thumbnail.width'),
                        'height' => Arr::path($config, 'thumbnail.height'),
                    ),
                   'use_thumbnail' => $this->request->post('chk_use_thumbnail') ? TRUE : FALSE,
                );
 
                $result = Uploader::factory('Image')
                    ->options($options)
                    ->data($this->request->files('attachment'))
                    ->execute();
            }
        }
        // do something
    }
[PHP] pobierz, plaintext 

To jest tylko jedno z możliwych podejść. Tutaj to czy jest miniaturka czy nie to jest określone na podstawie tego co zwraca $_POST a ten helper musiałby na podstawie tego wykonywać pewne operacje. Zakładam użycie helperów Image oraz Upload z tego frameworka.

Nie wiem jak by to wyglądało w Laravelu a już tym bardziej gdyby pisać całkowicie od zera.

Ten post edytował daro0 11.01.2017, 09:51:16

[Omenomn]

Jak się poświęci więcej czasu przy jednym projekcie na dobre rozwiązanie problemu, to później tego rozwiązania można używać w kolejnych, i czas wykonania skraca się o wiele.
Piszą o tym w książkach o wzorcach i dobrych praktykach.
Problem jest rozwiązany i działa meeega!!
Teraz mam bibliotekę rozszerzalną na miliony sposobów, gotową do użycia w innych projektach.

[ohm]

Teraz mam bibliotekę rozszerzalną na miliony sposobów, gotową do użycia w innych projektach.

Tylko pytanie czy inni też będą wiedzieli jak tę bibliotekę szybko i łatwo użyć?

[nospor]

Tylko pytanie czy inni też będą wiedzieli jak tę bibliotekę szybko i łatwo użyć?

Soryy, ale nie bede sobie "nieulatwial" pracy tylko dlatego ze ktos moze kiedys nie wiedziec jak tego uzyc... Ja tez mam wlasne liby w Symfony ktore generalizuje mi rozne rzeczy, np Grid, edycja, usuwanie, w sume caly CRUD. Na napisanie tego poswiecilem chwilke czasu ale teraz kazdy kolejny CRUD to 15 minut robotyi wiem ze wszystko bedzie dzialac tak samo.

Wracajac do twojego pytania:
Po pierwsze, skoro klasa byla uzywana w projekcie, to sa przyklady uzycia
Po drugie, zazwyczaj jak potrzeba pisze sie komentarz.

[Omenomn]

Zgadzam się z nospor

[com]

Mówię o routingu. Dziwnie Cię zdziwiło, że są metody przypisane do konkretnej akcji z urla.

Nie napisałem że coś w tym dziwnego, napisałem, że masz tu strategie o której ja i inni mówiliśmy.

Nieprawda, znajdź mi informację, że w dekoratorze kolejność dekoratorów ma nie mieć znaczenia.
Choćby zawsze musi istnieć końcowy dekorator, który nie przyjmuje wartości do konstrukora, więc jeżeli musi istnieć końcowy, to może istnieć początkowy i może istnieć ustalona kolejność.

Wgl nie zrozumiałeś dekoratorów.

Jedyne co musi istnieć to klasa która rozszerzasz, ona ma jakaś funkcjonalność w Twoim przypadku bazą jest Upload. I kiedy podczas tego uploadu zależy Ci żeby powstała miniaturka, wiec dodajesz do istniejącego obiektu Uploadu zrób mi miniaturkę. Dlatego tworzysz dekorator, którego jedynym zadaniem jest zmienić obiekt bazowy tak żeby zamiast pełnego obrazu zwrócona została miniaturka w jego miejscu.
Dla innego route chcesz miniaturkę obrócona o 180 stopni. Wiec bierzesz klase Upload bierzesz dekorator Thumbnail i dekorator Rotate i masz miniaturkę i obrócony. Ale nie ma znaczenia czy najpierw obrócisz potem zmniejszysz czy na odwrót i tak i tak efekt zawsze jest taki sam i tak powinno być u Ciebie, a tak nie jest bo u Ciebie każda klasa zależy od innej. W przypadku prawdziwego dekoratora nadawane ograniczenia/zmiany na obiekcie są od siebie nie zależne, wiec mogę mięć: miniaturkę; miniaturkę i obrócony == obrócony i miniaturka; obrócony, a wszystko to bez jakiejkolwiek zmiany w kodzie. Twoje początkowe założenie było blednę, czyli:

Choćby zawsze musi istnieć końcowy dekorator

Nie ma czegoś takiego jak początkowy czy końcowy dekorator, jest obiekt który dekorujesz i jeśli dekoratory maja ten sam interface co ten obiekt, to można je ze sobą składać tak jak było opisane w przykładach, ale tylko i wyłącznie wtedy.

Soryy, ale nie bede sobie "nieulatwial" pracy tylko dlatego ze ktos moze kiedys nie wiedziec jak tego uzyc...

Tu wcale nie chodzi o nie ułatwianie pracy, bo po to zaproponowane zostało użycie wzorców, żeby te rozwiązanie było jak najbardziej elastyczne i można było wykorzystać je w wielu projektach, ale wzorce zostały zdefiniowane w taki sposób, żeby każdy kto sporzy na kod, znając je wie jaki będzie efekt. A kiedy kolega Omenomn po roku czy dwóch latach wróci do tego kodu coś zmienić, najpierw znów będzie musiał wdrożyć sam siebie jak to działa i czemu tak to zrobiłem wtedy a nie inaczej.

Przeczytaj jeszcze raz uważnie co tam zostało napisane
http://blogophp.com/2009/08/16/dekorator/#more-40
Najistotniejsze fragmenty

// obiekty tej klasy beda dekorowane
class SimpleText extends Information

Proszę zwrócić uwagę na fakt, iż gdy obiekt dekorowany jest tego samego typu co dekoratory jesteśmy w stanie ?dekorować? również dekoratory

obiekt dekorowany !== dekorator i nie możesz go nazwać dekoratorem końcowym.

Pomijając już sam fakt, że tak jak tam było:
new FirstLetter(new TextLength(new SimpleText()));
Dekoratory idą od środka w górę, a u Ciebie odnoszę wrażenie, że idziesz od początku w dół, przynajmniej tak wynikało z pierwszego opisu.

Trochę wracając jeszcze do tematu frameworka i jego roli, o czym mówiliśmy wcześniej to przykład od olx:


Ten post edytował com 11.01.2017, 19:27:12

[solificati]

Nieprawda, znajdź mi informację, że w dekoratorze kolejność dekoratorów ma nie mieć znaczenia.
Choćby zawsze musi istnieć końcowy dekorator, który nie przyjmuje wartości do konstrukora, więc jeżeli musi istnieć końcowy, to może istnieć początkowy i może istnieć ustalona kolejność.

Principle of least astonishment jak to się w kulturze OOP nazywa. Gdy kolejność ma znaczenie to wprowadzasz składnię a to się liczy conajmniej jako "zaskoczenie".

Precyzując, Dekorator implementuje ten sam interfejs, który implementuje obiekt który jest dekorowany. Żeby dekorator mógł korzystać z pól dodanych przez inny dekorator, musisz wprowadzić drugie drzewo dekoratorów bazujące na poszerzonym interface albo ich produkcie.

Ten post edytował solificati 11.01.2017, 15:34:27

[daro0]

Jeszcze rok albo dwa lata temu przy wcześniejszych projektach to też myślałem że to co wtedy pisałem jest super. Jakże się myliłem, bo teraz jak na to popatrzę to aż szlak trafia bo można było to napisać inaczej. Ale dalej. Weźmy np. nie uploader ale StaticServer

[PHP] pobierz, plaintext 
class Controller_Image extends Controller
{
 
    public function action_serve()
    {
        $image = Image::factory(DOCROOT . '/test.jpg');
 
        $size = $this->request->query('size');
        $rotate = $this->request->query('rotate');
        $sharp = $this->request->query('sharp');
        $quality = $this->request->query('quality');
 
        if ($size)
        {
            $width = $image->width;
            $height = $image->height;
            $image->resize($width * $size / 100, $height * $size / 100);
        }
 
        if ($rotate)
        {
            $image->rotate($rotate);
        }
 
        if ($sharp)
        {
            $image->sharpen($sharp);
        }
 
        if ($quality)
        {
            $image = $image->render('jpg', $quality);
        }
 
        $this->response->headers('Cache-Control', 'max-age=3600, public');
        $this->response->headers('Content-Type', 'image/jpg');
        $this->response->body($image);
    }
 
}
[PHP] pobierz, plaintext 

I tak:

http://localhost/image/serve - wyświetla oryginalny obrazek JPG który wczyta
http://localhost/image/serve?size=50 - wyświetla obrazek w rozmiarach 50% oryginału
http://localhost/image/serve?size=50&sharp=100 - to samo ale wyostrzone
http://localhost/image/serve?quality=10 - jakość JPG 10%
http://localhost/image/serve?rotate=90 - obraza o 90 stopni w prawo

Domyślnie metoda __toString() wywołuje na render() w tym module.

I teraz jest pytanie, co w takim przypadku daje zastosowanie dekoratora (bo też można by to zrobić) vs. to podejście jakie jest tu?