การออกแบบโมเดลวัตถุโดยใช้รูปแบบขั้นพื้นฐาน

รูปแบบขั้นพื้นฐานที่เรานำเสนอในการออกแบบโครงสร้างวัตถุเป็นรูปแบบที่ใช้งานส่วนใหญ่ และปรากฏอยู่ในระบบงานที่เป็น Object-Oriented เกือบทุกระบบงาน ซึ่งจะมีรูปแบบ 8 ชนิดคือ

1.    Collection Manager                   ผู้จัดการกลุ่ม

2.    Container                                   ตู้เก็บวัตถุ

3.    Relationship Loop                     ทำความสัมพันธ์กับวัตถุที่อยู่ในตระกูลเดียวกัน

4.    Handle-Body                             ทำให้คุณสมบัติของวัตถุกลายเป็นวัตถุ

5.    Dynamic Schema                      วัตถุที่เก็บข้อมูลโครงสร้างของวัตถุ

6.    Shared Object Pool                   ใช้งานวัตถุร่วมกัน

คำอธิบายอย่างย่อของรูปแบบทั้ง 6 แบบนี้มีดังต่อไปนี้

1.    Collection Manager ในกรณีที่เราออกแบบให้วัตถุสร้างความสัมพันธ์กับวัตถุชนิดอื่น ด้วยจำนวนที่มากกว่าหนึ่ง หรือที่เราเรียกว่าเป็นความสัมพันธ์แบบ 1-* ทางวัตถุที่เป็นฝั่ง One ก็คือวัตถุที่มีเพียงชิ้นเดียว ถ้าเราออกแบบให้วัตถุที่เป็นชิ้นเดียวนี้ทำหน้าที่เป็นผู้ควบคุมดูแลวัตถุอีกหลาย ๆ  ชิ้นที่นำมาเชื่อมโยงอยู่ที่ตัวมัน เราจะเรียกวัตถุชิ้นเดียวนี้ว่า Collection Manager หน้าที่ของผู้จัดการกลุ่มก็คือ ผู้จัดการมีหน้าที่สร้างวัตถุที่เป็นสมาชิกที่อยู่ภายในกลุ่ม และมีหน้าที่ทำลายวัตถุที่เป็นสมาชิกเมื่อไม่ต้องการเก็บไว้ในกลุ่ม

รูปภาพ 24 ตัวอย่างการออกแบบโดยใช้ Collection Manager

ในภาพที่ 24 จะเห็นว่าเราออกแบบให้คลาส UserManager ทำหน้าที่เป็น Collection Manager ดังนั้นวัตถุ User Manager หนึ่งตัวจะควบคุมดูแลวัตถุ User หลาย ๆ  ตัว และเมื่อไรก็ตามที่เราต้องการสร้างวัตถุ User ขึ้นใหม่เราจะต้องเรียกใช้เมธอด addUser พร้อมกับให้ชื่อของผู้ใช้คนใหม่ที่ต้องการสร้างขึ้นเข้าไปให้ แล้วเมธอด addUser จะทำหน้าที่สร้างวัตถุ User ขึ้นเองภายในตัว UserManager ซึ่งไคลเอ็นต์โค้ดไม่จำเป็นต้องรับรู้กระบวนการสร้างวัตถุ User และไม่สามารถสร้างวัตถุ User ขึ้นใช้เองภายนอก

ในภาพที่ 24 จะเห็นว่าเราออกแบบให้คลาส UserManager ทำหน้าที่เป็น Collection Manager ดังนั้นวัตถุ User Manager หนึ่งตัวจะควบคุมดูแลวัตถุ User หลาย ๆ  ตัว และเมื่อไรก็ตามที่เราต้องการสร้างวัตถุ User ขึ้นใหม่เราจะต้องเรียกใช้เมธอด addUser พร้อมกับให้ชื่อของผู้ใช้คนใหม่ที่ต้องการสร้างขึ้นเข้าไปให้ แล้วเมธอด addUser จะทำหน้าที่สร้างวัตถุ User ขึ้นเองภายในตัว UserManager ซึ่งไคลเอ็นต์โค้ดไม่จำเป็นต้องรับรู้กระบวนการสร้างวัตถุ User และไม่สามารถสร้างวัตถุ User ขึ้นใช้เองภายนอก

วิธีการแบบนี้ใช้สำหรับการออกแบบทั่วไปเมื่อเกิดความสัมพันธ์แบบ 1-* เราจะพิจารณาให้วัตถุด้านที่เป็นหนึ่งทำหน้าที่เป็น Collection Manager หรือไม่ขึ้นอยู่กับข้อกำหนดของระบบงานและหลักในการแบ่งงานกันทำ[1]ระหว่างวัตถุ 

2.    Container

เมื่อไรก็ตามที่เราต้องการให้วัตถุตัวหนึ่งสามารถเก็บวัตถุอีกหลาย ๆ  ตัวไว้ภายในตัวมันเองได้ (ลักษณะเหมือนตู้เก็บของ) เราจะออกแบบให้มันทำหน้าที่เป็น Container ซึ่งมักจะนำมาประยุกต์ใช้กับความสัมพันธ์แบบ 1-* หรือ *-*

รูปภาพ 25 การออกแบบวัตถุให้เป็น Container

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

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

[1] Delegation Model

3.    Relationship Loop

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

รูปภาพ 26 แสดงการเชื่อมโยงระหว่างวัตถุชนิดเดียวกัน แต่ทำหน้าที่คนละบทบาท

ในการออกแบบที่ระดับคอนเซ็ปท์ (Conceptual Design) มักจะพบ Relationship Loop อยู่เสมอ แต่ในขณะที่ออกแบบไปถึงระดับรายละเอียด (Detailed Design) แล้ว สถาปนิกซอฟแวร์มักจะพยายามเปลี่ยน Relationship Loop ให้กลายเป็น Binary Association ระหว่างคลาสที่เป็นเจ้าของบทบาท (Role Player) กับคลาสที่เป็นบทบาท (Role) โดยใช้เทคนิคของ Handle-Body [Coplien 92] หรือใช้ดีไซน์แพทเทิร์นชื่อ Bridge [GoF 95]

รูปภาพ 27 แสดงการเปลี่ยน Relationship Loop ให้อิมพลีเมนต์ง่ายขึ้นโดยใช้ Handle-Body

4.  Handle-Body

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

รูปภาพ 28 การแยกส่วนคุณสมบัติของวัตถุออกมาเป็นวัตถุอีกตระกูลหนึ่ง

ในภาพที่ 28 จะสังเกตเห็นว่าเราสามารถดึงบทบาทของ Person แยกออกมาเป็นส่วน Handle ต่างหากจากส่วน Body ซึ่งก็คือตัว Person นั่นเอง และเนื่องจากบุคคลหนึ่งคนสามารถมีบทบาทได้หลายชนิดเราจึงสืบทอดคลาส PersonRole ต่อมาเป็นคลาส Patient และคลาส Doctor

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

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

5.  Dynamic Schema

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

รูปภาพ 29 แสดงรูปแบบการจัดโครงสร้าง Dynamic Schema

จากภาพที่ 29 ถ้าใช้เทคนิคของ Dynamic Schema จะประกอบด้วย 2 ส่วนคือส่วนที่เป็น Schema ก็คือโครงสร้างวัตถุที่เป็นแม่แบบ (Template) ให้กับวัตถุกลุ่มหนึ่ง เช่นในภาพนี้ วัตถุ Category ใช้สำหรับเป็นแม่แบบให้กับวัตถุ Part และวัตถุ Property ใช้สำหรับเป็นแม่แบบให้กับวัตถุ Attribute

รูปภาพ 30 ตัวอย่างการใช้ Inheritance กับชนิดของวัตุถุที่สามารถเกิดขึ้นใหม่ได้เรื่อย ๆ

จากภาพที่ 30 จะเห็นว่า เราสามารถสร้างตระกูลของชิ้นส่วน (Part) ให้ได้ตามที่ระบบงานต้องการ โดย ImportedPart คือชิ้นส่วนที่นำเข้ามาจากต่างประเทศ และ AsianPart คือชิ้นส่วนที่นำเข้าจากประเทศในกลุ่มอาเซียน และ JapanPart คือชิ้นส่วนที่นำเข้าจากประเทศญี่ปุ่น จากโครงสร้างดังกล่าวนี้ ถ้าในอนาคตมีประเภทของชิ้นส่วนประเภทใหม่เกิดขึ้น จะทำให้เราต้องแก้ไขโครงสร้างดังกล่าวนี้ให้สามารถรองรับประเภทใหม่ แต่เนื่องจากการแก้ไข Inhertiance เป็นเรื่องทางโปรแกรมที่ผู้ใช้ทั่วไปไม่สามารถแก้ไขได้ จะต้องให้โปรแกรมเมอร์เป็นคนแก้ไขโปรแกรมแล้วคอมไพล์โปรแกรมใหม่ ซึ่งเราจะเห็นว่าเป็นวิธีการที่ไม่สะดวกมากถ้าผู้ใช้ต้องการเพิ่มประเภทชิ้นส่วนใหม่ ๆ  เข้าไปในระบบอยู่เรื่อย ๆ

รูปภาพ 31 วิธีการนำ Dynamic Schema ตามภาพที่ 29 มาเรียกใช้ในโปรแกรม

ถ้าเราจัดโครงสร้างด้วยวิธี Dynamic Schema ตามภาพที่ 29 จะสามารถแก้ปัญหาดังกล่าวในภาพที่ 30 ได้ และเมื่อนำมาเขียนเป็นโปรแกรมเพื่อเรียกใช้งาน จะได้โปรแกรมคล้ายกับในภาพที่ 31 ซึ่งเราจะสังเกตเห็นว่าโปรแกรมในภาพที่ 31 ไม่มีการจำเพาะเจาะจงชื่อคลาสลงไปว่าเป็นชิ้นส่วนประเภทใด (สังเกตในภาพที่ 30 มีการจำเพาะเจาะจงชื่อคลาสไว้ชื่อว่า ImportedPart) และในภาพที่ 31 ไม่มีการจำเพาะเจาะจงชื่อของแอททริบิวท์ด้วย แต่ให้ค่าแอททริบิวท์เป็นสตริงหรือค่าตัวเลขที่ใส่เข้าไปในวัตถุ StringAttribute หรือวัตถุ FloatAttribute ตามลำดับ

6. Shared Object Pool

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

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

รูปภาพ 32 ตัวอย่างการใช้ Pool ที่เก็บวัตถุได้ 6 ชิ้น

จากภาพที่ 32 สังเกตว่า Pool นี้สามารถเก็บวัตถุได้เพียง 6 ชิ้น เมื่อไคลเอ็นต์ต้องการใช้งานวัตถุ ไคลเอ็นต์จะไม่ได้สร้างวัตถุขึ้นใหม่ แต่จะมาขอยืมวัตถุไปจาก Pool และเมื่อไคลเอ็นต์ใช้วัตถุนั้นเสร็จแล้วก็จะคืนกลับมาที่ Pool เพื่อให้ไคลเอ็นต์คนอื่นสามารถแบ่งปันไปใช้งานต่อได้

[1] หมายถึง CPU, หน่วยความจำ, จำนวน Network Connection, พื้นที่ว่างในฮาร์ดดิสก์, จำนวน Service Thread