Creational Patterns
จุดประสงค์
หัวข้อที่มีชื่อว่า “จุดประสงค์”Creational patterns มอบหน้าที่ในการ สร้าง object ให้กับกลไกเฉพาะที่เปลี่ยนแทนกันได้ เพื่อให้ code ส่วนที่เหลือพึ่งพา abstraction แทนที่จะพึ่งพา constructor ที่เป็นรูปธรรมโดยตรง
วิธีที่ง่ายที่สุดในการสร้าง object คือเรียก constructor ของตัวเองโดยตรง วิธีนี้ใช้ได้จนกระทั่ง code ของคุณต้องเลือกระหว่างชนิดที่เป็นรูปธรรมหลายชนิด ต้องแชร์ instance เดียวกัน ต้องประกอบ object ทีละขั้นตอนเล็ก ๆ หลายขั้น หรือต้องคัดลอก object ที่มีอยู่แล้วอย่างประหยัด ทุก ๆ new Thing() ที่กระจายอยู่ทั่ว code เบสคือการตัดสินใจที่ผูกตายตัวไว้ เปลี่ยน class เมื่อไรก็เท่ากับเปลี่ยนผู้เรียกทุกที่ Creational patterns รวบรวมการตัดสินใจเหล่านั้นไว้ในที่เดียว เพื่อให้ตรรกะการสร้างวิวัฒน์ได้โดยไม่กระเพื่อมไปถึงทุกที่ที่ใช้ผลลัพธ์
แต่ละ pattern ในโมดูลนี้โจมตีปัญหานั้นคนละแง่มุม pattern เหล่านี้ไม่ใช่คู่แข่งกัน นักออกแบบที่ช่ำชองจะหยิบตัวที่ตรงกับข้อจำกัดตรงหน้ามาใช้ และมักผสมหลายตัวเข้าด้วยกันในระบบเดียว
โครงสร้าง
หัวข้อที่มีชื่อว่า “โครงสร้าง”โมดูลนี้ครอบคลุม creational patterns คลาสสิกทั้งห้าตัวและความสัมพันธ์ระหว่างกัน
classDiagram
class CreationalPattern {
<<concept>>
+produce() Product
}
class Singleton {
+instance() Singleton
}
class FactoryMethod {
+create() Product
}
class AbstractFactory {
+createA() ProductA
+createB() ProductB
}
class Builder {
+step()
+build() Product
}
class Prototype {
+clone() Prototype
}
CreationalPattern <|.. Singleton
CreationalPattern <|.. FactoryMethod
CreationalPattern <|.. AbstractFactory
CreationalPattern <|.. Builder
CreationalPattern <|.. Prototype ภาพรวม pattern ทั้งห้า:
- Singleton — รับประกันว่า class มี instance ที่แชร์กันเพียงหนึ่งเดียว และให้ทุกคนมีจุดเข้าถึงเพียงจุดเดียว
- Factory Method — ปล่อยให้ class หลักเลื่อนการเลือกว่าจะสร้าง concrete product ตัวไหนไปให้ subclass ตัดสินใจ
- Abstract Factory — ผลิตทั้งตระกูลของ product ที่เกี่ยวข้องกันผ่าน interface เดียว เพื่อให้สมาชิกในตระกูลสอดคล้องกัน
- Builder — แยกการประกอบทีละขั้นตอนของ object ที่ซับซ้อนออกจากรูปแบบสุดท้ายของตัวเอง
- Prototype — สร้าง object ใหม่ด้วยการ clone instance ที่มีอยู่แล้วแทนที่จะสร้างขึ้นมาใหม่ตั้งแต่ต้น
ใช้เมื่อไหร่ / ข้อแลกเปลี่ยน
หัวข้อที่มีชื่อว่า “ใช้เมื่อไหร่ / ข้อแลกเปลี่ยน”- ข้อดี: ตรรกะการสร้างอยู่ในที่เดียว การสลับ implementation จึงแทบไม่ต้องแตะ code ผู้เรียก
- ข้อดี: code ผู้เรียกพึ่งพา interface ทำให้การทดสอบและการแทนที่ทำได้ง่ายขึ้น
- ข้อเสีย: ทุก pattern เพิ่มชั้นทางอ้อม สำหรับโปรแกรมเล็ก ๆ constructor ธรรมดาชัดเจนกว่า
- ข้อเสีย: หากใช้ผิดที่ pattern เหล่านี้สร้างพิธีรีตองโดยไม่ได้ประโยชน์ จงหยิบมาใช้เมื่อปัญหาเรื่องการสร้างมีอยู่จริงเท่านั้น