[T]issues 2.1

- I –

เพิ่มฟีเจอร์ บั๊ก แก้บั๊ก, เพิ่มฟีเจอร์ บั๊ก แก้บั๊ก, เพิ่มฟีเจอร์ บั๊ก แก้บั๊ก…

วงจร (อุบาทว์) สามัญที่โปรแกรมเมอร์ทุกคนต้องพบเจอ ไม่ว่าจะเทพมาจากไหนหากก้าวเดินบนทางสายนี้คงเจอกับตัวเองไม่มากก็น้อย

"ผมเขียนโปรแกรมเป็น OO นะพี่ มี Class แบ่ง namespace เป็นระเบียบเรียบร้อย มี Method เซ็ตเก็ต ใส่ private/protected/public ครบถ้วน – แล้วทำไมยิ่งเพิ่มฟีเจอร์ยิ่งมีบั๊กล่ะครับ?"

"ตอนเรียนอาจารย์ก็บอกว่า OO ดียังงั้น OO ดียังงี้ ไอ้ผมก็เชื่อ ทำตามที่จานสอนเป๊ะๆเลยเนี่ย ไม่เห็นมันจะช่วยอะไรเลย?"

หรืออาจารย์ซุงแหล…

หรือคุณเข้าใจอะไรผิด…

- II –

สมัยผมเรียนป.ตรี วิชา OOP เป็นไฟต์บังคับที่นักศึกษา Computer Science ทุกคนต้องชก โชคดีที่ผม (และเพื่อนๆ) เป็นเด็กหน่อมแน้มไม่เคยเขียนโปรแกรมกันมาก่อน เลยไม่รู้ว่าไอ้การเขียนแบบ procedural นี่มันเป็นยังไง – ธาตุไฟจึงไม่เข้าแทรกตอนดูดซึมเคล็ดวิชา Object-Oriented จากอาจารย์

เคล็ดวิชาที่อาจารย์กรอกเข้าหู (ซ้ายทะลุหูขวา) ยังท่องจำไม่ตกหล่น

• Encapsulation
• Inheritance
• Polymorphism

ผ่านวันนั้นมาก็นานพอสมควร เหล่าจอมยุทธ์ต่างโลดแล่นไปบนยุทธจักร software development แต่ไม่ว่าวรยุทธ์จะแก่กล้าสักเพียงใดก็ไม่อาจหลีกพ้นจากศัตรูตัวฉกาจ เจ้า Bug ตัวร้าย

หรือศัตรูที่แท้จริงอาจไม่ใช่บั๊ก… แต่เป็นตัวเราเอง

วรยุทธ์ตามสัญชาติญาณ ไฉนเลยจะเข้าถึงแก่นแท้…

Object-Oriented คืออะไรกันแน่?

- III –

พอมีโอกาสได้อ่านหนังสือ Object-Oriented Design Heuristics ของ Arthur J. Reil เลยเกิดอาการพร่ำเพ้อตามข้างต้นครับ เริ่มรู้สึกตัวว่าออกแบบ/เขียนโปรแกรมไปตาม instinct มากขึ้นเรื่อยๆ จึงต้องหวนคืนสู่สามัญกลับมาถามตัวเองว่าที่คิด/เขียนออกไป มันมีเหตุผลอะไรมารองรับหรือเปล่า?

หนังสือเล่มนี้เป็น complement ของ Design Patterns ครับ ถึงจะเขียนมานานแล้ว (ปี 1996 – ประมาณ 12 ปีที่แล้ว) แต่เนื้อหายังทันสมัยอยู่

คำว่า Heuristic ถอดความตามพจนานุกรม babylon 6 เวอร์ชั่นแครกได้ดังนี้

"หลักการจากสามัญสำนึกเพื่อเพิ่มความเป็นไปได้ของการหาวิธีการแก้ปัญหา "

Heuristic อันนึงจะเป็นข้อความสั้นๆประมาณ 1 – 2 บรรทัด พร้อมคำอธิบาย ลองมาดูตัวอย่างกัน

Heuristic 2.1

All data should be hidden within its class.

อันนี้ตรงตามเคล็ดวิชาข้อแรกเป๊ะๆเลย encapsulation

Heuristic 5.4

In theory, inheritance hierarchies should be deep—the deeper, the better.

การออกแบบให้มี hierarchy หลายชั้นนั้น ทางทฤษฎีถือว่าคุณยิ่งเพิ่ม abstraction ให้กับคลาส แปลว่าในคลาสหนึ่งจะมี data/behavior อยู่ไม่มาก – ซึ่งถือว่ายิ่งดี

ยกตัวอย่างเช่น คลาส Living มีเม็มเบอร์คือ age อาจจะมีเมทอดที่สิ่งมีชีวิตทั่วๆไปทำได้เช่น กิน ขี้ xxx นอน จากนั้นซับคลาสมาเป็น Animal กับ Human ซึ่งมีวิธีกิน ขี้ xxx นอน แตกต่างกัน (แต่ xxx อาจไม่ต่างกัน) อาจจะเพิ่มเมทอด work เข้าไป แล้วค่อยซับเป็นอาชีพต่างๆที่มีวิธีทำงานต่างกัน แล้วค่อยซับอีก เป็นต้น

Heuristic 5.5

In practice, inheritance hierarchies should be no deeper than an average person can keep in his or her short-term memory. A popular value for this depth is six.

แต่ในชีวิตจริงมันไม่ง่ายอย่างนั้น – นึกภาพเวลาเอาคลาสเล่านั้นไปใชสิครับ ยิ่งมี hierarchy ลึกเท่าไหร่คนใช้ย่อมงงเป็นไก่ตาแตกเท่านั้น ไม่รู้จะเอาอันไหนมาใช้ดี

ผู้เขียนบอกไว้ว่าจำนวนที่เหมาะสมเป็น 7 บวกลบ 2 – กำลังดี พอที่ก้อนเนื้อในกะโหลกน้อยๆของเราจะทำความเข้าใจตามได้สะดวก

- IV –

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

ก่อนที่จะเพิ่มฟีเจอร์ถัดไป

ก่อนจะเจอบั๊กตัวถัดไป…