ความคิดที่เป็น OOP กรณีตัวอย่างที่ 1

สวัสดีครับเพื่อนๆ ผมไม่ได้เขียนบล็อกตั้งนาน ก็จะแชร์สิ่งที่ทราบมาอยู่ 2 เรื่องใหญ่ๆ ได้แก่การออกแบบ OOP กับ การออกแบบตารางในฐานข้อมูล มาดูเรื่อง OOP กันก่อน เข้าเรื่องเลยนะครับ
1) สมมติเรามีคลาสที่รับผิดชอบเกี่ยวกับการเคลื่อนไหวของราคา คือ
- ราคาเปิด (open price)
- ราคาปิด (close price)
- ราคาสูง (high price)
- ราคาต่ำ (low price)
ทำนองนี้ เราจะเรียกเขาว่า OCHLMovement

2) เรามีอีกคลาสรับผิดชอบเกี่ยวกับปริมาณ กล่าวคือ
- ปริมาณล่าสุด (last volume)
- ปริมาณสูงสุด (max volume)
- ปริมาณต่ำสุด (min volume)
ทำนองนี้ ซึ่งเราเรียกเขาว่า VolumeMovement
มันเป็นแค่การสมมตินะครับ เมื่อให้ทั้งสองคลาสนี้ทำงานในส่วนที่ตนรับผิดชอบ OCHLMovement จะไม่ยุ่งกับ VolumeMovement และ VolumeMovement ไม่มั่วกับ OCHLMovement ต่างก็ทำงานของตนอย่างผาสุก

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

วิธีที่ 1. โอ้ข้าเห็นแล้ว ข้ารู้ข้าเห็น โอ้ มันมีส่วนที่เป็นราคาและส่วนที่เป็นปริมาณ แสดงว่าแบบนี้คลาสอย่าง OCHLMovement กับ VolumeMovement ก็น่าจะใช้ได้ ออกแบบได้อย่างนี้
class Stock
- ochlMovement: OCHLMovement
- bidVolume: VolumeMovement
- offerVolume: VolumeMovement
- lastTradeDate: Date

หรือ วิธีที่ 2. อื่ม...คิดไม่ออก ไม่รู้ว่าระบบที่มีมีคลาสอะไรบ้าง เอ้~จะคิดแบบนั้นไปทำไม ก็สร้างมันขึ้นทื่อๆเลย จัดไปตามที่มันต้องมี class Stock
- openPrice: double
- closePrice : double
- highPrice: double
- lowPrice: double
- bidVolume: double
- offerVolume: double
- lastTradeDate: Date

มาถึงตรงนี้ผมอยากจะถามเพื่อนๆว่า วิธีการแบบไหนที่เป็น OOP หรือมีแนวทางการออกแบบไปในทิศทางของ OOP ที่ควรเป็น?
คำตอบคือ วิธีการที่ 1. มีแนวโน้มไม่เป็น OOP ครับ เพราะเป็นการนำ (ขีนเส้นใต้เลยนะ) ลักษณะอื่นที่มีผลการทำงานในลักษณะอื่นมาเป็นลักษณะของมัน ซึ่งไม่ถูกต้อง ลักษณะอื่นเหล่านั้นไม่ชัดเจนในลักษณะของมัน แม้ว่าจะให้กลไกอย่างเดียวกันได้ แต่ก็ไม่ใช่ลักษณะของสิ่งที่ควรเป็น เหตุนี้วิธีการที่ 1. นี้จึงมีแนวโน้นไม่เป็น OOP ครับ ฟันธงไปเลยว่าไม่ถูกต้อง
ดังนั้นคำตอบ วิธีการที่ 2. การคิดลักษณะของมันเพื่อเป็นตัวตนของมัน จึงเป็น OOP ที่ถูกต้องนั่นเองครับ

ทำความเข้าใจ Package

ขอให้เพื่อนๆดูวีดีโอนี้เสียก่อน แล้วหลังจากนั้นเรามาคุยกันว่า package เป็นอย่างไรนะ

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

และจากประสบการณ์ที่ผมเจอ ความเจ็บปวดเรื่องหนึ่งก็คือ package นี่แหละครับ เพราะหากคิดเรื่อง package ผิดก็จะทำให้ความหมายในการจัดหมวดหมู่ไม่เกิดขึ้น หรือจัดผิด! จะผิดพลาดอย่างไรมาดูกันครับ

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

สองขา.ไก่
สองขา.นก
สองขา.กา

สี่ขา.หมู
สี่ขา.หมา

ไร้ขา.ปลา

แล้วที่ถูกต้องจัดอย่างไร? แบบนี้ครับ

สัตว์.ไก่
สัตว์.นก
สัตว์.กา
สัตว์.หมู
สัตว์.หมา
สัตว์.ปลา

2) ผิด เพราะลำดับขนาดไม่ถูกต้อง ขนาดงั้นเหรอ? ใช่ครับขนาดของ package ไม่ถูกต้อง มาดูตัวอย่างที่ผิดกันเลย

บ้านของฉัน.ประเทศของฉัน.โลกของฉัน
myhome, mycountry, myworld

อ่าว? แล้วที่ถูกเป็นอย่างไร เป็นอย่างนี้ครับ

โลกของฉัน.ประเทศของฉัน.บ้านของฉัน
myworld.mycountry.myhome

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

com.homework.ไก่
com.homework.ห่าน
com.homework.เป็ด

สรุปว่าควรเขียน package ด้วยทุกครั้งเพื่อเป็นวินัยที่ดีให้กับตัวเองและทีมคณะครับ