Krissana 的个人资料KRISS照片日志列表更多 工具 帮助

日志


2月8日

OOP ภาคทฤษฎี 2.2: Encapsulation

Encapsulation ....
จาก contract model  ที่พูดถึงไปคราวที่แล้ว หาก Server เซ็นสัญญาว่าจะมี service ใดๆให้โลกภายนอก client ก็จะสนใจเฉพาะ service นั้น โดยไม่สนใจว่า Server จะจัดการอย่างไรให้ได้มาซึ่ง service
 
นิยามของ Encapsulation:
 
Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.
 
เราจะเห็นได้ว่า แท้จริงแล้ว Encapsulation เป็นส่วนเติมเต็มของ Abstraction และถ้ามองลึกลงไปอีก Encapsulation นั้นก็เป็น concept สัมพัทธ์เช่นเดียวกับ Abstraction นั่นคือเมื่อเรา abstract สิ่งใดให้มีลักษณะภายนอกในขอบเขตสมมติใดๆ Encapsulation ก็จะสนใจลักษณะภายในของสิ่งนั้น ภายในขอบเขตสมมติดังกล่าว
 
ประโยชน์ของ Encapsulation หลักๆก็คือทำให้เราเปลี่ยนแปลง "ภายใน" (เทียบกับขอบเขตสมมติ) ได้ง่าย เพราะเมื่อ client สนใจแต่สิ่งภายนอกที่สัมผัสได้ server ก็สามารถเปลี่ยนแปลงภายในได้โดยยึดหลักเพียงอย่างเดียวว่าให้ภายนอกคงเดิม
 
เช่นการแบ่งกลุ่มคราวที่แล้ว
 
  • ผู้ชาย-หน้าตาดี 10
  • ผู้หญิง-หน้าตาดี 10
  • ผู้ชาย-หน้าตาไม่ดี 40
  • ผู้หญิง-หน้าตาไม่ดี 40
  • พิจารณากลุ่มที่ 2 ตราบใดที่ยังเป็นผู้หญิง และหน้าตาดีอยู่ 10 คนนี้ก็จะยังอยู่ในกลุ่มที่ 2 ไม่ว่าความสวย และเพศหญิงนั้นจะเกิดจากธรรมชาติ หรือ ยันฮี

     

    1月25日

    OOP ภาคทฤษฎี 2.1: Abstraction (cont.)

    เวลาวิเคราะห์ระบบหนึ่งๆ เราจะพบว่า Abstraction มีตั้งแต่อันที่สามารถอธิบายหรือสอดคล้องกับประเด็นปัญหาได้ ไปจนถึงอันที่ไม่รู้จะมีทำไม (แล้วแต่ความสามารถและประสบการณ์ในการวิเคราะห์ระบบ) ซึ่งพอจะแบ่งกว้างๆตาม "ความมีประโยชน์" ได้ดังนี้
    • Entity abstraction : object ที่เป็นตัวแทนของ entity ใน problem domain หรือ solution domain ได้ดี
    • Action abstraction : object ที่จัดกลุ่มของการกระทำไว้ด้วยกันเป็น set โดยสมาชิกใน set หนึ่งๆจะมีการกระทำเหมือนๆกัน
    • Virtual machine abstraction : จัดกลุ่มการกระทำที่ "ถูกใช้" โดย "การกระทำระดับสูงกว่า" เดียวกัน หรือ การกระทำที่ "ใช้" "การกระทำระดับต่ำกว่า" เดียวกัน
    • Coincidental 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 ขึ้นมาทีละระดับ จนได้จำนวนกลุ่มที่ง่ายต่อการพิจารณาเช่นสุดท้ายอาจเหลือ

    • คนงานมีปัญหา-ชาย 25
    • คนงานมีปัญหา-หญิง 30
    • คนงานไม่มีปัญหา-ชาย 25
    • คนงานไม่มีปัญหา-หญิง 20

    ซึ่งกว่าจะมาถึงขั้นนี้ เราต้องตัดลักษณะพิเศษมากมายของแต่ละคนออกไป เพื่อจะให้ fit ในกลุ่มที่เราต้องการ ซึ่งถ้าการจัดกลุ่มนี้เป็นการจัดกลุ่มที่ไม่มีประโยชน์ต่อมุมมองที่สนใจ เราก็จะบริหารต่อได้ลำบาก

    คนงานข้างต้น แบ่งได้อีกแบบ

    • ผู้ชาย-หน้าตาดี 10
    • ผู้หญิง-หน้าตาดี 10
    • ผู้ชาย-หน้าตาไม่ดี 40
    • ผู้หญิง-หน้าตาไม่ดี 40

    ซึ่งสุดท้ายก็ได้ 100 คนเหมือนกัน

    หรือ

    • คน 100 คน

    นี่ก็เป็นการจัดกลุ่มแบบ abstract จัดๆเลย

     

    แล้วไง? กลุ่มต่างๆที่เราแบ่ง คือ server หนึ่งๆ และเราคือ client ซึ่งเราจะรู้ว่าเราจะคาดหวัง contract หรือ responsibility อะไรได้จากกลุ่มนั้นๆ

    เช่นการแบ่งแบบแรก ถ้ามี object ไหนอยู่ในกลุ่ม "ผู้ชาย-ไม่มีปัญหา" แล้วจะมีปัญหาหรือไม่ใช่ผู้ชายไม่ได้--ผิดสัญญา

    หรือการแบ่งแบบที่ 2 ถ้าเราอยากได้นางแบบ เราก็เลือกจากกลุ่ม ผู้หญิง-หน้าตาดี ได้ทันที

     

    abstraction เป็น concept ที่ "หุ่นยนต์" มากๆ

     

    1月24日

    OOP ภาคทฤษฎี 2.1: Abstraction

    Abstraction เป็นหนึ่งในวิธีที่มนุษย์ใช้จัดการกับความซับซ้อน คำจำกัดความจากคุณปู่ Booch ว่าไว้ว่า:
    An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.
     
     
    "ทุกสิ่งในโลกล้วนเป็นสิ่งเดียวในโลก" นี่เป็นคำกล่าวของผมเอง หะๆ แต่ว่าในการจะจัดการสิ่งต่างๆในโลกนั้นถ้าเรามองทุกๆสิ่งในลักษณะดังกล่าวก็คงจะไม่มีวันจบสิ้น และเพราะของต่างๆมีเยอะแยะหมื่นพันแสนล้านอย่างนี่แหละ ทำให้เราต้อง "หลับหูหลับตามอง" หลายๆ 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:

    • Abstraction
    • Encapsulation
    • Modularity
    • Hierarchy

    ถ้าขาด 4 อย่างนี้ไปเราจะไม่เรียกว่า object-oriented

    นอกจากนี้ยังมีองค์ประกอบย่อยๆอีกคือ

    • Typing
    • Concurrency
    • Persistence

    ซึ่งองค์ประกอบย่อยนี้ถ้ามีก็ดี แต่ไม่มีก็ไม่ตาย เอ๊ย ก็ยังเป็น 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

    Public Name As String

    End Class

    Class Mammal : Inherits Animal

    End Class

    Class Amphibian: Inherits Animal

    End Class

    Class Dog : Inherits Mammal

    Public HairColor As Color

    End Class

    Class Cat : Inherits Mammal

    Public LongNail As Boolean

    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 แบบเต็มๆกันอีกทีนึง เพราะคราวนี้เป็นแค่การสรุปง่ายๆให้เห็นภาพเท่านั้น