Nesneye yönelik dillerde, nesneler ne zaman kendi başlarına işlem yapmalı ve nesneler üzerinde ne zaman işlem yapılmalıdır?

PageSayfa oluşturucuya yönelik bir dizi talimatı temsil eden bir sınıf olduğunu varsayalım . Ve Rendererbir sayfanın ekranda nasıl oluşturulacağını bilen bir sınıf olduğunu varsayalım . Kodu iki farklı şekilde yapılandırmak mümkündür:

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

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

Her yaklaşımın artıları ve eksileri nelerdir? Ne zaman daha iyi olacak? Diğeri ne zaman daha iyi olacak?

ARKA FON

Biraz daha arka plan eklemek için - kendimi aynı kodda her iki yaklaşımı kullanarak buluyorum. Adlı üçüncü taraf PDF kitaplığı kullanıyorum TCPDF. Kodumda bir yerde PDF oluşturma çalışması için aşağıdakilere sahip olmak zorunda:

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

Sayfanın bir temsilini oluşturmak istediğimi varsayalım. Bir PDF sayfası snippet'ini oluşturmak için talimatları tutan bir şablon oluşturabilirim:

/*
 * 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) Burada, ilk kod örneğimde olduğu gibi, $snippet kendini çalıştıran uyarı . Ayrıca çalışabilmesi için $pdfve her şeyi bilmeli ve bunlara aşina olmalıdır $data.

Ancak, PdfRendererböyle bir sınıf oluşturabilirim :

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);
    }
}

ve sonra kodum bu döner:

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

2) Burada çalışması için gerekli $rendererolan PageSnippetve alır $data. Bu ikinci kod örneğime benzer.

Dolayısıyla, oluşturucu sayfa snippet'ini alsa bile, oluşturucunun içinde snippet yine de kendi kendine çalışır . Yani her iki yaklaşım da oyunda. OO kullanımınızı yalnızca bir tanesiyle veya yalnızca diğeriyle sınırlandırabileceğinizden emin değilim. Birbirini maskeleseniz bile her ikisi de gerekli olabilir.

Bu tamamen OO'nun ne düşündüğüne bağlıdır .

OOP = SOLID için, sınıfın Tek Sorumluluğunun bir parçasıysa, işlem sınıfın bir parçası olmalıdır.

OO = sanal gönderme / polimorfizm için, dinamik olarak gönderilmesi gerekiyorsa, yani bir arabirim üzerinden çağrıldığında işlem nesnenin bir parçası olmalıdır.

OO = kapsülleme için, ifşa etmek istemediğiniz dahili durumu kullanıyorsa, işlem sınıfın bir parçası olmalıdır.

OO = “Akıcı arayüzleri seviyorum” sorusu, hangi varyantın daha doğal okuduğu sorusudur.

OO = gerçek dünya varlıklarını modellemek için, hangi gerçek dünya varlığı bu işlemi gerçekleştirir?

Tüm bu bakış açıları yalnız başına yanlıştır. Ancak bazen bu perspektiflerden biri veya daha fazlası bir tasarım kararına varmada yardımcı olur.

Örneğin polimorfizm bakış açısını kullanma: Farklı oluşturma stratejileriniz (farklı çıktı biçimleri veya farklı oluşturma motorları gibi) varsa, $renderer->render($page)çok mantıklıdır. Ancak, farklı şekilde işlenmesi gereken farklı sayfa türleriniz varsa $page->render()daha iyi olabilir. Çıktı hem sayfa türüne hem de oluşturma stratejisine bağlıysa, ziyaretçi kalıbı üzerinden iki kez gönderim yapabilirsiniz.

Birçok dilde, işlevlerin yöntem olması gerekmediğini unutmayın. render($page)Genellikle mükemmel bir ince (ve olağanüstü basit) bir çözüm gibi basit bir işlev .

Alan Kay'a göre nesneler kendi kendine yeterli, "yetişkin" ve sorumlu organizmalardır. Yetişkinler bir şeyler yaparlar, ameliyat edilmezler. Yani, finansal işlem kendini kurtarmaktan sorumludur , sayfa kendini oluşturmaktan vb. Sorumludur. Daha doğrusu, kapsülleme OOP'ta büyük şeydir. Özellikle, ünlü Tell sorma ilkesi (@CandiedOrange her zaman bahsetmeyi sever :)) ve alıcıların ve ayarlayıcıların kamuoyunda soyulmasıyla kendini gösterir .

Uygulamada, veritabanı tesisleri, oluşturma tesisleri vb. Gibi işlerini yapmak için gerekli tüm kaynaklara sahip nesnelerle sonuçlanır.

Örneğiniz göz önüne alındığında, OOP sürümüm aşağıdaki gibi görünecektir:

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);
    }
}

İlgilenmeniz durumunda David West, Object Thinking adlı kitabındaki orijinal OOP ilkelerini anlatıyor .

$page->renderMe();

Burada pagebizzat kendini yaratmaktan tamamen sorumluyuz. Bir kurucu aracılığıyla bir render sağlanmış olabilir veya bu işlevselliği yerleşik olarak içerebilir.

Parametre olarak geçirmeye oldukça benzer olduğu için, ilk örneği (bir oluşturucu aracılığıyla bir render ile birlikte verilir) görmezden geleceğim. Bunun yerine yerleşik işlevselliğin artılarını ve eksilerini inceleyeceğim.

Pro, çok yüksek bir kapsülleme seviyesine izin vermesidir. Sayfanın iç durumu hakkında doğrudan bir şey açıklamasına gerek yok. Sadece kendini göstererek ortaya koyar.

Con, tek sorumluluk ilkesini (SRP) ihlal etmesidir. Bir sayfanın durumunu kapsüllemekten sorumlu bir sınıfımız var ve aynı zamanda kendini nasıl oluşturacağına dair kurallarla kodlanmış ve bu nedenle nesnelerin "kendilerine bir şeyler yapması, başkaları tarafından bir şeyler yapmaması gerekeceği için büyük olasılıkla bir dizi diğer sorumluluklar var. ".

$page->renderMe($renderer);

Burada hâlâ bir sayfanın kendisini işleyebilmesini istiyoruz, ancak gerçek oluşturmayı gerçekleştirebilecek yardımcı bir nesne sağlıyoruz. Burada iki senaryo ortaya çıkabilir:

1. Sayfanın, bu oluşturmayı oluşturmak için oluşturma kurallarını (hangi sırayla çağırmak için hangi yöntemleri çağırması) bilmesi gerekir. Kapsülleme korunur, ancak sayfanın hâlâ oluşturma işlemini denetlemesi gerektiğinden SRP hala bozuktur veya
2. Sayfa, oluşturucu nesnesinde yalnızca bir yöntem çağırıyor ve ayrıntılarını içeri aktarıyor. SRP'ye saygı duymaya yaklaşıyoruz, ancak şimdi kapsüllemeyi zayıflattık.

$renderer->renderPage($page);

Burada, SRP'ye tamamen saygı duyduk. Sayfa nesnesi bir sayfada bilgi bulundurmaktan ve oluşturucu bu sayfayı oluşturmaktan sorumludur. Ancak, sayfa nesnesinin kapsüllenmesini tüm durumunu herkese açık hale getirmesi gerektiği için tamamen zayıflattık.

Ayrıca, yeni bir sorun oluşturduk: oluşturucu artık sayfa sınıfına sıkı sıkıya bağlı. Bir sayfadan farklı bir şey oluşturmak istediğimizde ne olur?

Hangisi en iyi? Hiçbiri. Hepsinin kusurları var.

Bu sorunun cevabı açıktır. Öyle $renderer->renderPage($page);doğru bir uygulama olduğu. Bu sonuca nasıl ulaştığımızı anlamak için kapsüllemeyi anlamamız gerekiyor.

Sayfa nedir? Birinin tüketeceği bir ekranın temsilidir. "Birisi" insan veya bot olabilir. Not Pagetemsilidir değil, ekran kendisidir. Temsil edilmeden bir temsil var mı? Sayfa oluşturucu içermeyen bir şey mi? Cevap Evet, bir temsil temsil edilmeden var olabilir. Temsil etmek daha sonraki bir aşamadır.

Sayfa içermeyen oluşturucu nedir? Bir oluşturucu sayfa olmadan görüntülenebilir mi? Hayır. Bu yüzden bir Renderer arayüzü renderPage($page);yönteme ihtiyaç duyar .

Sorun nedir $page->renderMe($renderer);?

renderMe($renderer)İçsel olarak hala aramak zorunda kalacak gerçektir $renderer->renderPage($page);. Bu ihlal Demeter Kanunu devletler

Her birimin diğer birimler hakkında sınırlı bilgiye sahip olması gerekir

PageSınıf var olup olmadığını umursamıyor Rendererevrende. Yalnızca bir sayfanın temsili olmakla ilgilenir. Bu nedenle sınıf veya arabirim Rendererasla a Page.

GÜNCEL YANIT

Sorunuzu doğru bulduysam, PageSnippetsınıf yalnızca bir sayfa pasajı olmakla ilgilenmelidir.

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

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

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

PdfRenderer renderleme ile ilgilidir.

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

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

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

İstemci kullanımı

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

Dikkate alınması gereken birkaç nokta:

• İlişkisel $databir dizi olarak geçmesi kötü bir uygulamadır . Bir sınıf örneği olmalıdır.
• Sayfa biçiminin dizinin htmlözelliği içinde yer $dataalması, alan adınıza özgü bir ayrıntıdır ve PageSnippetbu ayrıntıların farkındadır.

İdeal olarak, karmaşıklığı azalttığı için sınıflar arasında mümkün olduğunca az bağımlılık istersiniz. Bir sınıf yalnızca gerçekten ihtiyaç duyuyorsa başka bir sınıfa bağımlı olmalıdır.

Sen devlet Page"Bir sayfa oluşturucuya bir dizi talimat" içerir. Böyle bir şey hayal ediyorum:

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

Bu nedenle $page->renderMe($renderer), Sayfa oluşturucu için bir referansa ihtiyaç duyduğundan öyledir .

Ancak alternatif olarak oluşturma talimatları, doğrudan çağrılardan ziyade bir veri yapısı olarak da ifade edilebilir.

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

Bu durumda asıl İşleyici bu veri yapısını Sayfadan alır ve ilgili oluşturma talimatlarını uygulayarak işler. Böyle bir yaklaşımla bağımlılıklar tersine çevrilir - Sayfanın Oluşturucu hakkında bilgi sahibi olması gerekmez, ancak Oluşturucu'ya daha sonra oluşturabileceği bir Sayfa sağlanmalıdır. İkinci seçenek:$renderer->renderPage($page);

Hangisi daha iyi? İlk yaklaşım muhtemelen en basit olanıdır, ikincisi ise çok daha esnek ve güçlüdür, bu yüzden sanırım gereksinimlerinize bağlıdır.

Karar veremiyorsanız veya gelecekte yaklaşımı değiştirebileceğinizi düşünüyorsanız, bir dolaylı yolun, bir fonksiyonun arkasındaki kararı gizleyebilirsiniz:

renderPage($page, $renderer)

Tavsiye etmeyeceğim tek yaklaşım $page->renderMe(), bir sayfanın yalnızca tek bir oluşturucuya sahip olabileceğini düşündürmesi. Peki ya bir ScreenRendererekleyip eklerseniz PrintRenderer? Aynı sayfa her ikisi tarafından da oluşturulabilir.

KATI D parçası diyor

"Soyutlamalar detaylara, detaylar soyutlamalara bağlı olmalıdır."

Peki, sabit bir soyutlama olasılığı daha yüksek, değişme olasılığı daha düşük, muhtemelen bir arabirimi temsil eden Page ve Renderer arasında? Aksine, "detay" hangisi?

Deneyimlerime göre, soyutlama genellikle Renderer'dir. Örneğin, çok soyut ve kararlı, basit bir Akış veya XML olabilir. Ya da oldukça standart bir düzen. Sayfanızın özel bir işletme nesnesi, bir "ayrıntı" olma olasılığı daha yüksektir. Ve "resimler", "raporlar", "grafikler" vb. Gibi işlenecek başka iş nesneleriniz de var.

Ama açıkça tasarımınıza bağlı. Sayfa, örneğin <article>standart alt bölümleri olan bir HTML etiketinin eşdeğeri olabilir . Ve birçok farklı özel iş raporlama "renderer" var. Bu durumda, Oluşturucu Sayfaya bağlı olmalıdır.

Sınıfların çoğunun iki kategoriden birine ayrılabileceğini düşünüyorum:

• Veri içeren sınıflar (değişebilir veya değişmez önemli değil)

Bunlar, başka hiçbir şeye neredeyse hiç bağımlılığı olmayan sınıflardır. Bunlar genellikle alan adınızın bir parçasıdır. Hiçbir mantık içermemeli veya sadece doğrudan durumundan türetilebilen mantık içermemelidir. Bir Çalışan sınıfı, isAdultdoğrudan kendi sınıfından türetilebildiği gibi bir işleve sahip olabilir, birthDateancak hasBirthDayharici bilgi gerektiren bir işleve sahip değildir (geçerli tarih).

• Hizmet veren sınıflar

Bu tür sınıflar veri içeren diğer sınıflarda çalışır. Genellikle bir kez yapılandırılır ve değiştirilemezler (böylece her zaman aynı tür işlevleri yerine getirirler). Bununla birlikte, bu tür sınıflar, bir durumun kısa bir süre (Builder sınıfları gibi) korunmasını gerektiren daha karmaşık işlemleri yapmak için hala durum bilgisi olan kısa ömürlü bir yardımcı örnek sağlayabilir.

Örneğiniz

Örneğin, Pageveri içeren bir sınıf olacaktır. Bu verileri almak ve sınıfın değişebilir olması gerekiyorsa, belki de değiştirmek için işlevleri olmalıdır. Aptal tutun, böylece çok fazla bağımlılık olmadan kullanılabilir.

Veriler veya bu durumda Pageçok çeşitli şekillerde temsil edilebilirsiniz. Web sayfası olarak işlenebilir, diske yazılır, veritabanında depolanır, JSON'a dönüştürülür. Bu vakaların her biri için böyle bir sınıfa yöntem eklemek istemezsiniz (ve sınıfınızın yalnızca veri içermesi gerekiyorsa bile, diğer tüm sınıflara bağımlılıklar oluşturmak).

Sizin Renderertipik bir hizmet türü sınıftır. Belirli bir veri kümesinde çalışabilir ve bir sonuç döndürebilir. Kendine ait çok bir durumu yoktur ve sahip olduğu durum genellikle değişmezdir, bir kez yapılandırılabilir ve sonra tekrar kullanılabilir.

Örneğin , sınıfın a MobileRendererve a StandardRendereruygulamalarının her ikisini birden uygulayabilirsiniz, Rendererancak farklı ayarlarla yapabilirsiniz.

Yani olarak Pageverileri içerir ve dilsiz tutulmalıdır, bu durumda en temiz çözüm geçmek olacaktır Pagea Renderer:

$renderer->renderPage($page)