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.



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:


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 

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.

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



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.



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ść.

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.

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.

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.

Zgadzam się z nospor

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



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:

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.


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



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:

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.

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?

daro0 seriooo? Ten kod jest naprawdę kiepski...
to podejście jest nawet gorsze od tego, które chciałem poprawić.

com

przykładowy dekorator

[PHP] pobierz, plaintext 
$decorator = new Decorator( new Decorator1( new Decorator2( new Decorator3);
$decorator->make($decorationObject);
[PHP] pobierz, plaintext 

Widzisz, że Decorator3 nie przyjmuje obiektu?
Chcesz mi tłumaczyć coś, czego sam nie kumasz i jeszcze wmawiasz mi, że tego nie rozumiem.

@Omenomn weź w końcu przeczytaj co to jest Decorator i przestań się upierać przy czymś o czym nie masz pojęcia bo aż szkoda.

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



Cytat z linku, widzisz, żeby SimpleText przyjmowała obiekt? Więc chyba musi być ostatnia, no nie??
Proste jak konstrukcja cepa.
Najwyraźniej nie dla wszystkich.

SimpleText nie jest ostatnim a pierwszym. Na dodatek nie jest dekoratorem a Obiektem bazowym który jest DEKOROWANY a NIE jest DEKORATOREM.

Omenomn Specjalnie Ci już podkreśliłem fragmenty z tego bloga, ale zamiast przeczytać ze zrozumieniem uparłeś się na swoje rozwiązanie. Przeczytaj jeszcze raz co ja napisałem i co napisał Pyton_000 i można zakończyć te dyskusję.

Ostatecznie dekoratory bez klasy bazowej nie istnieją bo nie maja co dekorować, dlatego zawsze musi być jakaś baza tak jak tam jest to SimpleText, który nie jest dekoratorem, nim są dopiero TextLength oraz FirstLetter. Źle przeczytałeś i potem dobudowałeś sobie do tego teorie, zdarza się SimpleText możesz zawsze wywołać wgl bez dekoratorów i spełni swoje podstawowe zadanie, dekoratora nie da się bo nie będzie klasy która dekoruje i tyle.

[PHP] pobierz, plaintext 
$obj = new Decorator( new Decorator1( new Decorator2( new ObjectToDecorate);
$obj->make($object);
[PHP] pobierz, plaintext 

Tak miał wyglądać Twój kod dla Twojego przykładu

Okej, teraz widzę, że w tych tutorialach oni ostatni dekorator przekazują jako obiekt do dekorowania.

Jednak klasa SimpleText musi implementować interfejs dekoratora, wymagany w konstruktorze dekoratora TextLength, więc jeśli implementuje interfejs dekoratora to też nim jest, według mojego rozumowania.

Pierwszy dekorator jaki wywołuje metodę write() to FirstLetter, więc jest pierwszy, a ostatnia wywołana metoda jest z SimpleText.

[PHP] pobierz, plaintext 
$obj = new Decorator( new Decorator1( new Decorator2( new ObjectToDecorate);
$obj->make($object);
[PHP] pobierz, plaintext 

Co przekazujesz w tym kodzie do zmiennej $object? Nie widzisz tu błędu logicznego?

Teorycznie metoda make() może nie przyjmować parametru i wtedy pracujesz na sztywnych danych z ObjectToDecorate(), ale według mnie lepiej jest przekazać do metody make($object), obiekt do obróbki a klasę ObjectToDecorate (w tym przypadku nazwa błędna) potraktować jako ostatni krok obróbki obiektu $object.

Takie podejście wydaje mi się o wiele sensowniejsze.

Po za tym co to ma do rzeczy, że jest w dekoratorze ustalona kolejność. Może być tak, że któryś z dekoratorów zmieni dane, które otrzymał w taki sposób, że dekorator przed nim nie byłby w stanie ich obsłużyć, jeśli wystąpi po nim.

Wymyślanie problemów tam gdzie ich nie ma.

Omenomn
Tym razem nie Kohana i nie wiem czy jest to do końca poprawnie ale podczas pisania tego kodu myślałem że zwariuję! Dosłownie.

[PHP] pobierz, plaintext 
<?php
 
define('DOCROOT', realpath(dirname(__FILE__)).DIRECTORY_SEPARATOR);
 
interface IDecoratedImage
{
    public function render();
}
 
class Driver
{
    protected $file;
    protected $resource;
 
    public function __construct($file)
    {
        $this->file = $file;
        $this->resource = imagecreatefromjpeg($this->file->getRealPath());
    }
 
    public function __destruct()
    {
        imagedestroy($this->resource);
    }
 
    public function getResource()
    {
        return $this->resource;
    }
}
 
class Image implements IdecoratedImage
{
    protected $driver;
    protected $resource;
 
    public function __construct($driver)
    {
        $this->driver = $driver;
        $this->resource = $this->driver->getResource();
    }
 
    public function render()
    {
        imagejpeg($this->resource);
    }
 
    public function getResource()
    {
        return $this->resource;
    }
}
 
class GrayscaleImage implements IDecoratedImage
{
    protected $image;
 
    public function __construct($image)
    {
        $this->image = $image;
    }
 
    public function render()
    {
        $resource = $this->image->getResource();
        imagefilter($resource, IMG_FILTER_GRAYSCALE);
        imagejpeg($resource);
    }
 
    public function getResource()
    {
        return $this->resource;
    }
 
}
 
class NegateImage implements IDecoratedImage
{
    protected $image;
 
    public function __construct($image)
    {
        $this->image = $image;
    }
 
    public function render()
    {
        $resource = $this->image->getResource();
        imagefilter($resource, IMG_FILTER_NEGATE);
        imagejpeg($resource);
    }
}
 
 
header('Cache-Control: max-age=3600, public');
header('Content-Type: image/jpeg');
 
$path = DOCROOT . 'test.jpg';
 
// Display original image
//$image = new Image(new Driver(new SplFileInfo($path)));
 
// Display decorated grayscale image
//$image = new GrayscaleImage(new Image(new Driver(new SplFileInfo($path))));
 
// Display decorated negative image
$image = new NegateImage(new Image(new Driver(new SplFileInfo($path))));
$image->render();
[PHP] pobierz, plaintext 

Też chodzi o ładowanie JPEG oraz przy użyciu jak (poprawnie?) myślę dekorowania bazowego Image tak żeby uzyskać efekty w odcieniach szarości albo nagatywu obrazu. W takim razie odpowiedz mi na pytanie: po co tyle zabawy?? Mam jeszcze dekorować ten udekorowany obiekt w ten sposób:

[PHP] pobierz, plaintext 
$image = new GrayscaleImage(new NegateImage(new Image(new Driver(new SplFileInfo($path)))));
$image->render();
[PHP] pobierz, plaintext 

A co z dodatkowymi opcjami? Albo jeszcze takie coś:

[PHP] pobierz, plaintext 
$image = new SharpenImage(new GrayscaleImage(new NegateImage(new Image(new Driver(new SplFileInfo($path))))));
$image->render();
[PHP] pobierz, plaintext 

vs. to:

[PHP] pobierz, plaintext 
$image = Image::factory(DOCROOT . 'test.jpg')
    ->grayscale()
    ->negate()
    ->sharpen()
    ->render();
[PHP] pobierz, plaintext 

Co też moim zdaniem można zrobić bardzo prosto w tylko jednej klasie operując na resource i tych wbudowanych funkcjach z modułu GD.

single responsibility principle - słyszał?

Wydaje mi się, że o wiele gorzej z dodawaniem kolejnych funkcji przy takim rozwiązaniu, bo w końcu klasa może urosnąć do gigantycznych rozmiarów z ogromną ilością metod, a właśnie ten problem chciałem wyeliminować.
Trzeba pamiętać o tym, że to ma obsługiwać różne pliki, nie tylko obrazy, ale też wideo.

Czyli właśnie zasada jednej odpowiedzialności jest tu wykluczona, bo jeśli jeszcze można by ją odnieść do obrazu, to nie odniesie się tego do uploadu filmu z wygenerowaniem trzech miniaturek.

Po za tym istnieje taka klasa do obróbki obrazów jaką przedstawiasz daro0:
http://image.intervention.io/

i Ja ją wykorzystuję właśnie w moim dekoratorze.

@Omenomn

Męczysz się chłopak niemiłosiernie. Przeczytaj i przeanalizuj to, co jest napisane w Czystym Kodzie + SOLID. Sam kiedyś tak kombinowałem jak Ty. Tak jak ktoś już wcześniej napisał - uzbrój się w pokorę, przeczytaj, i zastanów się nad sensem tego, co tam jest napisane. Nie bez powodu jest to best seller.

Przeczytam na pewno.

Ps.
Nie męczę się, bo już to jest gotowe i dobrze działa.

Tak sobie ogólnie pomyślałem teraz, że tak jak backend tworzy się pod frontend, tak bebechy bibliotek do obsługi jakichś zadań powinno się tworzyć pod sposób ich wywoływania. Czyli najpierw zastanowić się trzeba jak chce się korzystać z danej biblioteki, jak ją wywoływać, a później dopiero tworzyć jej wnętrze.

Dalsza dyskusja nie ma sensu wiec na tym poście zakończę.

No bo taka jest definicja dekoratora. Masz obiekt do dekorowania który istniej zanim wgl ktokolwiek pomyśli o tym żeby stworzyć dekorator i masz dekoratory które dodają nowe funkcjonalności do klasy nie modyfikując jej.


Co za bzdury gadasz, to nie klasa która dekorujesz musi implementować interfejs dekoratora, a dekoratory interfejsy klasy która dekorują. Czyli zupełnie na odwrót.



Pracując na sztywnych danych jaki miałby sens dekorować klasę, skoro bez jej modyfikacji niczego nie jesteś wstanie zmienić. Podstawowym zadaniem które da się tu zrobić jest wykonanie takiego kodu:

[PHP] pobierz, plaintext 
$obj = new ObjectToDecorate();
$obj->make($object);
[PHP] pobierz, plaintext 

Nie potrzebuje mieć ani jednego dekoratora, żeby taki kod wywołać, bo on dostarcza to co daje mi interfejs.

To co Ty stworzyłeś nie można nazwać po prostu dekoratorem. Stworzyłeś własna implementacje jako rozwiązanie dla tego problem, bo to co Ty masz nawet obok dekoratora nie stało.

Tylko te rozwiązanie ma dwa podstawowe problemy, nie jest testowalne i skalowalne. Wraz z każdym dekoratorem wzrasta złożoność tego rozwiązania i uzależnienie jednego obiektu od drugiego.

Ale jedno muszę Ci przyznać wykazałeś się pomysłowością w wymyślaniu "koła" na nowo, bo otrzymałeś coś co w programowaniu istnieje od dawna pod nazwą dziedziczenie, tylko zamiast zrobić to tradycyjnie, stworzyłeś implementacje poprzez składanie obiektów.

i tak głównie chodzi o warstwowe nakładanie klas new Class(new Class1( new Class2( itd.)))

To, czy Class2 traktujesz jako obiekt dekorowany, czy ostatni dekorator nie ma takiego znaczenia.



To nie jest dziedziczenie tylko przypisanie, co czyni ogromną różnicę.



Jest testowalne. Przetestowałem, działa, chociaż jest dość zawiłe w implementacj, jeszcze nad tym popracuję



Chodziło mi o to, że mają ten sam interfejs.

Widzę, że wszędzie piszą tak jak Ty tutaj, rzuciłem okiem na ten wzorzec i jakoś mi umknęło to, że ostatni obiekt ma być traktowany jako obiekt dekorowany, bo sensowniejsze dla mnie jest podejście, że obiekt dekorowany to ten który przekazujesz do make, jakoś tak podświadomie to potraktowałem:

[PHP] pobierz, plaintext 
$obj = new ObjectToDecorate();
$obj->make($object);
[PHP] pobierz, plaintext 

bo załóżmy przekazujemy tablicę $array do make($array)

[PHP] pobierz, plaintext 
$array = [
'name' => 'plik.jpg',
'extension' => 'jpg',
'height' => 200,
'width' => 300,
]
$obj = new ObjectToDecorate();
$obj->make($array)
[PHP] pobierz, plaintext 

i teraz ObjectToDecorate może zmienić nazwę pliku, rozszerzenie i rozmiar, więc modyfikuje tablicę (dekoruje), która jest w tym momencie obiektem dekorowanym/modyfikowanym.

Dalsza dyskusja na temat dekoratora nie ma sensu naprawdę, bo rozumiem Twoje podejście, jednak niekoniecznie się z nim zgadzam.

Ponieważ zaczynasz bardziej sensownie pisać to jeszcze na to Ci odpowiem



Ma ogromne znaczenie, bo u Ciebie nie da się nawet wyciągnąć podstawowej funkcjonalności, może poza propertisami pliku ale to podobno ma być upload. To gdzie jest ten wspólny interfejs


W programowaniu obiektowym mocno upraszczając obiekty, mogą albo po sobie dziedziczyć, albo może nastąpić ich kompozycja. Ty zrobiłeś kompozycje, ale ponieważ wszystkie te twoje klasy dziedziczą po tym samym interfejsie to zasadniczo zrobiłeś ich rozszerzenie wiec defakto uzyskałeś to samo jakby zrobić :
Class : Class1 : Class2, efekt masz dokładnie identyczny, z tym że dla takiego podejścia bez problemu napiszesz testy automatyczne, dla Twojego już niekoniecznie.
Bo to co ty zrobiłeś:


czyli test zero jedynkowy, działa nie działa to żaden dowód, że to zawsze tak będzie działać jakby się tego oczekiwało.



ten obiekt który przekazujesz do make nie jest wgl z żadna z klas związany, to jest po prostu model na którym operujesz. Ani dekoratory ani klasa która dekorujesz wgl nie musza istnieć, żeby istniał ten objekt, a to może być cokolwiek.



Nadal nie rozumiesz co to jest dekorator, ten obiekt to model danych, jaki, taki jaki sobie wymarzysz. On wgl nie ma związku ze wzorcem dekorator.


No właśnie nie rozumiesz, uwierz, że gdybyś stworzył dekorator nie potrzebowałbyś obserwatora który śledzi zmiany w poszczególnych klasach.

Ja tego podejścia nie wymyśliłem, ja po prostu tłumacze Ci jak działa dekorator. Dekorator ma jedna jedyna definicje i jest to najprostszy z możliwych wzorców, ale jak się go nie zrozumie to wychodzi taki problem, że można uzyskać coś zupełnie innego.

a wystarczyło napisać to tak z użyciem dekoratorów skoro tak bardzo to chciałeś zrobić:

[PHP] pobierz, plaintext 
$obj = new Thumbnail(new Upload());
$obj->make($model);
[PHP] pobierz, plaintext 

No i które rozwiązanie jest bardziej akceptowalne te czy te:

[PHP] pobierz, plaintext 
$image = new PropertyGeter(
new ContentImageGeter(
new ImageNoResizer(
new Encoder(
new FilePuter))));
$image->make($request->file); 
[PHP] pobierz, plaintext 

Wgl spójrz ile zależności i klas potrzebujesz żeby stworzyć cokolwiek.

Chcesz mieć rożne typy obsłużone, proszę bardzo:

[PHP] pobierz, plaintext 
$obj0 = new Thumbnail(new Upload());
$obj0->make($model0);
 
$obj = new Thumbnail(new ImageUpload());
$obj->make($model);
 
$obj1 = new Thumbnail(new VideoUpload());
$obj1->make($model1);
 
...
[PHP] pobierz, plaintext 

Wiec nie:

[PHP] pobierz, plaintext 
- 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); 
[PHP] pobierz, plaintext 

A :

[PHP] pobierz, plaintext 
- zwykły obraz: 
$obj = new ImageUpload(); // objekt który może zostać udekorowany lub nie 
$obj->upload($request->file);
- miniaturka: 
$obj = new Thumbnail(new ImageUpload());
$obj->upload($request->file);
- video:
$obj1 = new VideoUpload(); // objekt który może zostać udekorowany lub nie 
$obj1->upload($request->file);
- video z miniaturką:
$obj1 = new Thumbnail(new VideoUpload());
$obj1->upload($request->file);
- video z trzema miniaturkami:
$obj1 = new ThreeThumbnails(new VideoUpload());
$obj1->upload($request->file);
[PHP] pobierz, plaintext 

Chcesz mieć jakiś Encoder, nie ma problemu

[PHP] pobierz, plaintext 
- zwykły obraz: 
$encoder = new DummyEncoder();
$obj = new ImageUpload($encoder); // objekt Encoder wstrzykiwany jako zależność czyli DI
$obj->upload($request->file);
[PHP] pobierz, plaintext 

Napisałeś praktycznie to samo co Ja, z tym, że u mnie jest rozbite na więcej mniejszych kroków...

Zdecyduj się, czy klasa ImageUpload pobiera parametr do konstruktora czy nie.

[PHP] pobierz, plaintext 
$obj = new ImageUpload(); // objekt który może zostać udekorowany lub nie 
$obj->upload($request->file);
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
$encoder = new DummyEncoder();
$obj = new ImageUpload($encoder); // objekt Encoder wstrzykiwany jako zależność czyli DI
$obj->upload($request->file);
[PHP] pobierz, plaintext 

Poniżej jest pomniejszanie obrazu, czy generowanie obrazu z miniaturką?

[PHP] pobierz, plaintext 
$obj = new Thumbnail(new ImageUpload());
$obj->upload($request->file);
[PHP] pobierz, plaintext 

Jak pobierzesz w Thumbnail informacje o pliku, skoro ImageUpload to klasa bazowa, która za pewne pobiera te dane?
Chcesz w każdej klasie pobierać dane o pliku?

Moje rozwiązanie startuje od klasy PropertyGet, żeby pobrało informacje o pliku raz, a później na nich bazowało.
Gdzie pobierasz kontent pliku, gdzie go enkodujesz, jak chciałbyś zrobić zmianę nazwy?

Taki uproszczony schemat to Ja też mogłem napisać w poście, ale jest bezużyteczny.

No właśnie, że nie bo ja nie potrzebuje u mnie nic więcej poza klasa bazowa i jej interfejsem, żeby stworzyć dowolny dekorator teraz.



To nie ma znaczenia, jeśli potrzebujesz dodatkowe zależności to je dodajesz, co pokazałem, ale do tego jest inny wzorzec.



Generowanie miniaturki, ale wystarczy zmienić ten dekorator na inny i masz inne zadanie.



Ale do czego Ci są potrzebne te dane? Zrobienie miniaturki nie wymaga niczego więcej jak tylko pliku na którym ma zostać to wygenerowane.



To nie jest uproszczony schemat tylko pełna funkcjonalność taka sama jak u Ciebie.

Implementacja:

[PHP] pobierz, plaintext 
class ImageUpload : UploadInterface
{
      private $encoder;
      private $renamer;     
 
      public function __construct (EncoderInterface $encoder, RenamerInterface $renamer) 
      {
            $this->encoder = $encoder;
            $this->renamer = $renamer;
      }
 
      public function upload($file)
      {
              // tutaj jakieś operacje na pliku typu enkodowanie, zmiany nazwy itd
              (...)  
 
              return $encodedAndRenamedAndEtcFile;
       }
}
 
class GenerateWithThumbnail : UploadInterface
{
      private $base;
 
      public function __construct (UpoladInterface $upload) 
      {
	     $this->base = $upload;
      }
 
      public function upload($file)
      {
              // tutaj wygenerowanie miniaturki
              (...)  
 
             $this->base->upload($fileWithThumbnail);
       }
}
 
// Wywołanie 
$encoder = new DummyEncoder();
$renamer = new DummyRenamer();
$obj = new GenerateWithThumbnail(new ImageUpload($encoder, $renamer));
$obj->upload($request->file);
 
[PHP] pobierz, plaintext 

Ok nazwa była zła zmienię na GenerateWithThumbnail

To co zrobiłeś jest sztywne i kompletnie nie rozszerzalne, chyba, że za każdym razem jak chcę coś dodać, będę musiał modyfikować konstruktor klasy ImageUpload i jej metodę upload() co jest bez sensu, dodatkowo wtedy musiałbym modyfikować kod wszędzie tam gdzie ta klasa jest używana.



Wegenerowanie pliku wymaga:
- nazwy pliku,
- ścieżki
- kontentu wygenerowanego ze ścieżki
- ścieżki na którą ma zostać zapisany.

Wszystkie te dane należy wyciągnąć z pliku, żeby go przesłać, oprócz ścieżki do zapisu.

Jeżeli ImageUpload pobiera te dane, to w jaki sposób dostanie je GenerateWithThumbnail, żeby mogło zmodyfikować plik i w jaki sposób prześle zmodyfikowany plik do ImageUpload. Pliku z requesta nie da się modyfikować, można co najwyżej zapisać zmodyfikowane dane o pliku i przesłać je dalej do obróbki, więc tak czy siak format przesyłanych danych się zmienia, a klasa bazowa ImageUpload musi je przyjąć.



Jeżeli te dane wyciągniesz z file w ImageUpload to w jaki sposób dostanie je GenerateWithThumbnail i w jaki sposób encoder i renamer przekaże dane do GenerateWithThumbnail ze zmienioną nazwą i zmienionym rozszerzeniu.
Najpierw powinna zostać wygenerowana miniatruka później plik bazowy, bo co jeśli chcę po prostu pomniejszyć plik, a nie generować dwóch? Najpierw muszę go pomniejszyć, a później wygenerować.

Natomiast jeżeli masz podstawową kompozycję z trzech klas:



to wtedy bez problemowo można tworzyć nakładki bez jakichkolwiek modyfikacji wnętrzna klas już istniejących, przykładowo:


lub


w ten sposób bazę trzech klas można rozszerzać jak się chce, trzymając się jedynie kolejności klas bazowych, bo taki kod też będzie działał:


tylko, że do sesji nie zostanie zapisana informacja o miniaturce, bo jest wygenerowana po zapisaniu danych do sesji.

Jest to o wiele bardziej elastyczne rozwiązanie niż Twoje według mnie, nadbudowujące kod, a nie modyfikujące go.

Teraz tak sobie pomyślałem, że w sumie do dekoratora nie musi być plik przekazywany, a może być obiekt:


i wtedy klient dziedziczący po klasie abstrakcyjnej metodę do utworzenia takiego obiektu wywoływałby dekorator.


Klient pobiera plik, a w metodzie make, lub w konstruktorze klienta byłoby



i wtedy kolejność dekoratorów nie ma żadnego znaczenia, bo można zrobić sam:
lub




Co sądzicie?

Sądzę że twoje posty są zbyt chaotyczne i trudne do zrozumienia, często zmieniasz tok myślowy a ponadto masz problem ze zrozumieniem wzorca dekorator.

Wydaje Ci się

A mnie zastanawia, po co w ogóle zadajesz pytania @Omenomn, skoro później olewasz wszystkie odpowiedzi upierając się przy swoim? Zupełnie jak tutaj: http://forum.php.pl/index.php?showtopic=243138 :/

To się zastanawiaj dalej, możemy gadać o php, a nie o mnie i moim podejściu do Waszych wypowiedzi.

Przedstawiłem nowy pomysł rozwiązania, więc się do niego odnieście, a nie do mnie.

Co Wy jesteście, wyrocznia, że mam Wasze oceny i opinie przyjmować jako jedyne prawdziwe i niezaprzeczalne?
Dyskutować można, a to co się wyciągnie z dyskusji to prywatna sprawa każdego z osobna.

Tacy świetni jesteście, a jak com, albo daro0 wrzucili swój kod, to się okazuje, że gorzej przemyślany niż mój.

Nie ma takiej potrzeby bo klasa ImageUpload nigdy się nie zmieni, po to masz przecież dekorator żeby dodać do niej nowe funkcjonalności bez zmiany tej klasy. Te parametry które tam dostaje w konstruktorze one są stałe i nie maja znaczenia, równie dobrze możesz tam przekazać sam Encoder, a Renamer może być dekoratorem, bo w zasadzie zmieniasz źródło danych. Ja po prostu założyłem , że to jest podstawowa funkcjonalność i te kroki są wykonywane zawsze. Klasa mogła nie otrzymywać wgl parametrów i wszystko to dziać się w jej wnętrzu ale wtedy łamiesz zasady programowania obiektowego.



No i co mi po tych danych, owszem potrzebuje je w klasie ImageUpload, która zapisuje mi przesłany plik, ale to już nie interesuje GenerateWithThumbnail, bo jego jedynym zdaniem jest stworzenie miniaturki, wiec do czego tu potrzebne są te inne informacje.



Jak chcesz coś pomniejszyć skoro to coś nie istnieje. Najpierw musisz mieć coś co będziesz zmniejszał a potem możesz to zmniejszyć, a nie najpierw zmniejszyć a potem dopiero to stworzyć.

Sadze, że nadal nie stworzyłes dekoratora bo nie rozumiesz dalej czym on jest i rozwiązanie które powstało jest strasznie nie elastyczne i wgl nie testowalne.



Ja wrzuciłem kod dekoratora bo się na niego uparłeś, wiec skoro według Ciebie rozwiązanie jest złe to znaczy że dekorator nie był dobrym pomysłem i tyle

Implementacja wersja 2:

[PHP] pobierz, plaintext 
class ImageUpload : UploadInterface
{
 
      public function save($file)
      {
              // tutaj zapis pliku
              (...)  
              return true;              
       }
}
 
class GenerateWithThumbnail : UploadInterface
{
      private $base;
 
      public function __construct (UpoladInterface $upload) 
      {
	     $this->base = $upload;
      }
 
      public function save($file)
      {
              // tutaj wygenerowanie miniaturki
              (...)  
 
             $this->base->save($fileWithThumbnail);
       }
}
 
class Encode : UploadInterface
{
      private $base;
 
      public function __construct (UpoladInterface $upload) 
      {
	     $this->base = $upload;
      }
 
      public function save($file)
      {
              // tutaj encodowanie pliku
              (...)  
 
             $this->base->save($encodedFile);
       }
}
 
class Renamer : UploadInterface
{
      private $base;
 
      public function __construct (UpoladInterface $upload) 
      {
	     $this->base = $upload;
      }
 
      public function save($file)
      {
              // tutaj zmiana nazwy pliku
              (...)  
 
             $this->base->save($renamedFile);
       }
}
 
// Wywołanie 
$obj = new Encode(new Renamer(new GenerateWithThumbnail(new ImageUpload())));
$obj->save($request->file);
 
$obj1 = new Renamer(new Encode(new GenerateWithThumbnail(new ImageUpload())));
$obj1->save($request->file);
 
// $obj === $obj1; => true
[PHP] pobierz, plaintext 

żeby zmienić rozmiar obrazka, musisz przekazać kontent pliku klasie GenerateWithThumbnail



Przed uploadem plik znajduje się folderze z plikami tymczasowymi, jak nie wiesz takich rzeczy to o czym my rozmawiamy w ogóle? Na tym pliku się operuje, chyba, że chcesz najpierw go wysłać, a później obrabiać, co jest bez sensu, bo można to zrobić przed wysłaniem.



W ogóle parametry w konstruktorze nie mają znaczenia, zupełnie...



Jest elastyczne, bo można nakładać warstwy jak się chce i jakie się chce, a klasa ImageUpload działa samoistnie bez żadnego dekoratora, tak jak chciałeś i oczywiście jest testowalne, bo znowu przetestowałem i działa w różnych konfiguracjach.

Dajmy sobie spokój, bo to co przedstawiasz po prostu nie może działać, jest nieścisłe, ogólne, nierozszerzalne i nietestowalne i proszę Cię skończ mi wmawiać, że nie rozumiem dekoratora.

Niczego nie musisz przekazywać bo ta klasa otrzyma surowy plik.



No wiec ten plik istnieje w tempie, a nie Ty go dopiero tworzysz potem.



No nie mają, bo to są zależności potrzebne klasie ImageUpload, tam może być cokolwiek



Tak ale tylko w ściśle określonej kolejności i żadnego nie można pominąć. Zacznijmy od tego, że nawet nie wiesz co są testy, wiec nie rozumiesz tego, że to nie działa. Masz nieskończona ilość kombinacji i co przetestowałeś je wszystkie, nie, zrobiłeś testy działa nie działa, a to nie jest testowalność.



No nie rozumiesz bo mimo wielu prób dekorator nie powstał, ale tak zakończmy to, wróć za parę lat z doświadczeniem

Nie kpij sobie, doświadczeniem nie nadrobisz kumatości.
Dakorator powstał. Mam to gdzieś, czy nazwiesz to dekoratorem, modyfikatorem, warstwami, czy jeszcze jakoś inaczej, ważne, że porządkuje kod.

Owszem nie nadrobisz, ale to nie ja nie kumam jak działa dekorator tylko Ty go nie zrozumiałeś.
A twój kod nie został uporządkowany, a bardziej zaciemniony niż jakbyś zrobił po prostu wszytko w kontrolerze i tyle

Szaleństwo! Najlepiej piszmy apki w jednym pliku i jednej klasie

Zróbmy tak, wrzuć całą swoja implementacje na gita i daj linka. Specjalnie dla Ciebie zrobię z tego dekorator



Bardzo skrajne rozwiązanie, ale istnieje takie coś jak

Zasada Keep It Simple, Stupid (czyli tłumacząc: nie komplikuj, głupku) jest to reguła mówiąca, że nie należy na siłę komplikować prostych rzeczy, aby przykładowo wykorzystać niepotrzebne w danym momencie wzorce projektowe.

Ok wrzucę, może ktoś się czegoś nauczy.

https://github.com/omenomn/uploadDecorator

Masz, ciekawe jak to poprawisz.

@Omenomn

Zanim zaczniesz jechać po czyimś kodzie czy tam w ogóle podejściu (i nie mówię o swoim) to tak:

1. Napisz jakiś serwis pokroju tego forum albo coś innego, co się wiąże z kilkumiesięcznym nakładem pracy
2. Napisz kolejny serwis za rok i wróć do kodu sprzed roku
3. Napisz coś kolejnego za 2 lata, za 3 itd.. i znowu wróć

Gwarantuję Ci że będziesz miał niesmak po tym co zrobiłeś wcześniej. Akurat @com przedstawił tu dość klarowne rozwiązanie, łatwe do zrozumienia a konkretniej chodzi o to na czym polega i co się dzieje po zastosowaniu wzorca dekorator.

Podałem tylko wcześniej pewną realizację wczytywania zdjęć modułem Image z Kohany i ich obróbkę na podstawie parametrów z request query, podaj może tutaj praktyczną realizację jak byś zrobił taki static server, który w zależności od parametrów z paska przeglądarki wyświetlałby odpowiednio udekorowane zdjęcia na bazie swojego rozwiązania.

Po moim jadą wszyscy cały czas

Wrzuciłem link na github.
Coś długo te poprawki

Bo tam w tym kodzie niczego się nie dało wykorzystać, no może poza tym co jest gotowe czyli wykorzystanie FFMpeg. I wcale nie powiedziałem, że dam Ci to od razu, przecież cały czas nie siedziałem nad tym rozwianiem, robię inne rzeczy o wyższym priorytecie niż ten kod.

https://github.com/ComStudio/decorator

Gdzie Ty tam masz ten Twój niezrozumiały przeze mnie dekorator, bo nie widzę tam ani jednej klasy wywołanej w konstruktorze innej?

I w czym niby Twój kod jest lepszy od mojego?

info o pliku pobierasz w trzech, albo więcej miejscach:

[PHP] pobierz, plaintext 
    public function save(File $file)
    {
        $this->image->save($file);
        $storage   = $this->getStorage();
        $fileName  = $file->getName();
        $thumbnailFromImage = new ThumbnailFromImage(150);
        $thumbnail = new File(
            $fileName . '_thumb',
            $file->getExtension(),
            $thumbnailFromImage->create($file),
            $file->getPath()
        );
        if($storage->has($fileName))
        {
            $image = $storage->get($fileName);
            $image['thumbnail'] = $thumbnail;
        }
    }
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
    public function save(File $file)
    {
        $this->image->save($file);
        $storage   = $this->getStorage();
        $fileName  = $file->getName();
        $thumbnailFromVideo   = new ThumbnailFromVideo();
        $thumbnail = new File(
            $fileName . '_thumb',
            $file->getExtension(),
            $thumbnailFromVideo->create($file),
            $file->getPath()
        );
        if($storage->has($fileName))
        {
            $image = $storage->get($fileName);
            $image['thumbnail'] = $thumbnail;
        }
    }
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
    public function __construct($name, $extension, $content, $path)
    {
        $this->name = $name;
        $this->extension = $extension;
        $this->content = $content;
        $this->path = $path;
    }
    public static function CreateFromRequest($file)
    {
        return new File(
            $file->getClientOriginalName(),
            $file->getClientOriginalExtension(),
            \File::get($file->getRealPath()),
            $file->getRealPath()
        );
    }
[PHP] pobierz, plaintext 

Nawet nie chce mi się już analizować tego kodu, burdel taki, że głowa boli.

https://github.com/ComStudio/decorator/blob/master/index.php

Tu masz wywołanie.


A tu co niby robisz https://github.com/omenomn/uploadDecorator/...sformers/Makers
W każdej klasie zwracasz 95% tych samych informacji.
Ja tam niczego nie pobieram, poza klasa File, w pozostałych miejscach tylko zwracam te informacje, żeby wygenerować nowy plik z miniaturka na bazie oryginału.
W dodatku te dwie metody save to przecież dwie rożne klasy, jedna dla Image, druga dla Video.

Ten fragment to tworzenie nowego obrazka, czyli tej miniaturki, bo coś źle chyba to zrozumiałeś.

[PHP] pobierz, plaintext 
 $thumbnail = new File(
            $fileName . '_thumb',
            $file->getExtension(),
            $thumbnailFromVideo->create($file),
            $file->getPath()
 );
[PHP] pobierz, plaintext 

Moje File to Twoje:
https://github.com/omenomn/uploadDecorator/...kerAbstract.php

Klasa abstrakcyjna ma co najmniej jedna metodę abstrakcyjna, inaczej nie jest klasą abstrakcyjną, wiec nie ma sensu.

A tu to już wgl szaleństwo
https://github.com/omenomn/uploadDecorator/...s/Puter.php#L11

Potrafisz stworzyć obiekt klasy abstrakcyjnej. Aż dziw że ten kod działa



Burdel to masz w swoim kodzie, widać, że nawet nie używasz porządnego IDE, bo masz masę rzeczy które są zbędne i albo nigdzie nie używasz.
Skoro te rozwiązanie jest dla Ciebie nie zrozumiałe, to nie mamy o czym rozmawiać, bo nie potrafisz pisać jeszcze obiektowo. Za parę lat jak wrócisz i się tego nauczysz to wtedy zrozumiesz to co stworzyłem

Twój kod to idealny przykład jak tego nie robić

Utrzymanie takiego kodu jaki stworzyłeś już dziś jest problematyczne. Nie mówiąc już o zrozumieniu jego, bo z niego nie wynika nic co chciałeś tam zrobić i jak ktoś dostanie ten kod to będzie się bał wgl to ruszyć

Polecam lekturę CzystyKod.

[PHP] pobierz, plaintext 
$upload = new Upload($imageSession);
$upload->save($file);
//Obraz z miniaturka
$uploadImageWithThumbnail = new ImageWithThumbnail(new Upload($imageSession));
$uploadImageWithThumbnail->save($file);
//Video
$videoSession = new SessionStorage('video');
//Zwykły upload
$upload = new Upload($videoSession);
$upload->save($file);
//Wideo z miniaturka
$uploadVideoWithThumbnail = new VideoWithThumbnail(new Upload($videoSession));
$uploadVideoWithThumbnail->save($file);
[PHP] pobierz, plaintext 

Ciekawe jak zapiszesz plik bez zapisywania informacji o nim do sesji, skoro klasa Upload wymaga interjejsu StorageInterface.
Gdzie masz kodowanie, zmianę nazwy randomową i do ustawienia?

W dekoratorze używa się jednego interfejsu, a nie jak tutaj:

[PHP] pobierz, plaintext 
class Upload implements UploadInterface{}
class SessionStorage implements StorageInterface{}
class ImageWithThumbnail implements UploadInterface{}
[PHP] pobierz, plaintext 

No chyba, że bazę traktujesz jako:

[PHP] pobierz, plaintext 
(new Upload($videoSession))
[PHP] pobierz, plaintext 

tylko po co ta sesja w konstruktorze?



To są transformery, one nie pobierają danych tylko transformują otrzymane dane do postaci jaką się potrzebuje. Działają na pojedynczym elemencie i kolekcji.



Nie tworzę obiektu klasy abstrakcyjnej tylko jej interfejsu. Klasa abstrakcyjna działa jak interfejs z tym, że metody możesz w niej dodawać.


Przykłady wywołania mojego kodu:

[PHP] pobierz, plaintext 
$file = new Puter(new ImageSessionPuter(new Returner)); //Wysłanie pliku, zapis do sesji, zwrócenie
$file = new Returner; // Samo zwrócenie danych o pliku
$file = new ImageSessionPuter(new Returner); // Zapis do sesji danych o pliku bez uploadu
$file = new Puter(new Returner); // Zapis pliku i zwrócenie informacji o nim
$file = new ImageSessionPuter(new Puter(new Returner)) // zapis do sesji, wysłanie pliku,, zwrócenie - odwrotna kolejność
$file = new RandomNamer(new Puter(new Returner)); 
$file = new RandomNamer(new Encoder(new Puter(new Returner))) // losowa nazwa, kodowanie, zapis, zwrócenie danych
$file->make($object);
[PHP] pobierz, plaintext 

Który kod jest bardziej elastyczny?
Odpowiedź jest chyba oczywista.

Ogólnie rzecz biorąc problem nie jest tak oczywisty do rozwiązania i błachy, jak wydaje mi się, że go większość potraktowała.

Pod Laravela jest coś interesującego np. do obróbki zdjęć a i z uploadem sprawa powinna być prosta.

http://image.intervention.io/

Podobne podejście jak w Kohanie (gdzie jest moduł Image).

http://www.easylaravelbook.com/blog/2015/0...with-laravel-5/

Wrzucałem już link do intervention image w tym temacie i pisałem, że go wykorzystuję.

Daro0 nie rozumiesz problemu, jeśli podrzucasz mi bibliotekę do obróbki zdjęć.
Ona nie wykonuje uploadu, zmiany nazw plików, zapisu danych o plikach do sesji, wycinania miniaturek z video, czy innych czynności związanych ogólnie z plikami, a nie tylko z obrazami.

Rozwiązanie, które przedstawiłem wykonuje wszystkie te operacje plus do tego jest całkowicie elastyczne, bo można dodawać poszczególne warstwy odpowiedzialne za kolejne operacje, bez ingerencji, w którąkolwiek warstwę już istniejącą, np. pobieranie wysokość i szerokość (wykorzystanie intervention image), albo rozmiaru pliku, czy innych właściwości. Mogę np. chcieć zmienić wielkość filmiku i wtedy po prostu dodaję warstwę odpowiedzialną za to.

Jeśli nie widzicie plusów takiego rozwiązania to Ja nie wiem...

ps.
Jednak warto było mimo wszystko temat umieścić, bo pomysł z dekoratorem przyszedł mi po próbach szukania odpowiedniego wzorca zainspirowany odpowiedziami tutaj między innymi mrc, a ostateczny szlif dokonał się po uzmysłowieniu sobie, że klasa bazowa dekoratora powinna funkcjonować sama (com)

Jako obserwator tematu dziwię się że com jeszcze chce z tobą dyskutować. Jego kod jest czytelny, samoopisujacy sie, zrozumiały dla osób postronnych (przynajmniej tych znających OOP). Wystarczyło mi 3 minuty na zrozumienie całości (może dlatego że sam bym to zaimplementował bardzo podobnie).

Twoj kod omenomn analizowałem 5 minut i zrezygnowałem. Nie ma tam dzbła KISS, jeszcze te nazwy klas (puter, returner) ... może i twoje rozwiązanie jest zrozumiałe dla ciebie i w twoim mniemaniu jest elastyczne, ale do cholery nie mógł bym pracować na twoim kodzie, bo jest po prostu zbyt skomplikowany.

Tam masz interfejs wiec zapisujesz do czegokolwiek co implementuje ten interfejs. Przecież nie zrobię Ci gotowca, ja tylko wskazałem drogę która masz iść, Zmiana kodowania,nazwy itd to będą kolejne dekoratory, które sobie dopiszesz w miarę potrzeb.

Dekoratorem jest z tego fragmentu tylko:

[PHP] pobierz, plaintext 
 class ImageWithThumbnail implements UploadInterface{}
[PHP] pobierz, plaintext 

Upload to klasa bazowa, a SessionStorage wgl nie ma znaczenia dla dekoratora. Bo to jest zależność wstrzykiwana do Upload, dlatego możesz wstawić dowolny storage jaki sobie wymarzysz, warunek jest tylko taki musi implementować zdefiniowany interfejs.



Nie rozumiem wgl ich zastosowania, ale ja to wszytki zawarłem w jednej klasie File która działa dla wszystkich.



Owszem klasa abstrakcyjna może posiadać definicje jakiś wspólnych metod ale musi posiadać co najmniej jedną metodę abstrakcyjną, żeby można było ja nazwać klasa abstrakcyjna, inaczej to jest zwykła klasa.
To są podstawy programowania obiektowego.


Owszem jest, nie Twój i to nie jest moja tylko subiektywna opinia, ale reszta osób stwierdziła to samo.

Nie wiem gdzie Ty pracujesz, czy robisz to sam czy w jakimś zespole ale jak w zespole to niech ktoś zrobi Ci code review tego co stworzyłeś

@com Co do abstrakcji to klasa abstrakcyjna nie musi zawierać metod abstrakcyjnych Za to każda klasa która posiada przynajmniej 1 abstrakcyjną metodą musi być abstrakcyjna.

Tak więc


jest poprawne.