ในโครงการ PHP มีรูปแบบใดบ้างในการจัดเก็บเข้าถึงและจัดระเบียบวัตถุตัวช่วย [ปิด]

คุณจัดระเบียบและจัดการออบเจ็กต์ตัวช่วยของคุณเช่นเอ็นจิ้นฐานข้อมูลการแจ้งเตือนผู้ใช้การจัดการข้อผิดพลาดและอื่น ๆ ในโครงการเชิงวัตถุที่ใช้ PHP ได้อย่างไร

สมมติว่าฉันมี PHP CMS ขนาดใหญ่ CMS จัดอยู่ในชั้นเรียนต่างๆ ตัวอย่างบางส่วน:

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

เป็นต้น

ฉันกำลังเผชิญกับคำถามนิรันดร์วิธีทำให้วัตถุเหล่านี้สามารถเข้าถึงได้ดีที่สุดในแต่ละส่วนของระบบที่ต้องการ

apporach แรกของฉันเมื่อหลายปีก่อนคือการมี $ application global ที่มีอินสแตนซ์เริ่มต้นของคลาสเหล่านี้

global $application;
$application->messageHandler->addMessage("Item successfully inserted");

จากนั้นฉันเปลี่ยนเป็นรูปแบบ Singleton และฟังก์ชั่นโรงงาน:

$mh =&factory("messageHandler");
$mh->addMessage("Item successfully inserted");

แต่ฉันก็ไม่พอใจเช่นกัน การทดสอบหน่วยและการห่อหุ้มมีความสำคัญสำหรับฉันมากขึ้นเรื่อย ๆ และในความเข้าใจตรรกะที่อยู่เบื้องหลังลูกโลก / เสื้อกล้ามทำลายแนวคิดพื้นฐานของ OOP

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

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

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

นอกจากนี้ฉันสนใจที่จะได้ยินเกี่ยวกับวิธีการเฉพาะทางเฉพาะเจาะจงหรือวิธีการแปลก ๆสำหรับปัญหานี้

ฉันจะหลีกเลี่ยงแนวทาง Singleton ที่ Flavius ​​แนะนำ มีเหตุผลมากมายที่จะหลีกเลี่ยงแนวทางนี้ มันละเมิดหลักการ OOP ที่ดี บล็อกการทดสอบของ Google มีบทความดีๆเกี่ยวกับ Singleton และวิธีหลีกเลี่ยง:

http://googletesting.blogspot.com/2008/08/by-miko-hevery-so-you-join-new-project.html http://googletesting.blogspot.com/2008/05/tott-using-dependancy -injection-to.html http://googletesting.blogspot.com/2008/08/where-have-all-singletons-gone.html

ทางเลือก

1. ผู้ให้บริการ

   http://java.sun.com/blueprints/corej2eepatterns/Patterns/ServiceLocator.html

2. การฉีดพึ่งพา

   http://en.wikipedia.org/wiki/Dependency_injection

   และคำอธิบาย php:

   http://components.symfony-project.org/dependency-injection/trunk/book/01-Dependency-Injection

นี่เป็นบทความที่ดีเกี่ยวกับทางเลือกเหล่านี้:

http://martinfowler.com/articles/injection.html

การใช้การฉีดพึ่งพา (DI):

• ฉันเชื่อว่าคุณควรถามสิ่งที่จำเป็นในตัวสร้างเพื่อให้วัตถุทำงาน :new YourObject($dependencyA, $dependencyB);

• คุณสามารถระบุอ็อบเจ็กต์ที่ต้องการ (การอ้างอิง) ด้วยตนเอง ( $application = new Application(new MessageHandler()) แต่คุณยังสามารถใช้เฟรมเวิร์ก DI (หน้าวิกิพีเดียมีลิงก์ไปยังเฟรมเวิร์ก PHP DI )

  สิ่งสำคัญคือคุณส่งผ่านเฉพาะสิ่งที่คุณใช้จริงเท่านั้น (เรียกการดำเนินการ) ไม่ใช่สิ่งที่คุณส่งผ่านไปยังวัตถุอื่นเพราะต้องการ นี่คือการโพสต์ล่าสุดจาก 'ลุงบ๊อบ (โรเบิร์ตมาร์ติน) พูดคุยDI คู่มือเทียบโดยใช้กรอบ

ความคิดเพิ่มเติมเกี่ยวกับการแก้ปัญหาของ Flavius ฉันไม่ต้องการให้โพสต์นี้เป็นการต่อต้านโพสต์ แต่ฉันคิดว่าสิ่งสำคัญคือต้องดูว่าทำไมการฉีดแบบพึ่งพาจึงดีกว่า globals

แม้ว่าจะไม่ใช่การใช้งานSingleton แบบ 'จริง' แต่ฉันก็ยังคิดว่า Flavius ​​เข้าใจผิด รัฐทั่วโลกจะไม่ดี โปรดทราบว่าโซลูชันดังกล่าวยังใช้วิธีการทดสอบแบบคงที่ที่ยากด้วย

ฉันรู้ว่าหลายคนทำมันอนุมัติและใช้มัน แต่การอ่านบทความบล็อกของ Misko Heverys ( ผู้เชี่ยวชาญด้านการทดสอบของ Google ) การอ่านซ้ำและการย่อยสิ่งที่เขาพูดอย่างช้าๆได้เปลี่ยนวิธีที่ฉันเห็นการออกแบบมาก

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

ฉันยังคงดิ้นรนกับข้อมูลทั้งหมดที่ได้รับจากบล็อกนั้นและไม่ใช่เรื่องง่ายเสมอไปที่จะนำไปใช้และฉันมีคำถามมากมาย แต่ไม่มีทางที่ฉันจะย้อนกลับไปในสิ่งที่ฉันเคยทำมาก่อน (ใช่ global state และ Singletons (big S)) หลังจากที่ฉันเข้าใจสิ่งที่ Misko Hevery พูด :-)

class Application {
    protected static $_singletonFoo=NULL;

    public static function foo() {
        if(NULL === self::$_singletonFoo) {
            self::$_singletonFoo = new Foo;
        }
        return self::$_singletonFoo;
    }

}

นี่คือวิธีที่ฉันทำ สร้างวัตถุตามความต้องการ:

Application::foo()->bar();

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

หมายเหตุ : สิ่งที่ฉันนำเสนอไม่ใช่รูปแบบซิงเกิลตันจริงๆ ซิงเกิลตันจะอนุญาตอินสแตนซ์เดียวเท่านั้นโดยกำหนดคอนสตรัคเตอร์ (Foo :: __ constructor ()) เป็นไพรเวต เป็นเพียงตัวแปร "ส่วนกลาง" ที่ใช้ได้กับอินสแตนซ์ "แอปพลิเคชัน" ทั้งหมด นั่นเป็นเหตุผลที่ฉันคิดว่าการใช้งานนั้นถูกต้องเนื่องจากไม่ได้ละเลยหลักการ OOP ที่ดี แน่นอนว่าไม่ควรใช้ "รูปแบบ" นี้มากเกินไปเช่นเดียวกับสิ่งใดในโลก!

ฉันเคยเห็นสิ่งนี้ถูกใช้ใน PHP frameworks, Zend Framework และ Yii ในหมู่พวกเขา และคุณควรใช้กรอบ ฉันจะไม่บอกคุณว่าอันไหน

ภาคผนวก สำหรับคนที่คุณกังวลเกี่ยวกับTDDคุณยังคงสามารถสร้างสายไฟเพื่อพึ่งพาการฉีดได้ อาจมีลักษณะดังนี้:

class Application {
        protected static $_singletonFoo=NULL;
        protected static $_helperName = 'Foo';

        public static function setDefaultHelperName($helperName='Foo') {
                if(is_string($helperName)) {
                        self::$_helperName = $helperName;
                }
                elseif(is_object($helperName)) {
                        self::$_singletonFoo = $helperName;
                }
                else {
                        return FALSE;
                }
                return TRUE;
        }
        public static function foo() {
                if(NULL === self::$_singletonFoo) {
                        self::$_singletonFoo = new self::$_helperName;
                }
                return self::$_singletonFoo;
        }
}

มีพื้นที่เพียงพอสำหรับการปรับปรุง เป็นเพียง PoC ใช้จินตนาการของคุณ

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

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

"กฎ" ที่ตายตัวเช่น "เสื้อกล้ามไม่ดี" เป็นที่มาของความชั่วร้ายสำหรับคนขี้เกียจไม่เต็มใจที่จะคิดเอง

ใช่ฉันรู้ว่า PHP manifesto นั้นไม่ดีในทางเทคนิค แต่มันเป็นภาษาที่ประสบความสำเร็จในทางแฮ็ก

ภาคผนวก

รูปแบบฟังก์ชันเดียว:

function app($class) {
    static $refs = array();

    //> Dependency injection in case of unit test
    if (is_object($class)) {
        $refs[get_class($class)] = $class;
        $class = get_class($class);
    }

    if (!isset($refs[$class]))
        $refs[$class] = new $class();

    return $refs[$class];
}

//> usage: app('Logger')->doWhatever();

ฉันชอบแนวคิดของ Dependency Injection:

"Dependency Injection คือส่วนประกอบที่ได้รับการพึ่งพาผ่านตัวสร้างวิธีการหรือลงในช่องโดยตรง (จากเว็บไซต์ Pico Container )"

Fabien Potencier เขียนบทความที่ดีมากเกี่ยวกับ Dependency Injectionและความจำเป็นในการใช้งาน นอกจากนี้เขายังมี Dependency Injection Container ขนาดเล็กที่ชื่อPimpleซึ่งฉันชอบใช้มาก (ข้อมูลเพิ่มเติมเกี่ยวกับgithub )

ตามที่ระบุไว้ข้างต้นฉันไม่ชอบการใช้ Singletons สรุปที่ดีเกี่ยวกับเหตุผลที่ Singletons ไม่ได้ออกแบบที่ดีสามารถพบได้ที่นี่ในบล็อกของสตีฟเย็กจของ

แนวทางที่ดีที่สุดคือการมีภาชนะสำหรับทรัพยากรเหล่านั้น วิธีที่ใช้บ่อยที่สุดในการนำคอนเทนเนอร์นี้ไปใช้:

ซิงเกิล

ไม่แนะนำเนื่องจากเป็นการยากที่จะทดสอบและบ่งบอกถึงสถานะทั่วโลก (Singletonitis)

Registry

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

มรดก

น่าเสียดายที่ไม่มีการสืบทอดหลายอย่างใน PHP ดังนั้นสิ่งนี้จึง จำกัด อยู่ในห่วงโซ่ทั้งหมด

การฉีดยาแบบพึ่งพา

นี่เป็นแนวทางที่ดีกว่า แต่เป็นหัวข้อที่ใหญ่กว่า

แบบดั้งเดิม

วิธีที่ง่ายที่สุดในการทำเช่นนี้คือการใช้ constructor หรือ setter injection (ส่งผ่านอ็อบเจกต์การขึ้นต่อกันโดยใช้ setter หรือใน class constructor)

กรอบ

คุณอาจหมุนหัวฉีดพึ่งพาของคุณเองหรือใช้กรอบการฉีดพึ่งพาบางอย่างเช่น Yadif

ทรัพยากรแอปพลิเคชัน

คุณสามารถเริ่มต้นทรัพยากรแต่ละรายการใน bootstrap ของแอปพลิเคชัน (ซึ่งทำหน้าที่เป็นคอนเทนเนอร์) และเข้าถึงได้จากทุกที่ในแอปที่เข้าถึงวัตถุ bootstrap

นี่คือแนวทางที่นำไปใช้ใน Zend Framework 1.x

ตัวโหลดทรัพยากร

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

ฉีดไปยังชั้นเฉพาะ

ทรัพยากรไม่จำเป็นต้องใช้ทุกที่ในแอปพลิเคชัน บางครั้งคุณแค่ต้องการมันเช่นในคอนโทรลเลอร์ (MV C ) จากนั้นคุณสามารถฉีดทรัพยากรเฉพาะที่นั่น

วิธีการทั่วไปในการนี้คือการใช้ความคิดเห็น docblock เพื่อเพิ่มข้อมูลเมตาของการฉีด

ดูแนวทางของฉันที่นี่:

จะใช้การฉีดพึ่งพาใน Zend Framework ได้อย่างไร? - กองล้น

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

แอปพลิเคชันอาจมีขนาดใหญ่มากและการโหลดทรัพยากรทั้งหมดตามคำขอแต่ละครั้งมีราคาแพงมาก มีหลายวิธีรวมทั้งนี้PHP AppServer ใน - โครงการโฮสติ้งใน Google Code

หากคุณต้องการทำให้วัตถุพร้อมใช้งานทั่วโลกรูปแบบรีจิสทรีอาจน่าสนใจสำหรับคุณ สำหรับแรงบันดาลใจมีลักษณะที่Zend Registry

ดังนั้นคำถามRegistry vs. Singleton

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

1) วัตถุอาจมีวิธีการที่มีประโยชน์มากมายหรือจำเป็นต้องเรียกมากกว่าหนึ่งครั้งในกรณีนี้ฉันใช้ซิงเกิลตัน / รีจิสตรี:

$object = load::singleton('classname');
//or
$object = classname::instance(); // which sets self::$instance = $this

2) อ็อบเจ็กต์มีอยู่ตลอดอายุของเมธอด / ฟังก์ชันที่เรียกใช้ซึ่งในกรณีนี้การสร้างอย่างง่ายจะเป็นประโยชน์ในการป้องกันไม่ให้การอ้างอิงอ็อบเจ็กต์ค้างอยู่นานเกินไป

$object = new Class();

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

ฉันจะไปฟังก์ชั่นที่ส่งคืนวัตถุเริ่มต้น:

A('Users')->getCurrentUser();

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

ทำไมไม่อ่านคู่มืออย่างละเอียดล่ะ?

http://php.net/manual/en/language.oop5.autoload.php