Tour de France #3: Object-Oriented #3

Reusability

พูดไปพูดมาก็เรื่องเก่า

    เรื่อง Object Oriented นั้นเป็นเป็นเรื่องที่มีเนื้อหาอยู่หลายส่วน แต่ละส่วนก็สัมพันธ์กันหมด มันจึงเป็นการยากที่จะมาอธิบายเรื่อง OO ให้เข้าใจกัน เพราะถ้าแตะตรงไหน มันก็จะกระเทือนถึงจุดอื่น วิธีหนึ่งก็คือ อธิบายรวบยอดไป เลยแต่มันจะกลายเป็นเหมือนปรัชญาเต๋าหรือเซ็น ใครยิ่งเรียนลึก ยิ่งคุยไม่รู้เรื่องครับ ผมเลือกเอาวิธีที่ 2 คือมุ่งที่จุดเดียว อย่างวันนี้จะเอาเรื่อง Reusability แต่มันก็คงอดไม่ได้ที่จะต้องกระทบไปถึงส่วนอื่นด้วย แต่ผมจะพยายามคุมเอาไว้ ไม่ไปไกลเกินความจำเป็น

 

นิยามแบบชาวบ้าน

    ถ้าเราจะนิยามเรื่อง Reusability แบบง่ายๆ ก็คือความสามารถที่เรานำเอา Code หรือ Design ของโปรแกรมเก่า เอาไปใช้กับโปรแกรมใหม่ได้ เรื่องนี้เป็นเรื่องภายในของคนคอมพิวเตอร์ครับ ผู้ใช้คงไม่ได้มารับรู้อะไร แต่พูดอย่างนั้นมันก็ไม่ถูกเสียทีเดียว เพราะการที่เราสามารถ Reuse ได้นั้น ทำให้เราไม่ต้องทำงานซ้ำซาก ผลก็คือทำให้โปรแกรมเสร็จเร็วขึ้นและบั๊กก็น้อยลง ส่งผลทางอ้อมสู่ผู้ใช้โปรแกรมครับ

    ถ้าใครคิดว่าผมจะเน้นคำว่า Inheritance คงต้องบอกว่าคิดผิดครับ Inheritance สนับสนุน Reusability น้อยกว่าที่มือใหม่คิดครับ

 

Reuse ระดับที่ 1 - Function

    ผมตั้งระดับของผมเอง อย่าได้นำไปอ้างอิงนะครับ ระดับที่ 1 ของผมหมายถึง Function ครับ ในอดีตที่เราเขียนโปรแกรมนั้น เราเขียนกันยาวยืด ไม่ต้องไปไกลถึงภาษา Assembly โบราณหรอกครับ เอาที่ภาษา BASIC รุ่นแรกๆ ก็ยังได้ ไม่มีฟังก์ชันให้ใช้ครับ การเขียนโปรแกรมก็เลยใช้คำสั่ง GOTO กันมันไปเลย ซึ่งเรารู้ๆ กันอยู่ครับว่ามันไม่ได้

    การใช้ฟังก์ชันในยุคแรกๆ ก็เป็นไปทำนองว่ายุบของที่เขียนซ้ำซ้อนไปเขียนอยู่ในที่เดียวกัน จะได้ประหยัดแรงงานโดยเฉพาะอย่างยิ่งก็คือหน่วยความจำ ซึ่งเครื่องคอมพิวเตอร์สมัยก่อน หน่วยความจำนี่จำกัดมาก

    หลังจากนั้นกว่า 20 ปี ความคิดเกี่ยวกับการ Reuse ค่อยเกิดขึ้นครับ มีการสังเกตว่า เมื่อเราใช้ฟังก์ชันในการสร้างเนื้องานใดๆ ผู้ที่มาเรียกใช้นั้นไม่จำเป็นต้องรู้รายละเอียดภายในเลย (Encapsulation) ผลลัพธ์ก็คือเกิดการเรียกใช้ซ้ำๆ กันได้จากหลายโปรแกรม ทำให้ลดงานไปได้ บั๊กก็ลดลงครับ เพราะว่าเนื้อหาในฟังก์ชันนั้นถูกทดสอบมาแล้วหลายโปรแกรม และฟังก์ชันที่เกิดขึ้นในยุคแรกๆ นั่นมาจากภาษา FORTRAN ซึ่งนำเอาฟังก์ชันทางคณิตศาสตร์จำพวก sin, cos, tan มาสร้างเป็นฟังก์ชัน นั่นจึงเป็นที่มาของคำว่า "ฟังก์ชัน" ถึงยุคปัจจุบัน

    ฟังก์ชันในยุคต่อมามีการพัฒนาขึ้นเพื่อเพิ่ม พารามิเตอร์ ต่างๆ ทำให้ลด Side-Effect ส่งผลให้เราสามารถเขียนโปรแกรมได้ใหญ่ขึ้น จากนั้นแนวคิดนี้จึงเป็นที่มาของ Software Engineering เพื่อสร้างคุณภาพให้กับ Software ในยุคนั้น Top Down Programming เป็นที่นิยมมากครับ

 

Reuse ระดับที่ 2 - Module

    Module ครับ ผมถือว่าเป็น Reuse ระดับที่ 2 ภาษาที่ผลักดันการใช้ Module ให้เป็นที่นิยมก็คือภาษา C สำหรับคนที่ไม่รู้ครับ Module คือ Scope ใหม่ ที่สูงกว่า ฟังก์ชัน Module เป็นที่รวมของฟังก์ชัน ที่ทำงานเหมือนๆ กัน ไปอยู่ด้วยกัน มีตัวแปรและฟังก์ชันที่เรียกใช้อยู่ในเฉพาะส่วนของ Module ครับ ตัวอย่างที่นิยมยกกันของ Module ก็คือ เรื่องการจัดการ Stack หรือ Queue โดยที่ผู้เรียกใช้ Module จะรู้จักเพียงแค่ Enqueue, Dequeue หรือ push pop เท่านั้น โดยที่ Module จะ Encapsulate โครงสร้างข้อมูลที่ใช้จัดการ และตัวของ ตัวชึ้ครับ

    ผมถือว่าขั้นนี้คือการพัฒนาแบบก้าวกระโดด คุณอาจจะไม่คิดเหมือนผมก็แต่ ที่ผมคิดอย่างนั้นก็เพราะ การที่รวบเอาเรื่องที่เกี่ยวกันเข้าด้วยกัน (abstraction) ส่งผลให้ Module มีความสัมพันธ์กับ โปรแกรมที่เรียกใช้ค่อนข้างหลวม ทำให้ Module นั้นสามารถ Reuse เพื่อนำไปใช้กับโปรแกรมอื่นได้ครับ จริงๆ แล้วการที่ฟังก์ชันไม่มี Side Effect มันก็มีความหลวมในระดับหนึ่ง แต่ Module นั้นเพิ่มระดับการ Reuse ขึ้นมากครับ

 

Reuse ระดับที่ 2.5 - Class

    แนวคิดของ Class นั้นเป็นแนวคิดที่คล้ายกับ Module จะว่ามันพัฒนามาจาก Module ผมก็คงพูดได้ไม่เต็มปาก เพราะแนวคิดของ Class นั้นมันเกิดมาตั้งแต่ยุคภาษา Simula ซึ่งน่าจะก่อนที่มีการคิดค้น Module เอาเป็นว่า มันคล้ายกันก็แล้วกันครับ

    แนวคิดของ Class มีระดับการ Reuse สูงกว่า Module ระดับหนึ่ง ทุกอย่างก็มีใน Module ก็มีใน Class ด้วย แต่สิ่งที่ Class มีเพิ่มนั่นก็คือ Module จะมีเพียง Copy เดียวในหน่วยความจำ แต่ Class นั้นมีจำนวน Copy ได้ไม่จำกัดครับ ประโยชน์มันก็มีครับ มันทำให้การพัฒนา Software ง่ายขึ้น สมมุติว่าเราสร้าง Module ในการจัดการ Database แต่ว่า มันเป็นไปได้ครับที่เราจะติดต่อกับ Database หลายตัวพร้อมกัน  เช่นเขียนโปรแกรมโอนข้อมูลจาก Access ไปยัง SQL Server ดังนั้นใน Module เราต้องมีระบบในการจัดการ Database หลายตัว แต่ในทางกลับกันถ้าเราใช้ Class เราไม่ต้องสนใจเรื่องนั้น เราสร้าง Class ที่จัดการ Database เพียงตัวเดียว ด้วยกลไกของ OO ทำให้เราสามารถสร้าง ตัวติดต่อกับฐานข้อมูลได้หลายตัว โดยที่แต่ละดัวอิสระต่อกันครับ

Reuse ระดับที่ 3 - Library

    ระดับที่ 3 คือ Library ครับ อะไรที่ไม่ควรอยู่ในโปรแกรม อะไรที่ควรใช้ได้เป็นของกลาง ก็เอามาเก็บไว้ใน Library ครับ ว่ากันไปแล้ว Library เป็นที่รวมของ Module อีกที จะว่ากันไปแล้วมันก็เหมือนกับ Zip file ที่รวมเอาแฟ้มต่างๆ มาเก็บไว้เป็นแฟ้มเดียวกัน ภาษาที่เป็นตัวผลักดันให้ Library เป็นที่นิยมก็คือภาษา C ครับ

    มีจุดหนึ่งที่ควรจะกล่าวถึงก็คือ Library นี้เป็นอิสระกับโปรแกรม ทำให้เวลาคอมไพล์นั้นต้องมีขึ้นตอนเพิ่มขึ้นหนึ่งขั้น โดยที่ขั้นแรกซึ่งเป็นขั้นที่ต้องทำเสมอก็คือการคอมไพล์โปรแกรมจาก Source Code ภาษา ต่างๆ มาเป็น machine code แต่โปรแกรมที่ได้ยังเอาไปใช้งานไม่ได้นะครับ เพราะยังไม่มี code ในส่วนของ Library ที่เราเรียกใช้มา ดังนั้นจึงต้องมีขั้นที่ 2 เพิ่ม นั่นก็คือขั้นที่เรียกว่า การ Link ซึ่งเราเอาไว้ Link กับ Library ที่คอมไพล์มาก่อนหน้าจากที่อื่น มันค่อยกลายเป็นโปรแกรมที่ทำงานได้ครับ

    การที่สามารถคอมไพล์แยกส่วน(Separate Compile) นั้น ส่งผลทำไห้วงการเขียนโปรแกรมคึกคักมากขึ้นมากครับ บริษัทที่สนับสนุนการเขียนโปรแกรมโดยการสร้าง Library ต่างๆ ขึ้นมา ก็มันเป็น machine code ก็เลยไม่จำเป็นต้องกังวลเกี่ยวกับการรั่วไหลของ  Algorithm ตั้งแต่บัดนั้นเป็นต้นมา เรามี Library ให้ใช้เยอะครับ จนกระทั่งมาถึงทุกวันนี้ โปรแกรมเมอร์ส่วนมาก จะไม่ใช่เป็นนักสร้างแล้วครับ กลายเป็นนักประกอบไป

 

Reuse ระดับที่ 3.5 - Class Library

    เมื่อมีคำว่า Class มันก็ต้องเป็นเรื่อง OO แน่นอน Class Library ก็คือ Library ประเภทหนึ่ง แต่เป็น Library ที่เอาไว้เก็บ Class โดยที่ Class ส่วนมากแล้วไม่ได้อิสระต่อกัน มันมีความสัมพันธ์แบบแม่-ลูกกันอยู่ นั่นคือ Inheritance ครับ การทำ Inheritance นั่นส่วนมากจะออกแบบมาเพื่อให้โปรแกรมเมอร์ Inherit ไปใช้อีกที การใช้งานของ Class Library จึงมักเข้าทำนองว่า เราต้อง Inherit ให้เราไปใช้ มากกว่าจะเรียกใช้แบบโดดๆ ประโยชน์ของการ Inherit ไปใช้นั้น ทำให้ Reuse ดีกว่า Reuse ดีกว่าอย่างไร เป็นคำถามที่น่าสนใจครับ

    ที่ว่าดีกว่านั้น ก็มองในแง่ของ การ Inherit Class ไปใช้นั้น มันแอบเอา Class Library ของตัวแม่มาที่เราโดยที่เราไม่รู้ตัว ลองดู บท Design Pattern - Momento # 2 ที่ผมเขียนไว้เป็นตัวอย่างดูครับ โปรแกรมเมอร์จะได้ความสามารถของ Momento โดยที่เขาไม่ต้องรู้ว่ามันทำได้อย่างไร ไม่มี Code ของตัวแม่ แม้แต่บรรทัดเดียวมาให้รกตาครับ

    แต่ Class Library ก็กลับมีข้อเสียอยู่เหมือนกัน ตรงที่ ระดับของ Inheritance ที่ซับซ้อนขึ้น ก็ยิ่งทำความเข้าใจได้ยากขึ้นครับ การเรียนรู้ Class Library ใช้เวลาไม่น้อยครับ

   

Reuse ระดับที่ 4 - Component

    Component ก็คือ Class Library แบบหนึ่งครับ ที่มีลักษณะพิเศษก็คือพุ่งเป้าไปที่เป้าหมายเพียงเป้าหมายเดียว ซึ่งการทำเช่นนี้ส่งให้ระดับการ Reuse สูงขึ้นไปอีก สูงขึ้นอย่างไร ลองดูตัวอย่างของรถยนต์ครับ ถ้าคุณขับไปขับมาปรากฏว่ายางแตกฉีกขาดไปเลย แน่นอนครับรถยนต์คันนั้นคุณไม่สามารถใช้งานมันได้ แต่ก็ไม่โชคร้ายขนาดนั้นครับ เพราะแนวคิดของการออกแบบรถยนต์นั้นเป็นแนวคิดแบบ Component (ในโลกเราก็มีไม่น้อยครับที่ใช้แนวคิดแบบ Component โดยเฉพาะเครื่องใช้ไฟฟ้าทั่วไป) เราเพียงแค่เปลี่ยนเอาล้อนั้นออก เอาล้อใหม่เข้าไปแทน เท่านี้เราก็สามารถใช้รถต่อได้แล้วครับ

    ในโลกคอมพิวเตอร์คงเปรียบเทียบตรงๆ กับรถยนต์คงไม่ได้ โปรแกรมคอมพิวเตอร์มันคงไม่เสียในลักษณะนั้น แต่หากทำนองว่า Component ตัวนี้ไม่ดี เปลี่ยนเป็นตัวใหม่ดีกว่า ภาษาที่ทำให้ Component เป็นที่นิยมก็คือภาษา Visual Basic ครับ ที่คิดค้น .vbx (ปัจจุบันเป็น .ocx) ถ้าคุณไม่ชอบ Combo ที่ให้มากับ VB คุณก็ไปเอาของ Third Party มาใช้แทนได้ ทุกสิ่งถอดเข้าถอดออกได้ครับ

    Microsoft เป็นบริษัทหนึ่งที่ชื่อในความสามารถของ Component มากครับ โปรแกรมของ Microsoft ทุกตัวใช้แนวคิดของ Component ตัวที่ผมจะกล่าวถึงในบทความนี้ก็คือ Microsoft Office ซึ่งการทำงานเป็นแบบ Component ทุกส่วนอิสระต่อกัน Microsoft เริ่ม Scale ใหญ่ตั้งแต่แรก ดังนั้น ถ้าว่าไปแล้วชุด Office ของ Microsoft ตอนแรกไม่มีความเสถียรเลยครับ แต่พอปรับไปปรับมา วันนี้มันยึดตลาดได้เกือบทั้งหมด จุดขายหลักของ Microsoft Office ก็ตรงที่มันเป็น Component นี่แหละครับ Developer ทั้งหลายสามารถเอา Visual Studio ไปเรียกใช้ ได้เลย ทำให้เราสามารถเขียนโปรแกรมให้ได้ความสามารถแบบ Microsoft Office ได้โดยง่ายครับ

Reuse ระดับที่ 5 - Framework

        Framework คือ Class Library อย่างหนึ่งครับ มันไม่มีของความเป็น Component ครับ มันมีลักษณะพิเศษอยู่อย่างหนึ่งก็คือ นั่นก็คือ มันสื่อสารกับโปรแกรมของเราแบบ 2 ทางครับ โดยที่ Class Library หรือ Component ทั่วไป มันจะมีการสื่อสารเพียงทางเดียวคือ โปรแกรมเราเรียกใช้ Class/Method ของ Class Library หรือ Component แต่สำหรับ Framework นั้นตัว Framework สามารถเรียกใช้ Class/Method ของเราได้

    ฟังดูแล้วแปลกๆ Framework มันจะมาเรียกใช้ Code ของเราทำไม ผมคงต้องให้คุณยืนตีลังกาหลับหัวคิด มันตรงข้ามกับแนวคิดทั่วไปจากหน้ามือเป็นหลังมือครับ โปรแกรมทั่วไป โปรแกรมของเราเป็นนายครับ เรามอง Class Library หรือ Component เป็นบ่าวคอยรับใช้เรา แต่สำหรับ Framework อย่างที่บอกครับ ตรงกันข้ามเลย Code ของ Main Program ไปอยู่ใน Framework ส่วนตัว Code ของเราทำหน้าที่เป็นผู้รับใช้ครับ Framework จะเป็นผู้มาเรียก Code ของเราไปทำงานครับ

    คุณอาจสงสัยเพิ่มว่าแล้วมันได้ประโยชน์อะไรที่ทำอย่างนั้น คำตอบนี้ไม่ยากครับ คุณเองก็ใช้ Framework โดยที่คุณไม่รู้ตัว ก็พวก User Interface นั่นแหละครับ คุณเห็นรึเปล่าว่า ใน Main Program มันมีอยู่บรรทัดเดียวเลยก็คือ

Application.Run(new Form1());

    มันเรียกรันในส่วนของ Framework จากนั้น Framework ก็จะเข้ามาควบคุมการทำงานทั้งหมด คุณเองทำได้ก็เพียงดัก Event ซึ่งนั้นก็เป็นการสร้าง Method เพื่อให้ Framework มาเรียกใช้ สังเกตนะครับ Code ของคุณไม่ได้ควบคุมโปรแกรมอีกแล้ว Framework ต่างหากที่ควบคุมโปรแกรม

    ลองนึกภาพดูนะครับว่า ถ้าคุณไม่มี Framework แบบนี้ใช้ คุณต้องเหนื่อยขนาดไหนที่ต้องเขียนโปรแกรมควบคุม User Interface ทั้งหมด ถ้าใครเคยเขียนภาษา C สำหรับ Windows ในยุคแรกๆ คงเข้าใจเรื่องนี้เป็นอย่างดีครับ

    สิ่งที่ Framework ให้กับเรา นอกจากความง่ายในการใช้งานแล้ว อีกอย่างก็คือมาตรฐานครับ ถ้าคุณใช้ Framework โปรแกรมของคุณถูก Framework บีบให้เข้ามาตรฐาน ทุกโปรแกรมจะเข้าทำนองเดียวกัน

    Framework ตัวดังๆ ก็มีของ Microsoft, Borland, Java ส่วนถ้าเป็นพวกภาษา C++ ก็คงเป็น ET++ ครับ

Reuse ระดับที่ 6 - Application Framework

    มีการประมาณกันว่า เวลาที่เราใช้ในการเขียนโปรแกรมธุรกิจซักตัวหนึ่ง เราเสียเวลาในการจัดการเกี่ยวกับ User Interface มากกว่าครึ่ง แถมยังต้องจัดการ Logic ซ้ำๆ อยู่ตลอดเวลา ตัวที่เป็นของใหม่จริงๆ ในแต่ละโปรแกรมอาจจะมีเพียงแค่ 10%-20% เท่านั้นครับ

     ธรรมชาติของโปรแกรมพวกธุรกิจนี้ เราเรียกเป็นภาษาของพวกเขียนโปรแกรมว่า CRUD ครับ (Create Retrive Update Delete) คืองานที่เกี่ยวกับ Database นั่นแหละครับ ธรรมชาติของมันก็คือมีความซ้ำซ้อนเยอะ แต่เขียนไม่ยากครับ แต่ความท้าทายมันอยู่ที่การบริหารจัดการครับ  จุดยากคือการ Maintain ให้มันอยู่ในรูปแบบเดียวกัน และแน่นอนครับ โปรแกรมพวกนี้จะมีการขอเปลี่ยนแปลงจากผู้ใช้ค่อนข้างสูง ซึ่งเราต้องหาวิธีลดการเกิด Chain Reaction

    ปัญหา Chain Reaction หรือปฏิกิริยาลูกโซ่ เกิดขึ้นเมื่อมีการขอเปลี่ยนแปลงจากผู้ใช้ หรือเกิดจากบั๊กที่ซ้ำๆ กัน ต้องไล่แก้โปรแกรมทุกตัว นั่นก็ยุ่งแล้วนะครับ ที่ยุ่งยิ่งกว่า ถ้าใครทำระบบใหญ่ มีโปรแกรมเมอร์หลายคน คงจะเจอคือ โปรแกรมเมอร์แต่ละคนมี Style เป็นของตัวเอง ผลลัพธ์ก็ทำให้โปรแกรมขาดเอกภาพ เช่นโปรแกรมหนึ่งจาก Programmer คนหนึ่งอาจมีลักษณะไม่เหมือนกับโปรแกรมเมอร์อีกคนหนึ่ง ยุ่งครับ แล้วที่สุดยอดก็คือที่ตัว Source Code ต่างคนต่างรูปแบบ พอมานั่งอ่านโปรแกรมของคนอื่นก็แทบเป็นลมครับ อ่านยากมาก ถ้าโปรแกรมเมอร์คนนั้นลาออก รับรองครับปั่นป่วนกันหมด

      ปัญหานี้เกิดขึ้นเมื่อประมาณ 7 ปี ที่ผ่านมา ผมเลยคิดว่าน่าจะหาวิธีแก้ปัญหาที่ดีกว่านี้ ตอนนั้นผมไม่รู้หรอกว่า Framework มันคืออะไร แต่ออกแบบไปออกแบบมา มารู้เอาทีหลังว่ามันเข้าข่าย Application Framework คือผมมีโครงโปรแกรมตัวหนึ่งคุมการทำงานของโปรแกรมเมอร์ทั้งหมด โปรแกรมเมอร์ไม่สามารถดิ้นออกจากโครงนี้ได้ ดังนั้นมันจะบีบให้โปรแกรมเมอร์เขียนโปรแกรมในแนวเดียวกัน และโปรแกรมที่เคยต้องเขียนตัวละ 2 อาทิตย์ ด้วย Application Framework ตัวนี้ โปรแกรมเมอร์ใช้เวลา 1-2 วันเท่านั้น และผลงานออกมาจะหน้าตาเหมือนกันหมด ถ้ามีบั๊กก็เป็นทุกโปรแกรม แต่ไม่เกิด Chain Reaction นะครับ เพราะเราแก้เพียงที่เดียว พอ Compile ทุกโปรแกรมใหม่ ก็ใช้ได้แล้วครับ

    Application Framework ตัวแรก ผมใช้เวลาคิดอยู่ประมาณครึ่งปี แต่เวลาสร้างจริงๆ ก็แค่อาทิตย์เดียวครับ ความยากของมันไม่ใช่ความซับซ้อน แต่หากต้องคิดให้ถ้วนให้มันรองรับให้ได้ทุกกรณี ผลลัพธ์ออกมาน่าพอใจครับ ปัจจุบัน มันยังรองรับการทำงานได้ดีอยู่ เท่าที่ผมเคยตรวจสอบดูเมื่อ 3 ปีที่แล้ว จำนวนโปรแกรมที่สร้างโดยใช้มันมีอยู่ประมาณ 3,000 โปรแกรม เวลานี้ก็ยังใช้อยู่ ไม่รู้ว่าตัวเลขเป็นอย่างไรแล้ว

    เมื่อ 4 ปีที่ผ่านมา ผมผันตัวเองมาเขียน Visual Basic ผมก็เอาแนวคิดของ Application Framework มาสานต่อ ผมใช้เวลาออกแบบ Application Framework รวมกับหัดเขียน Visual Basic อยู่ประมาณ 1 ปี ก็สร้าง Application Framework ที่ตั้งชื่อว่า "แสนหาญ" เสร็จ ตอนนั้นกำลังอ่านเรื่องวิถีคนกล้าพอดี ด้วย "แสนหาญ" ตัวนี้ โปรแกรมเมอร์เป็นอิสระกับ User Interface ทั้งหมด ถ้าถามโปรแกรมเมอร์ของผมดู บางคนใช้งาน ComboBox ไม่เป็นครับ รู้จักแต่ Property 'name' เท่านั้น แต่ในงานมี ComboBox เต็มเลยนะครับ "แสนหาญ" มันบังให้หมด เวลาเขียนโปรแกรมแทนที่จะเน้นว่าเขียนได้อย่างไร กลับกันครับ ผมใช้วิธีบอก "แสนหาญ" ว่าอยากได้อะไร มันทำให้เสร็จครับ

    แต่อายุของ "แสนหาญ" ไม่ค่อยยาวครับ เพราะผมติดปัญหา OO กับ VB แก้ไม่ค่อยตก ประกอบกับผมฝันอยากให้มันมีความสามารถมากไป เกือบทุกอย่างมันอัตโนมัติหมด Code ที่เขียนมีนิดเดียว แต่มันเสียความยืดหยุ่นครับ ผมเลยต้องออกแบบใหม่ หลังจากใช้แสนหาญไปประมาณ 1 ปี ผมเลยสร้างเป็นตัวใหม่ตั้งชื่อว่า "ถ้วนเท่านึก" ถ้าผมจำไม่ผิดก็คือน้องชายของท่านคึกฤทธิ์ เห็นชื่อมันมีความหมายดี คิดได้เท่าไหนก็ทำงานได้เท่านั้น ผมลดสิ่งที่เป็นอัตโนมัติลง มันมีความยืดหยุ่นสูงขึ้น ตัวนี้ก็ยังใช้ได้จนถึงปัจจุบันครับ ขณะนี้ผลงานของมันมีมากกว่า 500 โปรแกรมแล้วครับ

    เมื่อ .NET Framework ออกมา และมันรองรับ OO เต็มรูป ผมก็เลยอยากจะสร้าง Application Framework ตัวใหม่เสียที รอมานานแล้ว กำลังทำกันอยู่ครับ

    Application Framework มีข้อเสียเหมือนกันครับ คือมันทำให้ความรู้สึกของโปรแกรมเมอร์ไม่ค่อยดี มันทำงานแทนโปรแกรมเมอร์เกือบหมด ความท้าทายสำหรับโปรแกรมเมอร์เลยไม่ค่อยมี บางคนพอเปลี่ยนงานไปทำที่อื่น ก็มารำพึงกับผมว่า กลัวว่าไปที่ใหม่แล้วจะเขียนงานไม่ได้ Application Framework มันแย่งไปทำหมด เรื่องนี้ก็พูดยากครับ

สรุป

    เรื่อง Reusability เป็นเรื่องที่อยู่ในความสนใจมานานแล้ว โดยเฉพาะอย่างยิ่งในยุค OO แต่ก็มีความเข้าใจกันผิดว่า Inheritance และ Polymorphism เป็นหัวใจในการทำ ที่จริงแล้ว ทั้ง 2 ตัวนั้นมีบทบาทค่อนข้างน้อยในเรื่องนี้ ถ้าเทียบกับ Abstraction และ Encapsulation ครับ เพื่อให้เห็นภาพ ผมเลยยกตัวอย่างจากประสบการณ์จริงให้อ่านกัน คิดว่าคงมีประโยชน์บ้างครับ

 

7-Mar-02