Krissana 的个人资料KRISS照片日志列表更多 ![]() | 帮助 |
|
|
2月8日 OOP ภาคทฤษฎี 2.2: EncapsulationEncapsulation ....
จาก contract model ที่พูดถึงไปคราวที่แล้ว หาก Server เซ็นสัญญาว่าจะมี service ใดๆให้โลกภายนอก client ก็จะสนใจเฉพาะ service นั้น โดยไม่สนใจว่า Server จะจัดการอย่างไรให้ได้มาซึ่ง service
นิยามของ Encapsulation:
เราจะเห็นได้ว่า แท้จริงแล้ว Encapsulation เป็นส่วนเติมเต็มของ Abstraction และถ้ามองลึกลงไปอีก Encapsulation นั้นก็เป็น concept สัมพัทธ์เช่นเดียวกับ Abstraction นั่นคือเมื่อเรา abstract สิ่งใดให้มีลักษณะภายนอกในขอบเขตสมมติใดๆ Encapsulation ก็จะสนใจลักษณะภายในของสิ่งนั้น ภายในขอบเขตสมมติดังกล่าว
ประโยชน์ของ Encapsulation หลักๆก็คือทำให้เราเปลี่ยนแปลง "ภายใน" (เทียบกับขอบเขตสมมติ) ได้ง่าย เพราะเมื่อ client สนใจแต่สิ่งภายนอกที่สัมผัสได้ server ก็สามารถเปลี่ยนแปลงภายในได้โดยยึดหลักเพียงอย่างเดียวว่าให้ภายนอกคงเดิม
เช่นการแบ่งกลุ่มคราวที่แล้ว
พิจารณากลุ่มที่ 2 ตราบใดที่ยังเป็นผู้หญิง และหน้าตาดีอยู่ 10 คนนี้ก็จะยังอยู่ในกลุ่มที่ 2 ไม่ว่าความสวย และเพศหญิงนั้นจะเกิดจากธรรมชาติ หรือ ยันฮี
1月25日 OOP ภาคทฤษฎี 2.1: Abstraction (cont.)เวลาวิเคราะห์ระบบหนึ่งๆ เราจะพบว่า Abstraction มีตั้งแต่อันที่สามารถอธิบายหรือสอดคล้องกับประเด็นปัญหาได้ ไปจนถึงอันที่ไม่รู้จะมีทำไม (แล้วแต่ความสามารถและประสบการณ์ในการวิเคราะห์ระบบ) ซึ่งพอจะแบ่งกว้างๆตาม "ความมีประโยชน์" ได้ดังนี้
สิ่งที่เราอยากได้เมื่อวิเคราะห์ระบบ ก็คือ Entity abstraction
ขอนิยาม concept ของ client-server หน่อย ในที่นี้ไม่ได้หมายถึง client-server ในเชิง architecture นะ client คือ object ใดๆที่ใช้งาน resource ของ object อื่น และมองในมุมกลับกัน object ที่ถูก object อื่นใช้ resource ก็คือ server เราสามารถบ่งบอกลักษณะของ object ได้จาก "service" ที่ มันมีให้คนอื่น กับ "operation" ที่มันสามารถกระทำต่อคนอื่น ซึ่งมุมมองนี้ก็คือการดูเฉพาะลักษณะภายนอกของ object นั้นๆ
มี model ที่สำคัญอีกอันหนึ่งคือ contract model : object ใดๆจะ (ประหนึ่ง) เซ็นสัญญากับโลกภายนอกว่า ตัวข้านี้จะมี สิ่งนั้นสิ่งนี้ ให้ object อื่นมองเห็น และนำไปใช้ กล่าวคือ เป็นสิ่งที่ client คาดหวังว่า server จะต้องมี โดย server จะไปทำยังไงภายในนั้น client ไม่สนใจ ----------------------------------------------------------------------------------- โอย เหนื่อย พักหน่อย concept ต่างๆที่เล่ามา และจะเล่าต่อไปนั้น จริงๆแล้วเราใช้อยู่ตลอดเวลา เพียงแต่มันยากที่จะอธิบาย (อาจเพราะผมเองอธิบายได้เท่านี้) เมื่อคนเผชิญกับสิ่งที่ซับซ้อน และ คนคนนั้นไม่ใช่อัจฉริยะ เขาก็จะเริ่มการ generalize สิ่งต่างๆ เพื่อให้จำนวนของมันน้อยลง หรือ specialize สิ่งต่างๆ เพื่อพิจารณาเจาะจงลงไป generalization เป็นสิ่งที่ผมไม่ค่อยชอบนัก แต่มันก็ลดงาน labor ลงได้ เช่นเวลาพิจารณาคนงาน 100 คน แทนที่จะดูทีละคน เราก็ generalize ขึ้นมาทีละระดับ จนได้จำนวนกลุ่มที่ง่ายต่อการพิจารณาเช่นสุดท้ายอาจเหลือ
ซึ่งกว่าจะมาถึงขั้นนี้ เราต้องตัดลักษณะพิเศษมากมายของแต่ละคนออกไป เพื่อจะให้ fit ในกลุ่มที่เราต้องการ ซึ่งถ้าการจัดกลุ่มนี้เป็นการจัดกลุ่มที่ไม่มีประโยชน์ต่อมุมมองที่สนใจ เราก็จะบริหารต่อได้ลำบาก คนงานข้างต้น แบ่งได้อีกแบบ
ซึ่งสุดท้ายก็ได้ 100 คนเหมือนกัน หรือ
นี่ก็เป็นการจัดกลุ่มแบบ abstract จัดๆเลย
แล้วไง? กลุ่มต่างๆที่เราแบ่ง คือ server หนึ่งๆ และเราคือ client ซึ่งเราจะรู้ว่าเราจะคาดหวัง contract หรือ responsibility อะไรได้จากกลุ่มนั้นๆ เช่นการแบ่งแบบแรก ถ้ามี object ไหนอยู่ในกลุ่ม "ผู้ชาย-ไม่มีปัญหา" แล้วจะมีปัญหาหรือไม่ใช่ผู้ชายไม่ได้--ผิดสัญญา หรือการแบ่งแบบที่ 2 ถ้าเราอยากได้นางแบบ เราก็เลือกจากกลุ่ม ผู้หญิง-หน้าตาดี ได้ทันที
abstraction เป็น concept ที่ "หุ่นยนต์" มากๆ
1月24日 OOP ภาคทฤษฎี 2.1: AbstractionAbstraction เป็นหนึ่งในวิธีที่มนุษย์ใช้จัดการกับความซับซ้อน คำจำกัดความจากคุณปู่ Booch ว่าไว้ว่า:
"ทุกสิ่งในโลกล้วนเป็นสิ่งเดียวในโลก" นี่เป็นคำกล่าวของผมเอง หะๆ แต่ว่าในการจะจัดการสิ่งต่างๆในโลกนั้นถ้าเรามองทุกๆสิ่งในลักษณะดังกล่าวก็คงจะไม่มีวันจบสิ้น และเพราะของต่างๆมีเยอะแยะหมื่นพันแสนล้านอย่างนี่แหละ ทำให้เราต้อง "หลับหูหลับตามอง" หลายๆ object ว่าคือ "ของอย่างเดียวกัน" ซึ่งถ้าจะวิเคราะห์กันลงไปแล้ว คำว่า "ของอย่างเดียวกัน" ก็เป็นการสมมติขึ้นเพื่อพิจารณาให้ง่าย เพราะจริงๆแล้วการจัดหมวดหมู่ก็คือการ "รับรู้สิ่งความเหมือน และละความต่างไว้ชั่วคราว"
ซึ่งไอ้การรับรู้ความเหมือน ปกปิดความต่างเนี่ย มันแล้วแต่มุมมอง และความสนใจในขณะหนึ่งๆ (เลยมีคำว่า "ชั่วคราว") ของแต่ละคนมอง และเรามี "อำนาจ" ปลอมๆที่จะมองสิ่งต่างๆในแบบที่เราต้องการ และทำความเข้าใจมันได้ง่ายขึ้น
งงกันเลย หะๆ
เรามี โต๊ะไม้สีแดง โต๊ะเหล็กสีขาว โต๊ะกระดาษสีขาว เก้าอี้ไม้สีแดง อย่างละ 1
เราจะมองวัตถุ 4 ชิ้นนี้อย่างไร (แต่จริงๆแล้ว แค่ผมบรรยายถึงวัตถุ 4 ชิ้นนี้ ผมก็ได้ทำการ "มอง" มันไปแล้ว และคนที่อ่าน และรับรู้ได้ว่าวัตถุ 4 ชิ้นนี้คืออะไรบ้างก็ได้ทำการ "มอง" ไปแล้วเช่นกัน)
ความสามารถในการรับรู้สิ่งต่างๆของมนุษย์นั้นส่วนหนึ่งเกิดจาก abstraction หลายๆมุม หลายๆระดับอย่างรวดเร็วจนแทบไม่ต้องคิด เช่นในกรณีนี้ เราจะ abstract วัตถุ 4 ชิ้นนี้ได้หลายๆทาง
วัตถุ 4 ชิ้น
โต๊ะ 3 ตัว เก้าอี้ 1 ตัว
วัตถุสีขาว 2 ชิ้น สีแดง 2 ชิ้น
เฟอร์นิเจอร์ไม้ 2 เหล็ก 1 กระดาษ 1
โต๊ะไม้สีแดง โต๊ะเหล็กสีขาว โต๊ะกระดาษสีขาว เก้าอี้ไม้สีแดง
...
etc.
การมองเป็น "วัตถุ 4 ชิ้น" เป็นการมองในระดับสูงสุด คือมองทุกอย่างในโลกเหมือนกัน และไม่เห็นความแตกต่างอันใด
การมองเป็น "โต๊ะไม้สีแดง โต๊ะเหล็กสีขาว โต๊ะกระดาษสีขาว เก้าอี้ไม้สีแดง" เป็นการมองในระดับต่ำสุด (ในที่นี้ถือว่า 4 ชิ้นนี้ไม่แบ่งแยกไปเป็นอะตงอะตอมอะไรอีกนะ) คือมองในระดับ atomic ที่สุด ทุกอย่างต่างกันหมด ไม่มีอะไรเหมือนกัน
ส่วนการมองแบบที่เหลือก็ต่างมุมมองกันไป
ไม่ว่าระดับไหน ก็มีส่วนช่วยในการทำความเข้าใจ 4 สิ่งนี้ทั้งสิ้น และเวลาจะเลือกใช้การมองสิ่งต่างๆ เราก็ต้องเลือกระดับที่เหมาะสม หรือสนใจ เพื่อ manage ความซับซ้อนให้ได้
อธิบายต่อคราวหน้า
5月13日 OOP ภาคทฤษฎี 2: Conceptual Frameworkขอยกเรื่อง class กับ object ไปไว้ทีหลังเลย เพราะคราวนี้จะพูดถึง conceptual framework ของ OO ที่เรียกว่า object model ซึ่งเป็นสิ่งที่บ่งบอกว่านี่คือ OO ไม่ใช่อย่างอื่น ต้องบอกกันก่อนว่า OO ไม่ใช่ที่สุดของโลก เหมือนกับ เงินไม่ใช่พระเจ้า นอกจาก OO แล้วก็ยังมีรูปแบบอื่นๆอีกหลายอย่างที่ต่างก็เหมาะสมกับคนละที่คนละเวลา และไม่ได้มีอะไรที่ "ดีกว่ากันไปเสียทั้งหมด" และแต่ละแบบก็จะมีลักษณะเฉพาะของมันที่ทำให้เรารู้ว่านี่แหละคือไอ้นั่นนี่แหละคือไอ้นี่ ซึ่งเราจะมาดู object model กัน องค์ประกอบสำคัญที่ขาดไม่ได้ของ object model:
ถ้าขาด 4 อย่างนี้ไปเราจะไม่เรียกว่า object-oriented นอกจากนี้ยังมีองค์ประกอบย่อยๆอีกคือ
ซึ่งองค์ประกอบย่อยนี้ถ้ามีก็ดี แต่ไม่มีก็ไม่ตาย เอ๊ย ก็ยังเป็น OO ได้อยู่
ทำไมจะต้องวุ่นวาย คิดถึงสิ่งเหล่านี้ แทนที่จะเขียนๆไปให้สิ้นเรื่องสิ้นราว นั่นเป็นเพราะว่าถ้าเราขาด framework แบบนี้ไป ไม่ว่าเราจะใช้ภาษาอะไรที่เรียกว่า OOP language เช่น VB.NET,C#,C++,SmallTalk ... code ที่ออกมาก็ไม่ต่างกับการเขียนด้วย Pascal หรือ C ซึ่งไม่ได้ผิด (ขอย้ำ) แต่จะทำให้เราไม่ได้ใช้ข้อดีหรือพลังของ OOP อย่างเต็มที่ในการมองและจัดการกับปัญหาต่างๆ อีกอย่างที่สำคัญกว่านั้นก็คือถ้าเราไม่สนใจเรื่องพวกนี้ เราก็จะใช้เวลา และประสบการณ์อันยาวนาน กว่าเราจะบอกได้ว่า code ที่เราเขียนมันมีข้อบกพร่องอย่างไร OOP ภาคทฤษฎี 1.1ต่อเนื่องจากคราวที่แล้วในเวอร์ชั่นสัตวาภิธานคงจะทำให้มึนกันไปไม่น้อย (ผมด้วย) จึงคั่นรายการด้วย Code เพื่อความบันเทิงก่อนจะไปร่ายทฤษฎีกันต่อ เขียนด้วย VB.NET นะ ด้วยความถนัด ออกตัวว่านี่เป็น code ตัวอย่างนะ อย่า serious เรื่อง public member (เดี๋ยวว่ากันทีหลัง) เริ่มจากกำหนด Class Class Animal
End Class Class Mammal : Inherits Animal End Class Class Amphibian: Inherits Animal End Class Class Dog : Inherits Mammal
End Class Class Cat : Inherits Mammal
End Class Class Frog: Inherits Amphibian End Class ทีนี้เวลาเรียกใช้ทำไง Dim cat1 As New Cat Dim cat2 As New Cat Dim dog1 As New Dog Dim dog2 As New Dog Dim frog1 As New Frog สิ่งที่ทำ 4 บรรทัดข้างต้นคือการสร้าง (instantiate) object จาก class นั่นเอง โดยใน 4 บรรทัดที่ว่าประกอบด้วย 5 objects (cat1,cat2,dog1,dog2,frog1) เราบอกได้ว่า 4 บรรทัดนั้นมี 5 Animal objects 4 Mammal objects 1 Amphebian object 2 Cat objects 2 Dog objects 1 Frog object เราไม่เรียกว่ามี 4 Mammal classes,2 Cat classes... เพราะมันไม่ใช่ ระวังสับสนระหว่าง class กับ object เรื่อง inheritance เดี๋ยวว่าต่อ OOP ภาคทฤษฎี 1: Class & Objectsอะไรคือ OOP หว่า? มันคือเพลง Britney Spears รึ? นั่นมัน OOP(s) I did it again !!! .....ชิ้ง........ เอาเป็นว่าเราลองมาหาความหมายของ OOP กันก่อน เริ่มจาก Google: OOP (Out Of Production): A rocket or other product no longer currently made, but remembered fondly from the past. หะๆ พอๆ เดี๋ยวจะยาว เอาเป็นจากหนังสือของคุณ Grady Booch ละกัน OOP (Object-oriented programming) is a method of implementation in which progams are organized as cooperative collections of objects, each of which represents an instance of some class, and whose class are all members of a hierachy of classes united via inheritance relationships. ซึ่งถอดมาสำคัญๆ คือ (1) ใช้ object ในการสร้าง (2) แต่ละ object นั้นต้องเป็น instance ของ class และ (3) class มีการเกี่ยวของกับ class อื่นในแบบ inheritance โอว ยากเอี้ยๆ ไม่เห็นจะเข้าใจได้เลย ..... (ช่วยอินกันหน่อยนะ แกล้งไม่เข้าใจก็ได้ จะได้เขียนต่อได้) โอเค งั้นจะลองอธิบายและยกตัวอย่างให้เข้าใจ (หรืองงไปใหญ่ก็ไม่รู้) Class-object สัมพันธ์กันอย่างไร? เอาแบบลูกทุ่งๆเลยเนี่ย class ก็คืออะไรที่เป็น "คำจำกัดความ" ของสิ่งหนึ่งๆ (อะไรก็ได้) ส่วน object ที่เป็น instance ของ class นั้น ก็คือ"สิ่งของ"ที่เป็นไปตามคำจำกัดความนั้นนั่นเอง จะบอกว่า class เป็นนามธรรม และ object ก็คือรูปธรรมก็คงไม่ผิดนัก ผมหันไปดูทางขวา เห็นแมวตัวหนึ่ง อธิบายอย่าง OO ได้ว่าไอ้สิ่งที่ผมเห็นและเดินไปลูบหัวมันได้เนี่ยคือ "object" ส่วนสิ่งที่ผมกำหนดรู้ในใจว่า "แมว" เนี่ยก็คือ "class" นั่นเอง ซึ่งในห้องอาจมีแมว 5 ตัว 10 ตัว เราก็เรียกมันว่า "แมว" ทั้งสิ้น จะเห็นได้ว่า class มีอันเดียวแต่ object ที่กำเนิด (instantiated) จาก class นั้นมีเท่าไหร่ก็ได้ อ้า... มาถึงตรงนี้ก็อธิบายไป 2 ใน 3 แล้ว ที่เหลืออีกอย่างก็คือ inheritance inheritance เกี่ยวข้องกับ class และมีความหมายคือการถ่ายทอดคุณสมบัติจาก class สู่ class ในลักษณะ hierachy (แม่-ลูก) ซึ่งจะทำให้ลูกมีลักษณะของแม่ครบถ้วน และอาจมีลักษณะอื่นๆเพิ่มเติม (มีหรือไม่มีก็ได้) โดยที่เมื่อ class A (แม่) inherit สู่ class B (ลูก) แล้วเราจะสามารถเขียนเป็นประโยคได้ว่า B เป็น A (B is an A) เช่น หมาเป็นสัตว์เลี้ยงลูกด้วยนม ถ้าเรามองอย่างหยาบๆแล้ว "แมว" กับ "หมา" นั้นก็เป็น "สัตว์เลี้ยงลูกด้วยนม" ทั้งสิ้น ในประโยคที่ผ่านมาเราเห็น 3 class คือ "สัตว์เลี้ยงลูกด้วยนม" "แมว" และ "หมา" โดยที่ class แมว และ class หมานั้น inherit (ถ่ายทอดคุณสมบัติ) มาจาก class สัตว์เลี้ยงลูกด้วยนม นั่นเอง เอาตัวอย่างสุดท้าย แบบรวบทุกอย่างเลย "ในห้องนี้มีสัตว์เลี้ยงลูกด้วยนม 10 ตัว เป็นแมว 5 หมา 4 คนอีก 1 แต่ถ้านับสัตว์ทั้งหมดแล้วมี 11 เพราะมีตัวเงินตัวทองซึ่งเป็นสัตว์เลือดเย็นอีก 1 ตัว" ประโยคที่ผ่านมานั้นประกอบด้วยกี่ class กี่ object และมี inheritance อย่างไร? จบแค่นี้ก่อน คราวหน้าจะมาว่ากันในเรื่อง object และ class แบบเต็มๆกันอีกทีนึง เพราะคราวนี้เป็นแค่การสรุปง่ายๆให้เห็นภาพเท่านั้น |
|
|