โดยปกติการเขียนโปรแกรมแบบ OOP ที่มองทุกอย่างเป็นวัตถุนั้น ภายในแต่ละวัตถุจะมี 2 ส่วน คือ Data กับ Method
ส่วนของข้อมูล(Data) บางครั้งมักจะถูกห่อหุ้มไว้ให้ใช้ได้ภายในวัตถุนั้นๆ เท่านั้น
ถ้าอยากจะเปลียนแปลงข้อมูล ก็ควรจะเรียกใช้ผ่าน Method
การป้องกันไม่ให้มาแก้ Data โดยตรงก็คือ การ encapsulation นั่นเอง คือหุ้ม Data ไว้ ให้เรียกใช้ผ่าน Method (รายละเอียดปลีกย่อยยังมีอีกเยอะ ผมจะเล่าแค่ conceptให้เข้าใจนะครับ ส่วนอื่นไปศึกษาต่อได้ไม่ยาก)
ยกตัวอย่าง
เราออกแบบและเขียนโปรแกรม วัตถุบัญชีธนาคาร
ในบัญชีธนาคารก็จะมี Data ก็คือ ยอดเงิน กับ Method คือฝากถอน โดย Method ฝากถอน จะทำงานโดยบันทึกข้อมูลรายการเดินบัญชีลงใน statement + ปรับข้อมูลยอดเงิน
สมมติว่าเราทำงานกันเป็นทีมโปรแกรมเมอร์ เราก็ควรออกแบบวัตถุบัญชีธนาคารนี้ว่า
ห้ามมาปรับยอดเงินโดยไม่ผ่าน Method นะ ไม่งั้นมันจะไม่มีการบันทึก transaction ฝากถอนไง อยู่ดีๆ ยอดเงินก็เพิ่มขึ้นหรือลดลง โดยพอไปดู statement กลับไม่เจอรายการ
พอโปรแกรมเมอร์คนอื่นมาใช้วัตถุบัญชีธนาคารก็ต้องทำตามกฎที่เราออกแบบไว้
คือ ถ้าอยากจะเพิ่มหรือลดยอด ก็ควรทำผ่าน Method ฝากถอน แต่ถ้ามีโปรแกรมเมอร์บางคนดื้อดึง จะไปแก้ยอดเงินตรงๆ คือหัวชนฝาว่าจะทำ สมัยนี้ตัว Compiler มันเก่ง มันจะฟ้องเลยว่า เฮ้ยไม่ได้นะ คนเขียนส่วนวัตถุบัญชีธนาคารเค้าออกแบบมาแล้ว ไม่ให้ทำแบบนี้เฟ้ย
อย่างนี้เป็นต้น
ทีนี้ประโยชน์อีกอย่างหนึ่งสำหรับโปรแกรมเมอร์คนอื่นๆก็คือ
เค้าก็ไม่จำเป็นต้องรู้ว่าไอ้เจ้า Method ฝากถอน มันทำงานยังไง
จะต้องไปปรับยอด ไปลงบัญชี บลาๆๆๆ อย่างไร
เพราะเค้าเชื่อใจว่าเราออกแบบและเขียน Method ให้เค้ามาดีแล้ว
เค้าก็เรียกใช้ Method ที่เราออกแบบไว้ ก็จบเลย อย่างอื่นไม่ต้องไปแคร์
ถ้ามันผิด ก็งานเข้าเราที่ต้องแก้บั๊กเท่านั้นเอง
