Nei linguaggi orientati agli oggetti, quando gli oggetti devono eseguire operazioni su se stessi e quando devono essere eseguite operazioni sugli oggetti?

Supponiamo che ci sia una Pageclasse, che rappresenta un insieme di istruzioni per un renderer di pagine. E supponiamo che esista una Rendererclasse che sappia renderizzare una pagina sullo schermo. È possibile strutturare il codice in due modi diversi:

/*
 * 1) Page Uses Renderer internally,
 * or receives it explicitly
 */
$page->renderMe(); 
$page->renderMe($renderer); 

/*
 * 2) Page is passed to Renderer
 */
$renderer->renderPage($page);

Quali sono i pro e i contro di ogni approccio? Quando uno sarà migliore? Quando sarà meglio l'altro?

SFONDO

Per aggiungere un po 'più di background, mi trovo a utilizzare entrambi gli approcci nello stesso codice. Sto usando una libreria PDF di terze parti chiamata TCPDF. Da qualche parte nel mio codice devo avere il seguente per far funzionare il rendering PDF:

$pdf = new TCPDF();
$html = "some text";
$pdf->writeHTML($html);

Di 'che desidero creare una rappresentazione della pagina. Potrei creare un modello che contiene le istruzioni per il rendering di uno snippet di pagine PDF in questo modo:

/*
 * A representation of the PDF page snippet:
 * a template directing how to render a specific PDF page snippet
 */
class PageSnippet
{    
    function runTemplate(TCPDF $pdf, array $data = null): void
    {
        $pdf->writeHTML($data['html']);
    }
}

/* To be used like so */
$pdf = new TCPDF();
$data['html'] = "some text";
$snippet = new PageSnippet();
$snippet->runTemplate($pdf, $data);

1) Notare qui che si $snippet esegue da solo , come nel mio primo esempio di codice. Deve anche conoscere ed avere familiarità con $pdf, e con qualsiasi $dataper farlo funzionare.

Ma posso creare una PdfRendererclasse in questo modo:

class PdfRenderer
{
    /**@var TCPDF */
    protected $pdf;

    function __construct(TCPDF $pdf)
    {
        $this->pdf = $pdf;
    }

    function runTemplate(PageSnippet $template, array $data = null): void
    {
        $template->runTemplate($this->pdf, $data);
    }
}

e quindi il mio codice si trasforma in questo:

$renderer = new PdfRenderer(new TCPDF());
$renderer->runTemplate(new PageSnippet(), array('html' => 'some text'));

2) Qui $rendererriceve il PageSnippete qualsiasi $datarichiesto per farlo funzionare. Questo è simile al mio secondo esempio di codice.

Pertanto, anche se il renderer riceve lo snippet di pagina, all'interno del renderer lo snippet continua a funzionare da solo . Vale a dire che entrambi gli approcci sono in gioco. Non sono sicuro di poter limitare l'utilizzo di OO solo all'una o all'altra. Entrambi potrebbero essere richiesti, anche se si mascherano l'uno dall'altro.

Questo dipende interamente da cosa pensi che sia OO .

Per OOP = SOLID, l'operazione dovrebbe far parte della classe se fa parte della responsabilità singola della classe.

Per OO = invio virtuale / polimorfismo, l'operazione dovrebbe far parte dell'oggetto se deve essere inviato in modo dinamico, cioè se viene chiamato attraverso un'interfaccia.

Per OO = incapsulamento, l'operazione dovrebbe far parte della classe se utilizza uno stato interno che non si desidera esporre.

Per OO = "Mi piacciono le interfacce fluenti", la domanda è quale variante legge in modo più naturale.

Per OO = modellazione di entità del mondo reale, quale entità del mondo reale esegue questa operazione?

Tutti questi punti di vista sono generalmente errati in isolamento. Ma a volte una o più di queste prospettive sono utili per arrivare a una decisione di progettazione.

Ad esempio, usando il punto di vista del polimorfismo: se si hanno strategie di rendering diverse (come formati di output diversi o motori di rendering diversi), allora $renderer->render($page)ha molto senso. Ma se hai diversi tipi di pagina che dovrebbero essere resi in modo diverso, $page->render()potrebbe essere migliore. Se l'output dipende sia dal tipo di pagina sia dalla strategia di rendering, è possibile effettuare una doppia spedizione attraverso il modello visitatore.

Non dimenticare che in molte lingue, le funzioni non devono essere metodi. Una funzione semplice come render($page)se spesso una soluzione perfettamente perfetta (e meravigliosamente semplice).

Secondo Alan Kay , gli oggetti sono organismi autosufficienti, "adulti" e responsabili. Gli adulti fanno cose, non vengono operati. Cioè, la transazione finanziaria è responsabile del salvataggio stesso , la pagina è responsabile del rendering stesso , ecc. Ecc. Più concisamente, l'incapsulamento è la cosa più importante in OOP. In particolare, si manifesta attraverso il famoso principio Tell not ask (che a @CandiedOrange piace sempre menzionare :)) e la riprovazione pubblica di getter e setter .

In pratica si traduce in oggetti che possiedono tutte le risorse necessarie per svolgere il proprio lavoro, come strutture di database, strutture di rendering, ecc.

Quindi, considerando il tuo esempio, la mia versione OOP sarebbe simile alla seguente:

class Page
{
    private $data;
    private $renderer;

    public function __construct(ICanRender $renderer, $data)
    {
        $this->renderer = $renderer;
        $this->data = $data;
    }

    public function render()
    {
        $this->renderer->render($this->data);
    }
}

Nel caso in cui tu sia interessato, David West parla dei principi OOP originali nel suo libro, Object Thinking .

$page->renderMe();

Qui siamo pagecompletamente responsabili del rendering stesso. Potrebbe essere stato fornito con un rendering tramite un costruttore o potrebbe avere quella funzionalità integrata.

Ignorerò il primo caso (fornito con un rendering tramite un costruttore) qui, poiché è abbastanza simile al passaggio come parametro. Invece, esaminerò i pro e i contro della funzionalità integrata.

Il pro è che consente un livello molto elevato di incapsulamento. La pagina non deve rivelare direttamente nulla sul suo stato interiore. Lo espone solo attraverso un rendering di se stesso.

La contro è che rompe il principio della responsabilità singola (SRP). Abbiamo una classe che è responsabile dell'incapsulamento dello stato di una pagina ed è anche codificata con regole su come renderizzarsi e quindi probabilmente tutta una serie di altre responsabilità in quanto gli oggetti dovrebbero "fare le cose da soli, non farle fare da altri ".

$page->renderMe($renderer);

Qui, stiamo ancora richiedendo che una pagina sia in grado di renderizzarsi, ma la stiamo fornendo con un oggetto helper in grado di eseguire il rendering effettivo. Qui possono presentarsi due scenari:

1. La pagina deve semplicemente conoscere le regole di rendering (quali metodi chiamare in quale ordine) per creare quel rendering. L'incapsulamento viene conservato, ma l'SRP è ancora interrotto poiché la pagina deve ancora supervisionare il processo di rendering, oppure
2. La pagina chiama solo un metodo sull'oggetto renderer, trasmettendone i dettagli. Ci stiamo avvicinando al rispetto dell'SRP, ma ora abbiamo indebolito l'incapsulamento.

$renderer->renderPage($page);

Qui, abbiamo pienamente rispettato l'SRP. L'oggetto pagina è responsabile del mantenimento delle informazioni su una pagina e il renderer è responsabile del rendering di quella pagina. Tuttavia, ora abbiamo completamente indebolito l'incapsulamento dell'oggetto pagina in quanto deve renderlo pubblico.

Inoltre, abbiamo creato un nuovo problema: il renderer è ora strettamente associato alla classe di pagine. Cosa succede quando vogliamo rendere qualcosa di diverso da una pagina?

Qual è il migliore? Nessuno di loro. Tutti hanno i loro difetti.

La risposta a questa domanda è inequivocabile. È $renderer->renderPage($page);qual è l'implementazione corretta. Per capire come siamo arrivati ​​a questa conclusione, dobbiamo capire l'incapsulamento.

Cos'è una pagina? È una rappresentazione di un display che qualcuno consumerà. Quel "qualcuno" potrebbe essere umano o robot. Si noti che Pageè una rappresentazione e non il display stesso. Esiste una rappresentazione senza essere rappresentata? Una pagina è qualcosa senza renderer? La risposta è Sì, una rappresentazione può esistere senza essere rappresentata. Rappresentare è una fase successiva.

Che cos'è un renderer senza una pagina? Un renderer può essere visualizzato senza una pagina? No. Quindi un'interfaccia Renderer necessita del renderPage($page);metodo.

Cosa c'è che non va $page->renderMe($renderer);?

È il fatto che renderMe($renderer)dovrà ancora chiamare internamente $renderer->renderPage($page);. Questo viola la Legge di Demetra che afferma

Ogni unità dovrebbe avere una conoscenza limitata delle altre unità

Alla Pageclasse non importa se esiste un Rendereruniverso. Si preoccupa solo di essere una rappresentazione di una pagina. Quindi la classe o l'interfaccia Renderernon dovrebbero mai essere menzionate in a Page.

RISPOSTA AGGIORNATA

Se la tua domanda è corretta, la PageSnippetclasse dovrebbe occuparsi solo di essere un frammento di pagina.

class PageSnippet
{    
    /** string */
    private $html;

    function __construct($data = ['html' => '']): void
    {
        $this->html = $data['html'];
    }

   public function getHtml()
   {
       return $this->html;
   }
}

PdfRenderer si occupa del rendering.

class PdfRenderer
{
    /**@var TCPDF */
    protected $pdf;

    function __construct(TCPDF $pdf = new TCPDF())
    {
        $this->pdf = $pdf;
    }

    function runTemplate(string $html): void
    {
        $this->pdf->writeHTML($html);
    }
}

Utilizzo del cliente

$renderer = new PdfRenderer();
$snippet = new PageSnippet(['html' => '<html />']);
$renderer->runTemplate($snippet->getHtml());

Un paio di punti da considerare:

• È una cattiva pratica passare $datacome array associativo. Dovrebbe essere un'istanza di una classe.
• Il fatto che il formato della pagina sia contenuto all'interno della htmlproprietà $datadell'array è un dettaglio specifico per il tuo dominio ed PageSnippetè a conoscenza di questi dettagli.

Idealmente, si desidera il minor numero possibile di dipendenze tra le classi, poiché riduce la complessità. Una classe dovrebbe avere una dipendenza da un'altra classe solo se ne ha davvero bisogno.

Lo stato Pagecontiene "un set di istruzioni per un renderer di pagine". Immagino qualcosa del genere:

renderer.renderLine(x, y, w, h, Color.Black)
renderer.renderText(a, b, Font.Helvetica, Color.Black, "bla bla...")
etc...

Così sarebbe $page->renderMe($renderer), poiché la Pagina ha bisogno di un riferimento al renderer.

Ma in alternativa le istruzioni di rendering potrebbero anche essere espresse come una struttura di dati piuttosto che chiamate dirette, ad es.

[
  Line(x, y, w, h, Color.Black), 
  Text(a, b, Font.Helvetica, Color.Black, "bla bla...")
]

In questo caso, il Renderer effettivo otterrebbe questa struttura di dati dalla Pagina ed elaborerà eseguendo le corrispondenti istruzioni di rendering. Con un tale approccio le dipendenze sarebbero invertite: la Pagina non ha bisogno di conoscere il Renderer, ma al Renderer dovrebbe essere fornita una Pagina che può quindi renderizzare. Quindi opzione due:$renderer->renderPage($page);

Quindi qual è il migliore? Il primo approccio è probabilmente il più semplice da implementare, mentre il secondo è molto più flessibile e potente, quindi immagino che dipenda dalle tue esigenze.

Se non riesci a decidere, o pensi di poter cambiare approccio in futuro, puoi nascondere la decisione dietro un livello di riferimento indiretto, una funzione:

renderPage($page, $renderer)

L'unico approccio che non consiglierò è $page->renderMe()dato che suggerisce che una pagina può avere un solo renderer. Ma cosa succede se hai un ScreenRenderere aggiungi un PrintRenderer? La stessa pagina potrebbe essere resa da entrambi.

La parte D di SOLID dice

"Le astrazioni non dovrebbero dipendere dai dettagli. I dettagli dovrebbero dipendere dalle astrazioni."

Quindi, tra Page e Renderer, che è più probabile che sia un'astrazione stabile, meno probabilità di cambiare, forse rappresentando un'interfaccia? Al contrario, qual è il "dettaglio"?

Nella mia esperienza, l'astrazione è di solito il Renderer. Ad esempio, potrebbe essere un semplice Stream o XML, molto astratto e stabile. O un layout abbastanza standard. È più probabile che la tua Pagina sia un oggetto business personalizzato, un "dettaglio". E hai altri oggetti business da rendere, come "foto", "rapporti", "grafici" ecc ... (Probabilmente non un "trittico" come nel mio commento)

Ma ovviamente dipende dal tuo design. La pagina potrebbe essere astratta, ad esempio l'equivalente di un <article>tag HTML con sottoparti standard. E hai un sacco di diversi "renderer" personalizzati per i rapporti commerciali. In tal caso, il Renderer dovrebbe dipendere dalla Pagina.

Penso che la maggior parte delle Classi possa essere suddivisa in una di due categorie:

• Classi contenenti dati (mutabili o immutabili non importa)

Queste sono classi che non hanno quasi alcuna dipendenza da nient'altro. Di solito fanno parte del tuo dominio. Non devono contenere alcuna logica o solo logica che può essere derivata direttamente dal suo stato. Una classe Employee può avere una funzione isAdultche può essere derivata direttamente dalla sua birthDatema non una funzione hasBirthDayche richiede informazioni esterne (la data corrente).

• Classi che forniscono servizi

Questi tipi di classi operano su altre classi contenenti dati. In genere sono configurati una volta e immutabili (quindi svolgono sempre lo stesso tipo di funzione). Questi tipi di classi possono comunque fornire un'istanza di supporto di breve durata con stato per eseguire operazioni più complesse che richiedono il mantenimento di uno stato per un breve periodo (come le classi Builder).

Il tuo esempio

Nel tuo esempio, Pagesarebbe una classe contenente dati. Dovrebbe avere funzioni per ottenere questi dati e forse modificarli se si suppone che la classe sia mutabile. Tienilo stupido, quindi può essere usato senza molte dipendenze.

Dati, o in questo caso il tuo Pagepotrebbe essere rappresentato in molti modi. Potrebbe essere reso come una pagina web, scritta su disco, memorizzata in un database, convertita in JSON, qualunque cosa. Non si desidera aggiungere metodi a tale classe per ciascuno di questi casi (e creare dipendenze da tutti i tipi di altre classi, anche se la classe dovrebbe contenere solo dati).

La tua Rendererè una tipica classe di servizio. Può operare su un determinato set di dati e restituire un risultato. Non ha molti stati propri e quale stato è normalmente immutabile, può essere configurato una volta e poi riutilizzato.

Ad esempio, potresti avere a MobileRenderere a StandardRenderer, entrambe le implementazioni della Rendererclasse ma con impostazioni diverse.

Quindi, poiché Pagecontiene dati e deve essere mantenuto stupido, la soluzione più pulita in questo caso sarebbe quella di passare Pagea Renderer:

$renderer->renderPage($page)