บทเรียนนี้ปูพื้นฐานให้ผู้เรียนเข้าใจว่า “ทำไม” เราจึงต้องพัฒนาโปรแกรมแบบเชิงวัตถุ และ “อย่างไร” แนวคิดเชิงวัตถุจึงช่วยให้การออกแบบระบบมีความยืดหยุ่น ดูแลรักษาง่าย และรองรับซอฟต์แวร์ขนาดใหญ่ได้ดีกว่าแนวคิดแบบเดิม
บทที่ 1 ของรายวิชา การวิเคราะห์และออกแบบระบบเชิงวัตถุ (Object-Oriented Analysis and Design: OOAD) ทำหน้าที่เป็น “ฐานราก” ของทั้งรายวิชา เพราะก่อนที่ผู้เรียนจะเริ่มใช้ UML, วิเคราะห์ Requirement, หรือออกแบบระบบจริง ผู้เรียนต้องเข้าใจแนวคิดพื้นฐานของการพัฒนาซอฟต์แวร์เสียก่อนว่า ระบบหนึ่ง ๆ ถูกคิดอย่างไร ถูกแบ่งส่วนอย่างไร และเหตุใดแนวคิดเชิงวัตถุจึงเกิดขึ้นมาแทนแนวคิดแบบเดิม
เนื้อหาในบทนี้จึงเริ่มจากการทบทวนความรู้เดิม เช่น Algorithm, Flowchart, Programming Language, Database, ERD และ System Analysis & Design เพื่อเชื่อมจากสิ่งที่ผู้เรียนคุ้นเคยไปสู่การมองระบบแบบใหม่ จากนั้นจึงอธิบายแนวคิดของ Traditional Software Development เปรียบเทียบกับ Object-Oriented Software Development พร้อมชี้ให้เห็นปัญหาในโลกจริง เช่น ระบบใหญ่ขึ้น ซับซ้อนขึ้น แก้ไขยากขึ้น และมีต้นทุนการบำรุงรักษาสูงขึ้น
ตอนท้ายของบทจะลงลึกไปยังแนวคิดสำคัญที่สุดของ OOP ได้แก่ Class, Object, Attribute, Method, Message, Encapsulation, Inheritance และ Polymorphism ซึ่งเป็นศัพท์หลักที่ต้องใช้ต่อเนื่องไปตลอดรายวิชา และเป็นพื้นฐานโดยตรงของการวาด UML Diagram ในบทถัดไป
เนื้อหาในสไลด์ช่วงต้นได้ทบทวนแนวคิดพื้นฐานหลายเรื่อง ซึ่งเป็นสะพานเชื่อมจากการเขียนโปรแกรมแบบเดิมไปสู่การออกแบบเชิงวัตถุ
ลำดับขั้นตอนการแก้ปัญหาอย่างเป็นระบบ ระบุว่าเริ่มต้นอย่างไร รับข้อมูลอะไร ประมวลผลอย่างไร และได้ผลลัพธ์อะไร
Step-by-step thinkingการนำเสนอ Algorithm ด้วยสัญลักษณ์ เช่น เริ่มต้น รับข้อมูล ประมวลผล ตัดสินใจ และสิ้นสุด เพื่อมองตรรกะได้ชัดเจน
Visual logicเครื่องมือสำหรับแปลงแนวคิดจาก Algorithm ไปเป็นโปรแกรมจริง เช่น C, Java, Visual Basic, Pascal หรือภาษาเชิงวัตถุอื่น ๆ
Implementationใช้วิเคราะห์โครงสร้างข้อมูลและความสัมพันธ์ระหว่าง Entity ก่อนนำไปออกแบบฐานข้อมูลเชิงสัมพันธ์
Data relationshipระบบจัดการฐานข้อมูล เช่น MySQL, Oracle, SQL Server, SQLite และ MongoDB ซึ่งใช้เก็บและจัดการข้อมูลของระบบงาน
DBMSการวิเคราะห์ความต้องการผู้ใช้ ออกแบบกระบวนการ ข้อมูล และส่วนติดต่อ ก่อนจะลงมือพัฒนาเป็นระบบจริง
ISADAlgorithm หรือ “ขั้นตอนวิธี” หมายถึง ลำดับขั้นตอนในการแก้ปัญหาที่ชัดเจน เข้าใจง่าย และสามารถทำตามได้ทีละขั้น จุดสำคัญของ Algorithm คือ ต้องบอกให้ได้ว่า เริ่มต้นอย่างไร รับข้อมูลอะไร ประมวลผลอย่างไร และสิ้นสุดที่ผลลัพธ์ใด ในทางวิชาการ Algorithm จึงเป็นแกนกลางระหว่าง “โจทย์ปัญหา” และ “โปรแกรม” เพราะก่อนเขียนโค้ด นักพัฒนาต้องคิดขั้นตอนให้เป็นระบบก่อนเสมอ
จากสไลด์ได้ยกตัวอย่างว่าขั้นตอนวิธีสามารถเขียนได้หลายรูปแบบ ได้แก่ Pseudo-code, Flowchart และ Structure Chart แต่ไม่ว่ารูปแบบใด แนวคิดหลักยังคงเหมือนเดิม คือให้ผู้อ่านเข้าใจตรรกะของงานได้โดยไม่สับสน
สไลด์ได้ย้ำว่าโปรแกรมย่อย เช่น Function และ Procedure/Subroutine ช่วยให้การออกแบบตรรกะชัดเจนขึ้น และสามารถนำกลับมาใช้ซ้ำได้
แนวคิดนี้ชี้ให้เห็นว่าแม้ก่อนเข้าสู่ OOP เราก็เริ่มเห็นการแบ่งหน้าที่ของโปรแกรมเป็นส่วนย่อย ๆ แล้ว ซึ่งต่อไปจะพัฒนาไปสู่แนวคิดของ Object และ Method
สไลด์บทนี้ไม่ได้ทบทวนเฉพาะ Algorithm เท่านั้น แต่ยังเชื่อมโยงไปถึงฐานข้อมูลเชิงสัมพันธ์ การเขียน SQL และ Data Dictionary
ในระบบสารสนเทศส่วนใหญ่ ข้อมูลจะถูกเก็บในลักษณะของ “ตาราง” และกำหนดความสัมพันธ์ระหว่างตารางผ่านคีย์ต่าง ๆ เช่น Primary Key และ Foreign Key ตัวอย่างในสไลด์ได้ยกตารางสินค้า ตารางหน่วยนับ และตารางประเภทสินค้า เพื่อให้ผู้เรียนเห็นภาพของการเชื่อมโยงข้อมูลในงานจริง
SELECT * FROM TbProducts WHERE proPrice > 20000SELECT ProName FROM TbProducts WHERE proName LIKE 'C%'
สไลด์ในช่วงกลางของบทได้อธิบายว่าโลกซอฟต์แวร์พัฒนาจากการมองระบบแบบ “ข้อมูล + กระบวนการ” ไปสู่การมองระบบเป็น “กลุ่มของวัตถุ”
แนวคิดแบบดั้งเดิมมักเน้นการพิจารณาระบบโดยแยก “ข้อมูล” ออกจาก “กระบวนการ” จึงใช้เครื่องมืออย่าง DFD, ER Model, FSM หรือเทคนิคเชิงโครงสร้างอื่น ๆ ในการออกแบบ จากนั้นจึงพัฒนาโปรแกรมด้วยภาษาเชิงกระบวนการ เช่น BASIC, Pascal หรือ C
วิธีนี้ยังคงใช้ได้ แต่เมื่อระบบมีขนาดใหญ่และซับซ้อนมากขึ้น การแยกข้อมูลกับกระบวนการออกจากกันมากเกินไปอาจทำให้ระบบยากต่อการดูแลรักษาและขยายต่อยอด
แนวคิดเชิงวัตถุมองว่าในโลกจริง เราไม่ได้เห็นแต่เพียง “ข้อมูล” หรือ “คำสั่ง” แต่เราเห็น “สิ่งของ” หรือ “หน่วยงาน” ที่มีคุณลักษณะและพฤติกรรมอยู่ในตัวเอง เช่น ลูกค้า สินค้า รถยนต์ หรือโทรศัพท์มือถือ
ดังนั้น Object-Oriented จึงรวม data + behavior ไว้ด้วยกันในรูปของ Object และจัดแบบแผนของ Object ด้วย Class วิธีคิดเช่นนี้ทำให้ระบบมีความใกล้เคียงโลกจริงมากขึ้น และเหมาะกับซอฟต์แวร์ขนาดใหญ่ที่ต้องดูแลระยะยาว
| ประเด็น | Traditional / Structural | Object-Oriented |
|---|---|---|
| หน่วยที่ใช้คิด | Process, Function, Data Flow | Object, Class, Attribute, Method |
| มุมมองข้อมูล | ข้อมูลถูกแยกจากกระบวนการ | ข้อมูลถูกห่อรวมกับพฤติกรรมภายใน Object |
| เครื่องมือหลัก | DFD, ERD, FSM, Structured Chart | UML, Object Model, Use Case, Class Diagram |
| การนำกลับมาใช้ซ้ำ | ทำได้บ้าง แต่ไม่เด่นชัด | เด่นชัดผ่าน Class, Inheritance และ Composition |
| ความเหมาะสม | เหมาะกับงานที่ไม่ซับซ้อนมาก หรือระบบขนาดเล็กถึงกลาง | เหมาะกับระบบที่ซับซ้อน ขยายต่อได้ และดูแลระยะยาว |
สไลด์ได้อธิบายถึง Software Crisis หรือภาวะวิกฤตของซอฟต์แวร์ ซึ่งเกิดจากการที่ฮาร์ดแวร์พัฒนาเร็วมาก แต่การพัฒนาซอฟต์แวร์กลับไม่ทันต่อความซับซ้อนที่เพิ่มขึ้น เมื่อซอฟต์แวร์มีขนาดใหญ่ขึ้น มีโมดูลมากขึ้น และมีผู้ใช้งานหลากหลายขึ้น ปัญหาที่พบคือ bug มากขึ้น ใช้เวลาพัฒนานาน และมีค่าใช้จ่ายในการแก้ไขหรือบำรุงรักษาสูง
ระบบใหญ่ทำให้ค้นหาสาเหตุของปัญหายากขึ้น
ค่าใช้จ่ายพัฒนาและบำรุงรักษาเพิ่มขึ้นตามความซับซ้อน
ใช้เวลานานกว่าจะได้ระบบที่ตรงความต้องการจริง
ช่องว่างในการสื่อสารทำให้ระบบอาจไม่ตอบโจทย์ผู้ใช้
ตัวเลขด้านบนสอดคล้องกับสาระสำคัญในสไลด์ที่ชี้ให้เห็นว่า หากไม่วางแผนออกแบบที่ดีตั้งแต่ต้น ค่าใช้จ่ายในระยะยาวจะเพิ่มขึ้นแบบทวีคูณ
เมื่อเริ่มเข้าสู่โลกของ OOP ผู้เรียนต้องเปลี่ยนวิธีมองระบบจาก “ชุดคำสั่ง” มาเป็น “กลุ่มวัตถุที่สื่อสารกัน”
Class คือแบบจำลองหรือพิมพ์เขียวของสิ่งใดสิ่งหนึ่ง เช่น Class Mobile, Car, Person
ภายใน Class จะกำหนดว่า Object ประเภทนั้นควรมีข้อมูลอะไรบ้าง และทำอะไรได้บ้าง
Object คือสิ่งที่ถูกสร้างขึ้นจริงจาก Class นั้น เช่น myPhone หรือ studentPhone
ซึ่งมีค่าของข้อมูลแตกต่างกันได้ แม้จะมาจาก Class เดียวกัน
สาระสำคัญในสไลด์คือ ระบบเชิงวัตถุทำงานเหมือน “เครือข่ายของวัตถุที่สนทนากัน” โดยแต่ละวัตถุมีหน้าที่ของตัวเองและสื่อสารผ่าน message
Encapsulation คือการห่อหุ้มข้อมูล (Attributes) และพฤติกรรม (Methods) ไว้ภายในวัตถุเดียวกัน พร้อมกำหนดขอบเขตการเข้าถึง ว่าใครสามารถเรียกใช้หรือมองเห็นส่วนใดได้บ้าง แนวคิดนี้เชื่อมโยงโดยตรงกับ Information Hiding หรือการซ่อนรายละเอียดภายในไม่ให้ภายนอกรู้โดยไม่จำเป็น
สไลด์ได้ยกตัวอย่างว่า เราอาจไม่จำเป็นต้องรู้ว่า Object คำนวณอายุอย่างไร ขอเพียงมี getAge() ที่ให้ผลลัพธ์ถูกต้องและมี interface คงที่
ภายใน Object จะเปลี่ยนวิธีเก็บข้อมูลวันเกิด หรือปรับสูตรการคำนวณอย่างไร ก็ไม่กระทบผู้ใช้งานภายนอก
ปรับปรุงภายใน Object ได้ โดยไม่จำเป็นต้องแก้ทั้งระบบ หาก interface ยังเหมือนเดิม
เปลี่ยน implementation ภายในได้ง่าย เช่น เปลี่ยนวิธีคำนวณอายุหรือเปลี่ยนโครงสร้างข้อมูล
ระบบต่าง ๆ สามารถทำงานร่วมกันได้สะดวกขึ้น เพราะคุยกันผ่านข้อตกลงของ interface
การถ่ายทอดคุณสมบัติช่วยลดความซ้ำซ้อน และทำให้เราจัดโครงสร้างของ Class เป็นลำดับชั้นได้อย่างเป็นระบบ
Inheritance คือการที่ Class ลูก (Subclass) รับคุณสมบัติหรือพฤติกรรมบางส่วนจาก Class แม่ (Superclass) เพื่อหลีกเลี่ยงการเขียนซ้ำ และทำให้เกิดโครงสร้างที่สอดคล้องกับโลกจริง เช่น Employee, Director, Worker, Driver หรือกลุ่มของ Shape ต่าง ๆ
ตัวอย่างในสไลด์ใช้ Shape เป็น Superclass และมี Circle, Triangle, Square เป็น Subclass โดยทุกชนิดมีคุณสมบัติร่วมบางอย่าง เช่น center หรือ move() แต่แต่ละชนิดก็มีข้อมูลเฉพาะและวิธีทำงานเฉพาะของตนเอง เช่น radius, base/height หรือ side
ในสไลด์ยังกล่าวถึง Multiple Inheritance ซึ่งหมายถึง Class หนึ่งอาจรับคุณสมบัติจากมากกว่าหนึ่ง Superclass ได้ เช่น Managing Director อาจมีคุณลักษณะของทั้ง Person และ Employee
อย่างไรก็ตาม ในการใช้งานจริง ภาษาบางภาษาอาจรองรับตรง ๆ หรืออาจใช้แนวคิด Interface/Composition แทน
Polymorphism คือความสามารถที่ Object ต่างชนิดสามารถตอบสนองต่อ Method เดียวกันได้แตกต่างกันตามชนิดของตนเอง
ตัวอย่างจากสไลด์คือกลุ่มของ Shape ต่าง ๆ ที่ต่างก็มี calculateArea() เหมือนกัน แต่การคำนวณจริงภายในไม่เหมือนกัน
กล่าวง่าย ๆ คือ “ภายนอกเรียกชื่อเดียวกัน แต่ภายในแต่ละ Object ทำงานตามวิธีของตัวเอง” ซึ่งทำให้การออกแบบระบบยืดหยุ่นมาก และช่วยให้เราจัดการกับ Object หลายชนิดผ่าน interface เดียวกันได้
Algorithm และ Flowchart ช่วยฝึกคิดอย่างเป็นระบบก่อนแปลงเป็นโปรแกรมจริง
การออกแบบระบบที่ดีต้องเข้าใจทั้ง data structure, SQL และการจัดเก็บข้อมูล
เมื่อระบบใหญ่และซับซ้อนขึ้น ต้นทุนและการบำรุงรักษาจะสูงขึ้นอย่างมาก
Class และ Object ทำให้เราจำลองโลกจริงได้ชัดเจนขึ้น
Encapsulation, Inheritance และ Polymorphism เป็นหัวใจของ OOP
หลังจากเข้าใจพื้นฐาน OO แล้ว บทที่ 2 จะต่อยอดไปสู่แนวคิดเชิงนามธรรม ความสัมพันธ์ระหว่างวัตถุ และการจัดหมวดหมู่ของคลาสต่าง ๆ