ช่วงบ่น
Object oriented เริ่มมาจาก Alan Kay
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."
คือประเด็นของเขา เขาอยากซ่อน State processing
คือระบบสมัยนั้นมันมี Spaghetti code เยอะ State มันพันกัน ก็เลยบอกว่า เราแยกเป็นส่วนๆ Subsystem แล้วคุยกันผ่าน Message ได้มั้ย มันจะได้การันตีได้ว่า State ตรงนี้ไม่โดนใครกระทบ (นอกจาก Interface ของส่วนนั้น)
ถ้าพูดให้เห็นภาพคือ จากโค้ดสปาเก็ตตี้ก้อนใหญ่ เราได้สปาเก็ตตี้ก้อนเล็กๆ หลายๆ ก้อน ที่การันตีว่า มันไม่พันข้ามกัน ทีนี้เวลาเราจะแก้ไขจะ Debug มันก็รู้แล้วว่ากระทบแค่ไหน ไม่เหมือนเมื่อก่อนที่มีโอกาสกระทบหมด
อันนี้คือ Essence คือ Priority อันแรก และมีผลทาง Practical ด้วย คือแก้โค้ดตรงนี้เราบอกได้ว่ามันกระทบแค่ไหน ไม่ใช่นั่งพารานอยด์ว่าจะโดนนั่นมั้ยโดนนี่มั้ย มันจำกัดจุดระวังได้ ไม่ใช่พันกันจนแค่จะแก้ Bug เล็กๆ ต้องมานั่ง QA ระบบทั้งเดือน อะไรเงี้ย
ทีนี้คือบางทีเคยไปเห็นโค้ดที่มี 2 Object ที่ Share state กันบน Global singleton โดยบอกว่าต้องแยกเป็น Object เล็กๆ ตาม Single responsibility principle แล้วแบบ แถมคุยกันแบบใช้ Design pattern อย่างหรู เราก็ได้แต่เอิ่ม.......
คือสุดท้ายคุณสร้าง Object ใหญ่กว่านี้หน่อยแต่ไม่ต้องประกาศ Global singleton แล้วมันลิมิตว่าแก้โค้ดแล้วจะกระทบแค่นี้จะดีกว่าเยอะเลยนะ ดันไปเชื่อว่าออบเจ๊กต์ต้องเล็กแล้วเอามันมามี Priority อยู่เหนือกว่า Practical implication โค้ดก็พันกันแก้ยากอ่ะครับ
คือผมว่า บางที OOP Industry มันมาไกลจนลืมแก่นบางอย่างและลืมไปว่าเราใช้มันแต่แรกเพราะอะไร
ปัญหาที่ทำให้คนคิด Coding pattern กับ Programming paradigm มีแค่นี้
"โค้ดพันกัน เพื่อนหาไม่เจอว่าโค้ดอยู่ไหน มี Bug ดูแถวไหนดี แล้วพอผ่านไปซักพักผมไม่รู้ว่าแก้ตรงนี้จะกระทบโดนเท่าที่มันควรกระทบมั้ย ทำไงดี"
ทั้งหมดมันมาตอบคำถามนี้แหละ ซึ่งใครตอบคำถามนี้ได้อย่างหมดจด ทีมคุณจะ Productive มากๆ จนมี Unfair advantage เลยแหละ