ในภาษาที่มุ่งเน้นวัตถุวัตถุควรทำการดำเนินการกับตัวเองเมื่อใดและควรจะดำเนินการกับวัตถุเมื่อใด

สมมติว่ามีPageคลาสซึ่งแสดงชุดคำสั่งสำหรับตัวแสดงผลหน้า และสมมติว่ามีRendererคลาสที่รู้วิธีแสดงหน้าบนหน้าจอ เป็นไปได้ที่จะจัดโครงสร้างโค้ดด้วยวิธีที่ต่างกันสองวิธี:

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

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

ข้อดีและข้อเสียของแต่ละวิธีคืออะไร เมื่อใดจะดีกว่า คนอื่นจะดีกว่าเมื่อไหร่?

พื้นหลัง

เมื่อต้องการเพิ่มพื้นหลังเพิ่มเติมเล็กน้อย - ฉันค้นหาตัวเองโดยใช้วิธีการทั้งสองในรหัสเดียวกัน ฉันกำลังใช้ห้องสมุดของบุคคลที่ 3 รูปแบบไฟล์ PDF TCPDFที่เรียกว่า บางแห่งในรหัสของฉันฉันต้องมีสิ่งต่อไปนี้เพื่อให้การแสดงผล PDF ทำงานได้

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

กล่าวว่าฉันต้องการสร้างการเป็นตัวแทนของหน้า ฉันสามารถสร้างเทมเพลตที่มีคำแนะนำในการแสดงตัวอย่างข้อมูลหน้า PDF เช่น:

/*
 * 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) สังเกตที่นี่ที่ $snippet ทำงานตัวเองเช่นในตัวอย่างรหัสแรกของฉัน นอกจากนี้ยังจำเป็นต้องรู้และคุ้นเคยกับ$pdfและ$dataเพื่อการทำงาน

แต่ฉันสามารถสร้างPdfRendererชั้นเรียนได้เช่น:

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

จากนั้นรหัสของฉันเปลี่ยนเป็น:

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

2) ที่นี่$rendererได้รับPageSnippetและ$dataสิ่งที่จำเป็นสำหรับการทำงาน นี่คล้ายกับตัวอย่างรหัสที่สองของฉัน

ดังนั้นแม้ว่า renderer ได้รับข้อมูลโค้ดหน้าภายในแสดงผลข้อมูลโค้ดยังคงทำงานของตัวเอง กล่าวคือวิธีการทั้งสองอยู่ในการเล่น ฉันไม่แน่ใจว่าคุณสามารถ จำกัด การใช้งาน OO ของคุณให้เหลือเพียงอย่างเดียวเท่านั้น อาจจำเป็นต้องใช้ทั้งคู่แม้ว่าคุณจะปิดบังหน้ากัน

นี้ขึ้นอยู่กับสิ่งที่คุณคิดว่าเป็น OO

สำหรับ OOP = SOLID การดำเนินการควรเป็นส่วนหนึ่งของคลาสหากเป็นส่วนหนึ่งของ Single Responsibility ของคลาส

สำหรับ OO = virtual dispatch / polymorphism การดำเนินการควรเป็นส่วนหนึ่งของวัตถุถ้ามันควรถูกส่งแบบไดนามิกเช่นถ้ามันถูกเรียกผ่านอินเตอร์เฟส

สำหรับ OO = encapsulation การดำเนินการควรเป็นส่วนหนึ่งของคลาสหากใช้สถานะภายในที่คุณไม่ต้องการเปิดเผย

สำหรับ OO =“ ฉันชอบอินเทอร์เฟซที่คล่องแคล่ว” คำถามคือตัวแปรใดที่อ่านได้โดยธรรมชาติมากขึ้น

สำหรับ OO = การสร้างโมเดลเอนทิตีในโลกแห่งความเป็นจริงเอนทิตีในโลกแห่งความจริงใดที่ดำเนินการนี้

มุมมองเหล่านั้นทั้งหมดมักจะแยกผิด แต่บางครั้งมุมมองเหล่านี้อย่างน้อยหนึ่งมุมมองจะเป็นประโยชน์ในการตัดสินใจออกแบบ

เช่นใช้มุมมองแบบพหุสัณฐาน: หากคุณมีกลยุทธ์การแสดงผลที่แตกต่างกัน (เช่นรูปแบบเอาต์พุตที่แตกต่างกันหรือเอนจิ้นการเรนเดอร์ที่แตกต่างกัน) ก็$renderer->render($page)สมเหตุสมผลดี แต่หากคุณมีประเภทเพจที่แตกต่างกันซึ่งควรแสดงผลแตกต่างกัน$page->render()อาจจะดีกว่า หากผลลัพธ์ขึ้นอยู่กับประเภทหน้าเว็บและกลยุทธ์การแสดงผลคุณสามารถส่งสองครั้งผ่านรูปแบบผู้เข้าชม

อย่าลืมว่าในหลาย ๆ ภาษาฟังก์ชั่นไม่จำเป็นต้องเป็นวิธีการ ฟังก์ชั่นที่เรียบง่ายเช่นrender($page)ถ้ามักจะเป็นทางออกที่ดี (และเรียบง่ายอย่างน่าพิศวง)

อลันเคย์อ้างว่าวัตถุมีความพอเพียง "ผู้ใหญ่" และสิ่งมีชีวิตที่รับผิดชอบ ผู้ใหญ่ทำสิ่งต่าง ๆ พวกเขาไม่ได้ดำเนินการ นั่นคือธุรกรรมทางการเงินมีหน้าที่บันทึกตัวเองหน้าที่รับผิดชอบในการเรนเดอร์ตัวเองฯลฯ มีความชัดเจนมากยิ่งขึ้นการห่อหุ้มเป็นเรื่องใหญ่ใน OOP โดยเฉพาะอย่างยิ่งแสดงออกผ่านการบอกเล่าที่มีชื่อเสียงไม่ได้ถามหลักการ (ที่ @CandiedOrange ชอบที่จะพูดถึงตลอดเวลา :)) และตำหนิของประชาชนgetters และ setters

ในทางปฏิบัติจะส่งผลให้วัตถุมีทรัพยากรที่จำเป็นทั้งหมดในการทำงานเช่นฐานข้อมูลสิ่งอำนวยความสะดวกการแสดงผล ฯลฯ

ดังนั้นเมื่อพิจารณาตัวอย่างของคุณเวอร์ชัน OOP ของฉันจะมีลักษณะดังนี้:

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

ในกรณีที่คุณสนใจเดวิดเวสต์พูดคุยเกี่ยวกับหลักการ OOP เดิมในหนังสือของเขาคิดวัตถุ

$page->renderMe();

ที่นี่เรามีpageความรับผิดชอบอย่างสมบูรณ์สำหรับการแสดงผลของตัวเอง มันอาจจะมาพร้อมกับการแสดงผลผ่านตัวสร้างหรือมันอาจมีฟังก์ชั่นที่สร้างขึ้นมา

ฉันจะละเว้นกรณีแรก (มาพร้อมกับการแสดงผลผ่านตัวสร้าง) ที่นี่เพราะมันค่อนข้างคล้ายกับการผ่านมันเป็นพารามิเตอร์ แต่ฉันจะดูข้อดีข้อเสียของฟังก์ชั่นที่สร้างขึ้น

มืออาชีพคือมันช่วยให้ encapsulation ในระดับสูงมาก หน้าเว็บไม่จำเป็นต้องเปิดเผยอะไรเลยเกี่ยวกับสถานะด้านในโดยตรง มันเปิดเผยผ่านการแสดงผลของตัวเองเท่านั้น

คอนดิชั่นคือมันทำลายหลักการความรับผิดชอบเดียว (SRP) เรามีคลาสที่รับผิดชอบในการห่อหุ้มสถานะของเพจและยังมีการกำหนดรหัสอย่างเข้มงวดเกี่ยวกับวิธีการแสดงผลตัวเองและน่าจะเป็นหน้าที่ความรับผิดชอบอื่น ๆ อีกมากมายเนื่องจากวัตถุควร "ทำสิ่งต่าง ๆ ให้กับตัวเอง "

$page->renderMe($renderer);

ที่นี่เรายังคงต้องการหน้าเพื่อให้สามารถแสดงผลได้เอง แต่เรากำลังจัดหาหน้าที่มีออบเจกต์ตัวช่วยที่สามารถทำการเรนเดอร์จริง สองสถานการณ์สามารถเกิดขึ้นได้ที่นี่:

1. หน้าเพียงแค่ต้องรู้กฎการแสดงผล (วิธีการที่จะเรียกตามลำดับ) เพื่อสร้างการแสดงผลที่ Encapsulation ถูกเก็บรักษาไว้ แต่ SRP ยังคงใช้งานไม่ได้เนื่องจากหน้ายังคงต้องดูแลกระบวนการแสดงผลหรือ
2. หน้าเรียกวิธีการเดียวบนวัตถุของ renderer ส่งผ่านรายละเอียดมาเราเข้าใกล้การเคารพ SRP มากขึ้น แต่ตอนนี้เราได้ลดการห่อหุ้ม

$renderer->renderPage($page);

ที่นี่เราเคารพ SRP อย่างสมบูรณ์ วัตถุหน้ามีหน้าที่รับผิดชอบในการเก็บข้อมูลบนหน้าและ renderer รับผิดชอบในการแสดงผลหน้านั้น อย่างไรก็ตามตอนนี้เราได้ทำให้การห่อหุ้มของหน้าวัตถุอ่อนแอลงอย่างสมบูรณ์เนื่องจากต้องการทำให้ทั้งรัฐเป็นสาธารณะ

นอกจากนี้เราได้สร้างปัญหาใหม่: โปรแกรมแสดงภาพอยู่ในระดับเดียวกันกับคลาสของหน้าเว็บอย่างแน่นหนา จะเกิดอะไรขึ้นเมื่อเราต้องการแสดงสิ่งที่แตกต่างจากหน้า

ไหนดีที่สุด ไม่มีของพวกเขา พวกเขามีข้อบกพร่อง

คำตอบสำหรับคำถามนี้ชัดเจน มันคือ$renderer->renderPage($page);การดำเนินการที่ถูกต้อง เพื่อให้เข้าใจว่าเรามาถึงข้อสรุปนี้เราต้องเข้าใจการห่อหุ้ม

หน้าคืออะไร? มันเป็นตัวแทนของจอแสดงผลที่ใครบางคนจะใช้ "คน" นั้นอาจเป็นมนุษย์หรือบอท โปรดทราบว่าการPageเป็นตัวแทนและไม่แสดงตัวเอง มีตัวแทนอยู่โดยไม่มีตัวแทนหรือไม่? เป็นหน้าเว็บที่ไม่มีตัวเรนเดอร์หรือไม่ คำตอบคือใช่การเป็นตัวแทนสามารถอยู่ได้โดยไม่ต้องเป็นตัวแทน เพื่อเป็นตัวแทนของเวทีต่อมา

renderer ที่ไม่มีหน้าคืออะไร? renderer สามารถแสดงโดยไม่มีหน้าได้หรือไม่? ไม่ดังนั้นอินเทอร์เฟซ Renderer จึงต้องการrenderPage($page);วิธีการ

มีอะไรผิดปกติกับ$page->renderMe($renderer);?

มันเป็นความจริงที่ว่าจะยังคงมีการเรียกร้องภายในrenderMe($renderer) $renderer->renderPage($page);สิ่งนี้ละเมิดกฎหมายของ Demeterซึ่งระบุ

แต่ละหน่วยควรมีความรู้ จำกัด เกี่ยวกับหน่วยอื่น ๆ เท่านั้น

Pageชั้นไม่สนใจว่ามีอยู่Rendererในจักรวาล มันสนใจเพียงแค่การเป็นตัวแทนของหน้า ดังนั้นชั้นเรียนหรืออินเตอร์เฟซที่ไม่ควรจะกล่าวถึงภายในRendererPage

ปรับปรุงคำตอบ

หากฉันได้รับคำถามของคุณถูกต้องPageSnippetชั้นควรจะเกี่ยวข้องกับการเป็นตัวอย่างของหน้า

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

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

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

PdfRenderer เกี่ยวข้องกับการแสดงผล

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

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

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

การใช้งานของลูกค้า

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

ข้อควรพิจารณา:

• การปฏิบัติที่ไม่ดีในการผ่าน$dataเป็นอาร์เรย์เชื่อมโยง ควรเป็นตัวอย่างของคลาส
• ข้อเท็จจริงที่ว่ารูปแบบหน้ามีอยู่ภายในhtmlคุณสมบัติของ$dataอาร์เรย์นั้นเป็นรายละเอียดเฉพาะสำหรับโดเมนของคุณและPageSnippetรับทราบรายละเอียดนี้

เป็นการดีที่คุณต้องการการพึ่งพาระหว่างคลาสน้อยที่สุดเท่าที่จะทำได้เนื่องจากมันลดความซับซ้อน คลาสควรมีการขึ้นต่อกันของคลาสอื่นหากจำเป็นจริงๆ

คุณระบุว่าPageมี "ชุดคำสั่งสำหรับตัวแสดงหน้า" ฉันจินตนาการถึงสิ่งนี้:

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

ดังนั้นจึงเป็น$page->renderMe($renderer)เพราะเพจต้องการการอ้างอิงไปยังโหมดแสดงภาพ

แต่คำแนะนำในการเรนเดอร์ก็สามารถแสดงเป็นโครงสร้างข้อมูลแทนการโทรโดยตรงเช่น

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

ในกรณีนี้ Renderer จริงจะได้รับโครงสร้างข้อมูลนี้จากหน้าและประมวลผลโดยดำเนินการตามคำแนะนำการแสดงผลที่สอดคล้องกัน ด้วยวิธีการดังกล่าวการพึ่งพาจะถูกย้อนกลับ - หน้าไม่จำเป็นต้องรู้เกี่ยวกับ Renderer แต่ Renderer ควรให้เพจที่สามารถแสดงผลได้ ดังนั้นตัวเลือกที่สอง:$renderer->renderPage($page);

แล้วอันไหนดีที่สุด? วิธีแรกอาจเป็นวิธีที่ง่ายที่สุดในการใช้งานในขณะที่วิธีที่สองนั้นมีความยืดหยุ่นและมีประสิทธิภาพมากกว่าดังนั้นฉันคิดว่ามันขึ้นอยู่กับความต้องการของคุณ

หากคุณไม่สามารถตัดสินใจได้หรือคุณคิดว่าคุณอาจเปลี่ยนวิธีการในอนาคตคุณสามารถซ่อนการตัดสินใจที่อยู่เบื้องหลังเลเยอร์ทางอ้อมซึ่งเป็นฟังก์ชัน:

renderPage($page, $renderer)

วิธีเดียวที่ฉันจะไม่แนะนำคือ$page->renderMe()เพราะมันแนะนำว่าหน้าเว็บสามารถมีโหมดแสดงภาพเดียวได้ แต่ถ้าคุณมีScreenRendererและเพิ่มPrintRenderer? หน้าเดียวกันอาจแสดงผลโดยทั้งคู่

D ส่วนหนึ่งของ SOLIDกล่าวว่า

"Abstractions ไม่ควรขึ้นอยู่กับรายละเอียดรายละเอียดควรขึ้นอยู่กับ abstractions"

ดังนั้นระหว่างหน้าและ Renderer ซึ่งมีแนวโน้มที่จะเป็นนามธรรมที่มั่นคงมีโอกาสน้อยที่จะเปลี่ยนแปลงอาจเป็นตัวแทนของอินเตอร์เฟซ? ตรงกันข้าม "รายละเอียด" คืออะไร?

จากประสบการณ์ของฉันสิ่งที่เป็นนามธรรมมักจะเป็น Renderer ตัวอย่างเช่นมันอาจเป็น Stream หรือ XML แบบนามธรรมและเสถียร หรือบางรูปแบบมาตรฐานค่อนข้าง หน้าของคุณมีแนวโน้มที่จะเป็นวัตถุทางธุรกิจที่กำหนดเองซึ่งเป็น "รายละเอียด" และคุณมีวัตถุทางธุรกิจอื่น ๆ ที่จะแสดงผลเช่น "รูปภาพ", "รายงาน", "แผนภูมิ" ฯลฯ ... (อาจไม่ใช่ "tryptich" ดังที่แสดงความคิดเห็นของฉัน)

แต่เห็นได้ชัดว่ามันขึ้นอยู่กับการออกแบบของคุณ หน้าอาจเป็นนามธรรมตัวอย่างเช่นเทียบเท่าของ<article>แท็กHTML ที่มีส่วนย่อยมาตรฐาน และคุณมี "renderers" การรายงานทางธุรกิจที่กำหนดเองต่าง ๆ มากมาย ในกรณีนั้น Renderer ควรขึ้นอยู่กับหน้า

ฉันคิดว่าคลาสส่วนใหญ่สามารถแบ่งออกเป็นสองประเภท:

• คลาสที่มีข้อมูล (ไม่แน่นอนหรือไม่เปลี่ยนรูปไม่สำคัญ)

เหล่านี้เป็นชั้นเรียนที่แทบไม่มีการพึ่งพากับสิ่งอื่นใด โดยทั่วไปจะเป็นส่วนหนึ่งของโดเมนของคุณ พวกเขาไม่ควรมีตรรกะหรือตรรกะเท่านั้นที่สามารถได้รับโดยตรงจากรัฐ คลาส Employee สามารถมีฟังก์ชั่นisAdultที่สามารถรับโดยตรงจากมันbirthDateแต่ไม่ใช่ฟังก์ชั่นhasBirthDayที่ต้องใช้ข้อมูลภายนอก (วันที่ปัจจุบัน)

• คลาสที่ให้บริการ

คลาสเหล่านี้ทำงานกับคลาสอื่นที่มีข้อมูล โดยทั่วไปจะมีการกำหนดค่าครั้งเดียวและไม่เปลี่ยนรูป (ดังนั้นพวกเขาจึงทำหน้าที่ชนิดเดียวกันเสมอ) คลาสเหล่านี้อาจยังให้อินสแตนซ์ตัวช่วยอายุสั้น stateful เพื่อทำการดำเนินการที่ซับซ้อนมากขึ้นที่ต้องการรักษาสถานะบางอย่างในช่วงเวลาสั้น ๆ (เช่นคลาสตัวสร้าง)

ตัวอย่างของคุณ

ในตัวอย่างของคุณPageจะเป็นคลาสที่มีข้อมูล มันควรมีฟังก์ชั่นในการรับข้อมูลนี้และอาจแก้ไขได้ถ้าคลาสนั้นควรจะไม่แน่นอน เก็บไว้เป็นใบ้ดังนั้นจึงสามารถใช้งานได้โดยไม่ต้องพึ่งพาอะไรมากมาย

ข้อมูลหรือในกรณีนี้คุณPageสามารถแสดงได้หลายวิธี มันสามารถแสดงผลเป็นหน้าเว็บเขียนลงดิสก์เก็บไว้ในฐานข้อมูลแปลงเป็น JSON อะไรก็ตาม คุณไม่ต้องการเพิ่มวิธีการในชั้นเรียนดังกล่าวสำหรับแต่ละกรณี (และสร้างการอ้างอิงในชั้นเรียนอื่น ๆ ทุกประเภทแม้ว่าชั้นเรียนของคุณควรจะมีเพียงข้อมูล)

คุณRendererเป็นประเภทประเภทบริการทั่วไป สามารถทำงานกับข้อมูลบางชุดและส่งคืนผลลัพธ์ มันไม่ได้มีสถานะเป็นของตัวเองมากนักและมักจะมีสถานะที่ไม่เปลี่ยนรูปแบบซึ่งสามารถกำหนดค่าครั้งเดียวแล้วนำกลับมาใช้ใหม่ได้

ตัวอย่างเช่นคุณอาจมี a MobileRendererและ a StandardRendererทั้งการปรับใช้Rendererคลาส แต่มีการตั้งค่าที่แตกต่างกัน

เพื่อให้Pageมีข้อมูลและควรเก็บเป็นใบ้โซลูชันที่สะอาดที่สุดในกรณีนี้จะส่งผ่านPageไปยัง a Renderer:

$renderer->renderPage($page)