คงที่ไม่ดี แต่สิ่งที่เกี่ยวกับรูปแบบโรงงาน?

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

ฉันกำลังประสบปัญหานี้: ฉันมี "บทความ" วัตถุที่สามารถมี "ตัวเลือก" (เพิ่มเติม "บทความไมโคร") ที่เชื่อมโยงกับมัน

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

จากมุมมองที่แท้จริงของฉันฉันเห็น 3 ตัวเลือก:

1) สร้างภายในบทความ:

class Article
{
    //[...]
    public function getArrOption(){
        //Build an array of Options instance.
        //return an array of Options.
    }
}

Pro:ตรงไปข้างหน้า

Const: Maintenability: ตอนนี้วัตถุบทความมีตรรกะการสร้างสำหรับวัตถุตัวเลือก ซึ่งอาจนำไปสู่การทำสำเนารหัส

2) การใช้ optionFactory

class Article
{
    //[...]
    public function getArrOption(){
        return OptionFactory::buildFromArticleId($this->getId());
    }
}

Pro:ตรรกะการสร้างไม่ได้อยู่ในคลาสของบทความ

Const:ฉันกำลังฝ่าฝืนกฎ "คงยากที่จะเยาะเย้ย" ทำให้ชั้นบทความของฉันทดสอบได้ยาก

3) แยก logics ทั้งหมด

//Build the array of Option instance in a controller somewhere, using a Factory:
$arrOption = OptionFactory::buildFromArticleId($article->getId());

Pro:บทความจัดการกับความรับผิดชอบของตนเองเท่านั้นและไม่สนใจเกี่ยวกับลิงก์ "พ่อ" ของเขาไปยังตัวเลือก สิ่งที่แยกออกจริงๆ

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

วิธีที่ดีที่สุดที่จะไปคืออะไร? (ฉันพลาดอะไรไปหรือเปล่า) ขอบคุณ

แก้ไข:

ไม่ต้องพูดถึงว่าถ้าฉันไม่สามารถโทรหาโรงงานในชั้นเรียนได้ฉันจะไม่กล้าใช้รูปแบบการเริ่มต้นขี้เกียจเกินไป ...

1. คงที่ไม่ใช่ "ไม่ดี" มันไม่สามารถถอดออกได้ คุณยังสามารถใช้งานได้โดยที่การเยาะเย้ยไม่สมเหตุสมผล

2. นั่นไม่ใช่รูปแบบจากโรงงานดูเหมือนกับรูปแบบของที่เก็บแม้ว่าอาจจะไม่ใช่ Factory เป็นที่ที่คุณมีคลาสหลายคลาสที่มีอินเทอร์เฟซ / คลาสพื้นฐานเดียวกันและคุณต้องการแยกตรรกะซึ่งเป็นตัวตัดสินว่าคลาสใดจะกลับมา พื้นที่เก็บข้อมูลได้รับข้อมูลจากพื้นที่เก็บข้อมูลโดยย่อการดำเนินการของพื้นที่เก็บข้อมูลนั้น (บทความไม่จำเป็นต้องรู้ว่าตัวเลือกของมันจะถูกเก็บไว้ในฐานข้อมูลเดียวกันอีกคนหนึ่งเป็นไฟล์ XML, ไฟล์ CSV, อะไรก็ตาม)

3. คุณได้เพิกเฉยต่อความเป็นไปได้ที่จะให้วัตถุคลาส ObjectFactory (หรือ Repository หรืออะไรก็ตาม) ในคลาสคอนสตรัคเตอร์ซึ่งมันสามารถเรียกเมธอด buildFromArticle

PHP ของฉันเป็นสนิม แต่ฉันคิดว่ามันมีลักษณะเช่นนี้:

class Article
{
    private $_option_repository;

    public function __construct($option_repository) {
        $_option_repository = $option_repository;
    }

    //[...]

    public function getArrOption(){
        return $_option_repository->buildFromArticleId($this->getId());
    }
}

ฉันคิดว่านี่เป็นการเติมเต็มข้อดีทั้งหมดของคุณข้างต้น

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

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

(1) แทนที่ทุกเหตุการณ์ของโลกด้วยการเข้าถึงตัวแปรอินสแตนซ์

(2) ปล่อยให้ตัวแปรอินสแตนซ์นั้นถูกฉีดเข้าไปในวัตถุโดยอัตโนมัติเมื่อมีการสร้างอินสแตนซ์

"Seuss: การแยกความรับผิดชอบออกจากวิธีการคงที่สำหรับการกำหนดค่าแบบละเอียด"

ลิงก์เครื่อง Wayback