ทุกวันนี้เราอยู่ในยุคของการเขียนโปรแกรมแบบ Object-Oriented ภาษาไหนๆก็เป็นภาษาแบบออบเจกต์แทบทั้งนั้น ไม่ว่าจะเป็น Java, Ruby, Python, PHP, JavaScript หรืออื่นๆล้วนแล้วแต่เขียนเป็นออบเจกต์ได้ทั้งนั้น (บางภาษาอาจเป็นได้มากกว่า Object-Oriented) แต่แล้วการเขียนโปรแกรมแบบ Object-Oriented มันคืออะไรกันแน่? หลายคนยังคงหาคำตอบไม่ได้ อ่านหนังสือก็แล้ว เรียนในห้องมาก็แล้ว หรือแม้แต่ทำงานเขียนโปรแกรมอยู่แล้ว ก็ยังไม่รู้ว่าจริงๆแล้วมันคืออะไร เราได้อะไรจากมัน แล้วที่เราเขียนอยู่นี้หล่ะ ใช่เขียนเป็นออบเจกต์รึเปล่า!!! ในบทความนี้ผมจะอธิบายให้คุณเห็นว่าแท้จริงแล้วมันคืออะไร มันอาจไม่ใช่ที่เราเคยเข้าใจกันมาหรือมันอาจง่ายกว่าที่เราคิดไว้ก็ได้ แล้วตกลง OOP คืออะไรกันแน่ ? บางคนก็ว่ามันคือการเขียนโปรแกรมเชิงวัตถุ ก็แน่หล่ะก็นี่คือคำแปลตรงตามตัวเลยนิครับ บ้างก็ว่ามันคือ Encapsulation, Inheritance, Polymorphism อันนี้ยิ่งไปกันใหญ่ ถามว่าถูกมั๊ย มันก็ไม่ผิดอะไร เพราะเรียน OOP ทีไรก็มีชื่อเท่ๆเหล่านี้เสมอ แต่แล้วเจ้าชื่อเรียกเท่ๆยาวๆเหล่านั้นมันคืออะไร? เราได้อะไรจากมัน? ตอบได้ไหมครับ? ลืมมันไปก่อนเถอะครับ มันเป็นแค่ฟีเจอร์ทางภาษาเท่านั้น เพราะถึงแม้คุณจะเขียนโค้ด Abstract, Polymorphism หรืออื่นๆ คุณก็ไม่ได้ประโยชน์อะไรจากมันถ้าคุณยังไม่เข้าใจหัวใจหลัก (BASIC PRINCIPLE) ของ OOP ยกตัวอย่างเช่น คุณใส่ฟีเจอร์ทางภาษาเข้าไป แต่โค้ดมันยังเป็นสปาเก็ตตี้อยู่ก็เท่านั้น ถูกไหมครับ เจ้าฟีเจอร์ทางภาษามันแค่ช่วยเสริมหัวใจหลักให้ดียิ่งขึ้นเท่านั้นเอง
หัวใจหลักของ OOP
คือ การแบ่งโปรแกรมหรือแอพพลิเคชันออกเป็นโมดูล(ส่วน)ย่อยๆ
แต่ละโมดูลมีหน้าที่การทำงานหลักเพียงอย่างเดียวเท่านั้น และโมดูลทั้งหมดเหล่านั้นทำงานร่วมกันเป็นแอพลิเคชันที่สมบูรณ์ คุณยังไม่เข้าใจมันหรอกถ้ายังไม่เห็นตัวอย่าง งั้นเรามาดูกันเลยดีกว่า
สมมุติผมจะสร้างแอพพลิเคชันขึ้นมาสักอันหนึ่ง
ผมอาจแบ่งแอพพลิเคชันออกเป็นโมดูลย่อยๆดังแสดงในรูปที่ 1
รูปที่
1 OOP Application
แต่ละโมดูลจะมีหน้าที่หลักหรือบทบาท (Role) หลักเพียงอย่างเดียวเท่านั้น เช่น
- โมดูล GUI จะมีแต่โค้ดที่เกี่ยวข้องกับการแสดงผล (Presentation Logic) เท่านั้น จะไม่มีอย่างอื่นเลย แต่แล้วข้อมูลที่จะนำมาแสดงผลจะมาจากไหนหล่ะ ผมก็ให้มันเป็นหน้าที่ของโมดูล Service
- โมดูล Service มีหน้าที่ในการประมวลผล มันประกอบไปด้วย Business Logic ต่างๆ เช่นการคำนวณราคา, การคิดภาษี เป็นต้น เพื่อเอาผลลัพธ์ไปใช้ในโมดูล GUI แต่การจะประมวลผลได้นั้นมันต้องมีข้อมูลดิบป้อนเข้ามา ซึ่งข้อมูลดิบมักถูกเก็บอยู่ในระบบฐานข้อมูล อย่างไรก็ตามนี่ไม่ใช่หน้าที่หรือบทบาทของโมดูล Service แต่เป็นหน้าที่ของโมดูลต่อไปโมดูล DAO
- โมดูล DAO (Data Access Object) ชื่อก็บอกอยู่แล้วว่าเป็นโมดูลที่ใช้เข้าถึงข้อมูล มีหน้าที่ในการนำข้อมูลเข้าออกจากระบบฐานข้อมูลหรือประกอบไปด้วยโค้ด Data Access Logic เท่านั้น ส่วนจะประมวลผลข้อมูลอย่างไรก็เป็นหน้าที่ของ Service
- โมดูล Report คงเดาได้ไม่ยากว่า มีหน้าที่ออกรายงานอย่างเดียว ก็เผอิญว่าแอพพลิเคชันนี้มีการออกรายงานด้วย
- สุดท้ายโมดูล Main มีหน้าที่ในการโหลดหรือประกอบร่างโมดูลต่างๆเข้าด้วยกันเพื่อให้ได้ออกมาเป็นแอพพลิเคชันที่ใช้งานได้
เห็นไหมครับว่าแต่ละส่วนไม่มีการก้าวก่ายงานกัน
แล้วเราได้อะไรจากการออกแบบเช่นนี้ ? คำตอบคือเราสามารถเปลี่ยนแปลง,
แก้ไข, เพิ่มเติมได้อย่างอิสระ ยกตัวอย่างเช่น
หากเรามีการเปลี่ยนแปลงระบบฐานข้อมูล
เช่นจะเปลี่ยนโครงสร้างตารางหากใช้ Relational Database หรือแม้แต่จะเปลี่ยนจาก Relational ไปเป็น Object
Database เราก็มั่นใจได้ว่าโค้ดที่ต้องเปลี่ยนแปลงอยู่ในโมดูล DAO
เท่านั้น ก็การแสดงผลก็เหมือนเดิม, Business Logic ก็เหมือนเดิม, ออกรายงานก็อย่างเดิมจะไปแก้อย่างอื่นมันทำไม หากเราอยากปรับปรุงหน้าตาการแสดงผล (GUI)
ให้มันดูดีกว่าที่เป็นอยู่ เราก็แก้ไขที่โมดูล GUI เท่านั้น ก็ฐานข้อมูลมันอย่างเดิม, อย่างอื่นก็เหมือนเดิม
จะแก้อย่างอื่นไปทำไม
วันนี้เราเขียนด้วย Java
พรุ่งนี้แอพพลิคชันมันต้องทำงานร่วมกับแอพพลิเคชันอื่นที่ดันเขียนด้วย
.Net เราจะทำอย่างไรดี? เราก็เพิ่มโมดูล
Web Service เข้าไปสิ เพราะเทคโนโลยี Web Services มันเกิดมาเพื่อการนี้คือทำให้ต่างภาษาต่างแพลทฟอร์มทำงานร่วมกันได้
พอจะเห็นภาพหรือยังครับว่าถ้าเราแบ่งแอพพลิเคชันได้ดีคือแบ่งออกเป็นสัดเป็นส่วน
เราก็สามารถเปลี่ยนแปลง, แก้ไข, เพิ่มเติมได้ง่ายขึ้น ได้ประโยชน์แม้ไม่มีโค้ดไฮไซอย่าง Abstract,
Polymorphism, Overriding ใดๆทั้งสิ้น แค่นี้แหละครับหัวใจหลักของ OOP
ส่วนจะแบ่งอย่างไรให้มันดีหรือเหมาะสม
อันนี้ก็ต้องไปว่ากันที่เรื่องของการออกแบบกันต่อไป
กลับมาต่อกันที่หลักการของ OOP กัน
ในทางปฏิบัติแล้วแต่ละโมดูลก็คือออบเจกต์นั่นเอง ดังนั้นการเขียนโปรแกรมแบบ Object-Oriented
ก็คือ การแบ่งโปรแกรมหรือแอพพลิเคชันออกเป็นออบเจกต์ย่อยๆ
แต่ละออบเจกต์ทำหน้าที่หลักเพียงอย่างเดียวหรือมีเพียงบทบาทเดียว
สุดท้ายทุกๆออบเจกต์ทำงานร่วมกันออกมาเป็นแอพพลิเคชันที่สมบูรณ์
ในความเป็นจริงแต่ละบทบาทอาจประกอบไปด้วยออบเจกต์มากกว่าหนึ่งตัวก็ได้เช่น
บทบาทการแสดงผล (GUI) อาจต้องใช้ออบเจกต์มากกว่าหนึ่งตัว
เพราะหนึ่งออบเจกต์ก็หนึ่งหน้าจอ เป็นต้น
ดังนั้นออบเจกต์ต่างๆที่อยู่ในบทบาทเดียวกัน
ก็น่าจะถูกจัดให้อยู่ในกลุ่มเดียวกันดังแสดงในรูปที่ 5 กลุ่มของออบเจกต์ก็คือ Package
หรือ Namespace หรือ Library หรือ Component สุดแท้แล้วแต่จะเรียกนั่นเอง
เพราะฉะนั้นหากผมอยากจะเปลี่ยนหน้าการแสดงผลใหม่ ผมก็โละมันทั้ง GUI
Package ได้เลย จะเห็นได้ว่าหัวใจหลักของ OOP คือการจัดแบ่งโค้ดอย่างมีระเบียบ
พูดง่ายๆคืออย่าเขียนเป็นสปาเก็ตตี้ก็แล้วกัน
รูปที่
2 Packages
แล้วที่เราร่ำเรียนกันมาเกี่ยวกับ Inheritance,
Polymorphism ทั้งหลายทั้งปวงมันคืออะไร นั่นเป็นฟีเจอร์ทางภาษาของ Object-Oriented
ครับ ในเมื่อแอพพลิเคชันถูกแบ่งออกเป็นออบเจกต์ย่อยๆมากมาย
(ในระบบใหญ่ๆมีได้เป็นหลักร้อยหลักพัน) และมันจะต้องทำงานร่วมกัน
ฟีเจอร์ทางภาษาเหล่านั้นจะทำให้มันทำงานร่วมกันได้ดียิ่งขึ้น
เพราะฉะนั้นจุดเริ่มต้นคือต้องแบ่งออบเจกต์ให้ดีเสียก่อน
แล้วจึงใส่ฟีเจอร์ทางภาษาเข้าไป
ไม่มีความคิดเห็น:
แสดงความคิดเห็น