แนวความคิดเพื่อการเป็นโปรแกรมเมอร์
  • บทความนี้ผมได้มาจากที่พี่ที่บริษัทเค้าให้หา หลักการของ Requirement แต่มันดันเจออันนี้ด้วย
    พออ่านๆ ดูก็เห็นว่ามันน่าจะมีประโยชน์ดีก็เลยเอามาให้อ่านกัน ลองดูแล้วกันนะ

    Something strange

    การศึกษาในห้องเรียนปลูกฝังค่านิยมผิดๆ ให้พวกเรา (โปรแกรมเมอร์) อยู่

    "คุณเขียนภาษาอะไรอยู่/คุณเขียน Java เป็นไหม/ทำไมไม่ใช้ C#?" เป็นบทสนทนาที่โปรแกรมเมอร์คุยกันซ้ำซาก

    ภาษาที่ใช้ในการเขียนโปรแกรมดูเหมือนจะเป็นปัจจัยเดียวที่ชี้เป็นชี้ตายชีวิตโปรแกรมเมอร์ได้

    - เด็กนักศึกษาไม่อยากทำ thesis ที่น่าสนใจ เพราะว่าเขา/เธอ เขียน Java ไม่เป็น
    - เด็กปี 4 เดินผ่านหลายๆ บริษัทในงาน job fair เพราะบริษัทเหล่านั้นใช้ภาษาที่เขา/เธอ ไม่ถนัด
    - พนักงานบริษัทอยากเปลี่ยนงาน เพราะบริษัทที่ทำงานอยู่เปลี่ยนไปใช้ภาษาที่เขา/เธอ ไม่ถนัด

    - etc...

    So, what's wrong?

    ผมไม่เถียงว่าภาษาเป็นสิ่งสำคัญ ถ้าคุณจะออกรบแล้วยิงปืนไม่เป็นก็ตายเปล่า

    แต่ภาษาเองก็ไม่ใช่ "ทั้งหมด" ในชีวิตเรา ภาษามันผ่านเข้ามาเป็นยุคๆ ช่วงอดีต Smalltalk, C, C++ ดัง ต่อมา Java บูม .NET ก็มีคนสนใจเยอะ ไหนจะ Ruby On Rails, Groovy On Grails ผ่านมาแล้วผ่านไปทั้งนั้น

    สำหรับผมสิ่งที่สำคัญมากกว่า "ภาษา" ที่ใช้เขียนโปรแกรมคือ "แนวคิด" ในการเขียนโปรแกรม

    ถ้าจะเปรียบเทียบเป็นเกมส์ RPG, การคิดแบบ Object-Oriented เปรียบได้กับ basic skill ที่จำเป็นสำหรับอาชีพ Programmer มันสอนวิธีมองปัญหาให้เป็นวัตถุ ทำอย่างไรที่จะแตกปัญหาออกเป็นหน่วยย่อยๆ ที่สมบูรณ์ในตัวเอง จากนั้นใส่ความสัมพันธ์ให้หน่วยย่อยทั้งหลายเพื่อสร้างระบบขึ้นมาแก้ปัญหา

    พอเก็บเลเวลจนจ๊อบครบ 50 แล้วก็ถึงเวลาเปลี่ยนอาชีพเป็นคลาสสอง (ไม่ได้เล่นแร็กไม่ต้องงง) จะเป็นอะไรดีล่ะ System Analyst, Software Architecture, พนักงานต้อนรับ (อันนี้อัพมาผิดสาย) ไม่ว่าจะอาชีพไหนต่อจากนี้ (ยกเว้นอันหลัง) ย่อมต้องคุ้นเคยกับ OO เป็นพื้นฐาน คราวนี้ล่ะครับที่ Design Pattern จะเป็น skill แรกๆ ที่คุณต้องอัพหลังจากเปลี่ยนเป็นคลาสสอง

    โปรแกรมเมอร์หลายคนที่เริ่มต้นเก็บเลเวลจากภาษาตระกูล C, C++ มักจะมีปัญหากับวิธีคิดแบบ Object-Oriented (ต่อไปจะเรียกย่อๆ ว่า OO) กันค่อนข้างมาก เนื่องจากยึดติดกับแนวคิดแบบ "แตกปัญหาเป็นส่วนๆ" (Procedural Composition) ซึ่งทำได้โดยแยกสิ่งที่ต้องทำออกเป็นข้อๆ ต่อเนื่องกัน แล้วแก้ปัญหาไปทีละสเต็ป

    แน่นอนว่าวิธีดังกล่าวมักจะชักจูงให้เราเขียนโปรแกรมเข้าแนวทางเหล่านี้โดยไม่รู้ตัว คุณอาจจะคิดว่าเป็น OO Programmer เพราะแยกระบบเป็นคลาสต่างๆ แล้ว เสียใจด้วยที่ต้องบอกว่าคุณคิดผิด

    Why OO is important?

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

    ครับ โค้ดกึ่งๆ OO ย่อมทำงานได้ หาก logic ที่คุณใช้แก้ปัญหาตรงกับความต้องการของ requirement แต่เคยเจอปัญหาแนวๆ นี้กันบ้างไหม

    - ระบบที่คุณเขียนมีคลาสเป็นล้าน บางคลาสก็ใช้โค้ดซ้ำๆ กัน ก๊อปมาแปะจากที่อื่นเอา
    - คลาสที่คุณเขียนยาวอย่างกับพระไตรปิฎก ปริ๊นออกมาได้เป็นสิบๆ หน้า บางครั้ง Method เดียวไล่กันสามวันสามคืน ถึงจะเจอจุดที่ทำให้เกิดปัญหา
    - มี requirement เปลี่ยน/เพิ่มขึ้นมาที คุณต้องนั่งเกาหัวแกรกๆ แล้วคิดว่าจะไปเปลียน/เพิ่มตรงไหนดี จนเป็นสาเหตุของสองข้อข้างบน
    - คนที่ต้อง maintain โค้ดต่อจากคุณนั่งเกาหัวจนผมร่วง แล้วเปลี่ยนใจเขียนใหม่ดีกว่า
    ไม่ต้องอายครับ ชาวโปรแกรมเมอร์ทุกคนต้องเคยผ่านจุดนี้กันมาทุกคน (จุดเลี้ยว) ลองมองโค้ดที่เพื่อนคุณเขียนแล้วสงสัยว่าเค้าทำยังไง ทำไมโค้ดเค้า maintain ง่ายกว่า ไม่ต้องนั่งเครียดเวลา SA ได้ไอเดีย requirement ใหม่ๆ หรือนั่งหาบั๊กหลังขดหลังแข็งเมื่อเทสเตอร์หาบั๊กของคุณเจอ

    Cr: Vashira
  • 7 Comments sorted by
  • ASP.NET จงเจริญ HAHA
  • แนวด้วยว่าจุดสำคัญอยู่ที่แนวคิดแระมุมมอง เรื่องภาษาไว้เปิดหนังสืออ้างอิงเอากะได้

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

    OOP อาจเป็นสิ่งใหม่ที่เข้าใจได้ยากสำหรับผู้ที่ไม่เคยมีประสบการณ์ด้านการเขียนโปรแกรมแบบออบเจ็ค ทั้งนี้สิ่งที่สำคัญที่ทำให้เราเข้าใจหลักการเขียนโปรแกรมแบบออบเจ็ค เราจำเป็นต้องรู้ก่อนว่า ออบเจ็คคืออะไร?.....ปกติแล้วในชีวิตประจำวันเราทุกคนได้สัมผัส เคยรู้จักและเคยใช้งานออบเจ็คมาแล้ว เพียงแต่.. เราไม่เคยให้คำจำกัดความของคำว่า ออบเจ็ค (Object) ตัวอย่างเช่น คอมพิวเตอร์ รถยนต์ บ้าน โทรทัศน์ จักรยานยนต์ หรือทุกสิ่งทุกอย่างสัตว์สิ่งของต่างๆ ถือเป็นออบเจ็ค (Object) ทั้งหมด
    เราจะเห็นได้ว่าทุกสิ่งทุกอย่างจะมีคุณสมบัติ (Property) เฉพะตัวของมัน เช่น ทีวี จะมีขนาดหน้าจอ ชนิดของจอ ยี่ห้อ รุ่น ระบบเสียง ส่วนรถยนต์ก็จะมี ยี่ห้อ รุ่น แรงม้า จำนวนประตู ชนิดเกียร์ เป็นต้น นอกจากนั้นสิ่งเหล่านี้ยังสามารถที่จะทำงานบางอย่างได้ (เมธอด method) ตามที่ผู้ผลิตออกแบบขึ้นมา เช่นเราสามารถเปลี่ยนเกียร์รถยนต์ เลี้ยวซ้าย เลี้ยวขวา หรือหยุดรถได้โดยที่เราไม่จำเป็นต้องรู้ว่ามันทำงานอย่างไร จะมีใครบ้างสนใจว่าเบรกรถยนต์ทำงานอย่างไร ใช้เฟืองตัวไหนทำงานประสานกันบ้าง ขอให้มันทำงานตามที่เราต้องการก็พอ งานที่ ต่างๆ ที่เกิดขึ้น มันคงไม่ได้เกิดขึ้นมาเอง นอกจากจะต้องมีเหตุการณ์ (Event) อย่างใดอย่างหนึ่งไปกระตุ้นให้มันทำงาน อยู่ดีๆ ทีวีจะเปลี่ยนช่องเองไม่ได้นอกจากเราจะกดรีโมท หรือกดปุ่มบนเครื่อง หรืออยู่ดีๆ รถยนต์คงไม่เบรกเองโดยคนขับไม่ได้เหยียบเบรก

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

    ถ้าสินค้าแต่ละรุ่นที่ออกมา บริษัทผู้ผลิตต้องออกแบบทุกองค์ประกอบใหม่ทั้งหมดก็คงเป็นการยุ่งยากและเสียเวลาในการผลิตเป็นอย่างมาก ดังนั้นโดยปกติผู้ผลิตจะออกแบบต้นแบบหลักเอาไว้ และนำเอาต้นแบบดังกล่าวมาทำเป็นต้นแบบของผลิตภันฑ์ตัวใหม่ (Inheritance หมายถึงการสืบทอดคุณสมบัติจากต้นแบบเดิม) โดยทำการพัฒนาต่อยอดจากโครงสร้างต้นแบบเดิม เพื่อให้ได้ผลิตภัณฑ์รุ่นใหม่ และสร้างเป็นต้นแบบอีกที เช่น การผลิตทีวีจอแบน ผู้ผลิตก็ยึดต้นแบบของทีวีจอธรรมดาและพัฒนารูปร่าง หน้าตา เพิ่มเติมคุณสมบัติใหม่ๆ เข้าไป หรือแม้แต่การผลิตรถยนต์รุ่นใหม่ๆ คงไม่ได้เริ่มออกแบบใหม่ทั้งหมด แต่คงใช้วิธีดัดแปลงรูปร่างหน้าตา เพิ่มสมรรถนะและความสะดวกสบายเข้าไป ซึ่งเป็นการนำเอาสิ่งที่มีอยู่มาพัฒนาเพิ่มเติมโดยไม่ต้องเริ่มออกแบบใหม่ทั้งหมด

    จากข้อความดังที่กล่าวมาได้แสดงถึงขอบเขตของออบเจ๊ค จะเห็นว่ามีคำศัพท์ใหม่ๆ เกิดขึ้นมามากมายเช่น คลาส (Class) ออบเจ็ค (Object) พร้อพเพอร์ตี้ (Property) เมธอด (Method) อีเวนต์ (Event) เป็นต้น อย่างไรก็ตามคุณไม่ต้องกังวลกับคำศัพท์ต่างๆ เหล่านี้ เพียงต้องการให้เรามองเห็นภาพรวมทั้งหมดเกี่ยวกับแนวคิดของ Object Oriented จึงยกตัวอย่างขึ้นมาประกอบความเข้าใจ

    จะเห็นได้ว่าคำจำกัดความ ที่ง่ายที่สุดของ ออบเจ็ค (Object) ก็คือ อะไรก็ได้ ไม่ว่าจะเป็นคน สัตว์ สิ่งของ สถานที่ ฯลฯ โดยที่ ออบเจ็คจะมีส่วนประกอบที่สำคัญ 2 ประการคือ พร๊อพเพอร์ตี้ (Property) หรือคุณสมบัติเฉพาะตัว และ เมธอด (Method) หรือความสามารถในการทำงาน ดังตัวอยางเช่น ระบบปฏิบัติการ Windows ไมโครซอฟท์ได้นำเอาแนวคิดของ ออบเจ็ค มาประยุกต์ใช้ ทุกสิ่งทุกอย่างใน Windows จะถูกมองเป็น ออบเจ็คทั้งหมด ตั้งแต่ Desktop Icon และ Taskbar นั้นหมายถึงว่าทุกองค์ประกอบของ Windows จะถูกมองเป็น ออบเจ็คซึ่งจะมีพร๊อพเพอร์ตี้ (Property) เฉพาะตัว และมี เมธอด (Method) เพื่อทำงานใดๆ

    เช่น จากรูปหน้าจอ Desktop ของ Windows ถ้าเราคลิกขวาบน Icon ใดๆ จากนั้นคลิกเมนู Property ไดอะล็อกแสดงพร็อพเพอร์ตี้ของ Icon นั้นๆ จะปรากฏขึ้นให้เราเห็นพร็อพเพอร์ตี้เหล่านั้น เช่น ชื่อ Icon ชนิดของไฟล์ ที่อยู่ของไฟล์ ขนาดไฟล์ วันที่/เวลาที่สร้างไฟล์ วันที่/เวลาที่แก้ไขครั้งล่าสุด วันที่เข้าถึงครั้งล่าสุด และรูป Icon เป็นต้น

    นอกจากนั้นออบเจ็คที่เลือกจะมี เมธอด มาให้เพื่อทำงานใดๆ เช่น เมธอด Change Icon เพื่อใช้เปลี่ยนรูปไอคอน, Find Target เพื่อเรียกเปิดโฟล์เดอร์ เป็นต้น จะเป็นได้ว่าเมธอดต่างๆเหล่านี้จะไม่สามารถทำงานเองได้จนกว่าจะเกิดเหตุการณ์ (Event) ใดๆ ขึ้นเช่นเมื่อมีการคลิกเมาส์เป็นต้น

    Cr: Wara
  • วีแม่งสุดยอด ทำยังไงถึงได้เก่งแบบวีบ้าง...
  • นี่สิเค้าเรียกเทพจริง หุหุ

    ช่วงนี้ก็พยายามเขียนอารายให้เปน Object นะ แต่ไม่รู้เหมือนกันแหะว่าตรงคอนเซ็นต์หรือป่าว เพราะหลายๆครั้ง คลาสที่เขียนออกมาทำงานได้แค่ระดับ Procedure ทำมะดาเองง่ะ

    สงสัยยังต้องฝึกอีกเยอะ...
  • ทั่นพ่อ สุดยอดเลยอ่ะ

    สมแล้วที่เป็นทั่นพ่อของลูก

    แต่ลูกดิไม่สมกะเป็นทั่นลูกของทั่นพ่อเลย
  • เก่งตรงไหนฟะกุแค่ search แล้วก้ออ่าน
    แล้วอ่านแล้วอันนี้มองเหงภาพดีเลยก็อปมาแค่นี้เอง -*-