Tag Design Pattern

สรุปงาน DevMountain #02

งาน DevMountain จัดมา 2 รอบแล้ว แต่ Season 1 ไม่รู้ข่าว แหะๆ สำหรับงานนี้ Season 2 และ โดยจัดที่เชียงใหม่เลย แต่ไม่ได้ไปนะ พอดีมีธุระเย็นวันที่ 12 ครับ สำหรับงานนี้จัด 2 วันเต็ม จริงต้องบอกว่า Theme Tech Week Meetup เพราะมีงานอื่นๆ จัดไปด้วย ตามนี้เลย <thai-tech-calendar /> | รวม อัพเดท Tech event, Tech Meetup ในไทยไว้ในที่เดียว…

[Design Pattern] Command Pattern in Depth

อันนี้น่าจะเป็น Pattern ที่ 4 ที่เขียนกันครับ ทำไมต้องใช้ Command Pattern ต้องการเชื่อมของหลายๆสิ่งเข้าด้วยกันได้ เช่น Remote กับเครื่องใช้ไฟฟ้า แต่ละอย่างในบ้าน เช่น หลอดไฟ, พัดลม หรือ ทีวี ที่มีลักษณะการทำงานคล้ายๆกัน เช่น เปิด(ON) หรือป ปิด(OFF) เป็นต้น แต่ไม่อยากให้มันผูกแน่นกันจนเกินไป มาดูโจทย์ของเราดึงกว่า โดยผมรับ Requirement มาว่าให้ได้ออกแบบ Application ETradeStock อันนึงที่สามารถส่งคำสั่งไปที่ตลาดหุ้น SAT ซึ่งสำหรับ SAT มี API อยู่ 2 เจ้าครับ…

[Design Pattern] Decorator Pattern in Depth

ทำไมต้องใช้ Decorator Pattern อยากเพิ่มความสามารถของ Object (Object ทำงานเหมือนเดิมนะ แต่ถูกเพิ่มความสามารถ) เมื่อไหร่ควรจะใช้ ไม่อยากใช้คุณสมบัตินึงของ OOP-Inheritance มากเกินไป เพราะใช้ไปแล้ว ก็ต้อง Override ไปแก้ความสามารถที่ได้มาจาก Class แม่อีก หรือมี Class ลูก (Sub Class) ที่มากจนเกินไปครับ ซึ่งเจ้า Decorator มันมาช่วยตรงนี้ครับ ไม่ต้องแก้ แต่เราเพิ่ม (Wrap) ความสามารถใหม่ลงไป โดยที่ความสามารถเดิม ยังคงอยู่ ลดจำนวน Sub Class ลงได้ สนับสนุนแนวคิด Open-Close Principle ด้วย…

[Design Pattern] Observer Pattern in Depth

คราวนี้มาเป็น Pattern ที่ 2 แล้วที่ผมเขียนในเรื่อง Design Pattern in Depth โดยตอนนี้ขอเขียนเกี่ยวกับ BNK48 แล้วกันครับ น้องเณอปราง ^___^ ทำไมต้องใช้ Observer Pattern ถ้า Design ด้านแนวคิดที่ว่า อยากรู้ให้มาถาม (Server) สิ่งที่เกิดขึ้น คือ Client ต้องคอยวิ่งมาถาม (Request) ตรวจสอบว่าข้อมูลที่ Server มัน Update ยัง … Update ยังงง ถ้าเกิดข้อมูลที่ต้องกระจายเป็นข้อมูลของวง Girl Group อย่าง BNK48…

[Design Pattern] Strategy Pattern in Depth

ภาพจาก https://commons.wikimedia.org/wiki/File:John_Lavery_-_IWM_War_Room.jpg

วันนี้ Blog นี้มาเน้นทางสาย Pattern กันเยอะ เชื่อว่าหลายๆคน Copy & Paste Development มาใช้งาน แต่ก็ไม่รู้ว่า มัน คือ อะไรครับ โดย Pattern ที่ผมมาเขียนลง Blog ในวันนี้ คือ Strategy Pattern ซึ่งข้อมูลส่วนใหญ่ผมเอามาจากของ Head First นะครับ ตัวอย่างมันอธิบายได้ง่ายดีครับ ทำไมต้องใช้ Strategy ทุกปัญหามันไม่สามารถแก้ไขด้วยกับใช้เทคนิคเดิมของ OOP – Inheritance ได้ไง ? ตัวอย่าง เช่น นายเจมส์ได้รับหน้าที่ในการสร้าง Class ของ Duck…

[CUSE] Midterm ของเทอมที่ 3

วันนี้เพิ่งสอบ Midterm เสร็จครับ จริงๆ อาจารย์บอกว่ามันเป็น Quiz แต่ก็เป็น Quiz ที่จั่วหัวที่หน้าแรกว่า Midterm Examination 2/2560 สำหรับวิชาที่สอบวันนี้เป็นวิขา Enterprise Application Architecture ซึ่งหัวข้อทีได้เรียนไปในช่วงก่อน Midterm มันทำให้เห็นมิติใหม่ของ UML และการ Design ครับ โดยเนื้อหาที่เรียนไป Revised OOP Class/Object Relation ของ OOP UML in different view Class Diagram Object Diagram Sequence Diagram Package…

Design Principle กับ Design Pattern

ก่อนจะมาเข้าเรื่องที่ลึกลงไป ผมอยากแนะนำ 2 คำนี้ก่อนครับ Principle แปลเป็นไทย คือ “หลักการ” แปลไทยเป็นไทย คือ สาระสำคัญที่ยึดถือเป็นแนวปฏิบัติ (ข้อมูลจากราชบัณฑิตยสถาน) Pattern แปลเป็นไทย คือ “รูปแบบ” แปลไทยเป็นไทย คือ แบบ, แผน, ตัวอย่าง, ทำแบบ, แบบอย่างอันดี, เอาแบบอย่าง กลับมาที่ Design Principle คือ หลักการออกแบบ Software โดยมีชุดแนวคิด หรือคำแนะนำ เพื่อป้องกันการออกแบบ Software ที่แย่ ที่ส่งผลทำให้มีการปรับแก้ไข (Customize) หรือ การดูแลรักษา (Maintenance) ยาก…

ทำไม Method หรือ Function ที่ดีควรมีความยาวไม่เกิน 1 หน้าจอ หรือ 20 บรรทัด หรือ กฏอื่นๆอีกมากมาย

สำหรับบางคนที่เพิ่งเรียนเรียน Programming หรือ เพิ่มเริ่มทำงานใหม่ๆ อาจจะสงสัยว่าทำไมอาจารย์ หรือ พี่ที่ทำงานถึงมีข้อกำหนดในการเขียน Code ขึ้นมา ซึ่งบางข้ออาจจะดูไม่จำเป็นเลย เช่น หากเรามองแค่ผิวเผินแล้ว อาจจะคิดในใจว่าต้องการความเป็นระเบียบ ให้ Code สวยงาม เพื่อที่เรา หรือคนอื่นมาเขียนต่อภายหลังได้ง่าย แต่ถ้ามองลึกๆลงไป มันอาจจะเป็นกุศโลบายอย่างหนึ่งก็ได้ ซึ่งแฝงไปด้วยแนวคิด และทฤษฏีที่ซับซ้อน โดยผมจะอธิบาย แต่ละข้อเลยยะครับ ข้อแรก Method ที่เขียนขึ้นมาควรจะไม่เกิน 20 บรรทัด หรือ แสดงไม่เกินไม่เกิน 1 หน้าจอ หากเรามองลึกลงไป ทำไมต้องไม่เกิน 20 บรรทัด หรือ 1 หน้าจอ ซึ่งแนวคิดนี้จะลึกให้เราต้องกำหนดการทำงานของ…

Cohesion VS Coupling

ในชีวิตการทำงานจริง การพัฒนาออกแบบ Software ระบบหนึ่งขึ้นมา คงไม่ได้มีเพียง File เดียว หรือ Method Main อย่างเดียวแน่ๆ เหมือนตอนที่เรียนอยู่ในมหาวิทยาลัย โดยการทำงานจริงนั้น เราต้องแบบระบบงาน Software ที่ทำอยู่ออกมาเป็น Module หรือ Component ต่างๆ และท้ายที่สุดได้ Class Diagram แต่เมื่อออกแบบเสร็จแล้ว เราจะมั่นใจได้อย่างไรว่า Code ที่เราออกแบบนั้น ไม่มีการทำงานที่ซับซ้อน หรือมีโครงสร้างที่ซับซ้อนมากเกินไป จนทำให้ในอนาคตเมื่อมีการแก้ไข Code นั้นแล้วอาจจะทำให้กระทบไปทั้งระบบ แล้วเราจะมีวิธีจัดการอย่างไงให้สามารถลดความซับซ้อนของระบบได้ ผมขอแนะนำแนวคิด 2C ได้แก่ Cohesion และ Coupling (ลองดูรูป…