23 GOF Design Pattern

Creation Patterns

• Factory Method pattern
• Abstract Factory pattern
• Builder pattern
• Singleton pattern
• Prototype pattern จะคล้ายกับ Singleton แต่ว่าสามารถสร้างได้หลายตัว สำหรับ Java คือการใช้ .clone()

Structural Patterns

• Adapter pattern
• Bridge pattern
• Composite pattern
• Decorator pattern
• Facade pattern
• Proxy pattern
• Flyweight pattern ก็คือการเก็บข้อมูลลง cache หรือ buffer สำหรับข้อมูลน้อยๆ แต่ใช้บ่อยๆ ซึ่งจะเกี่ยวข้องกับ Singleton และ Factory pattern เพื่อ Performance, Scalability, Stability

Behavioral Patterns

• Chain of Responsibility pattern
• Command pattern - Encapsulate requests for service form and object inside other objects, thereby letting you manipulate the requests in various ways.
• Interpreter pattern
• State pattern
• Memento pattern มันจะใช้ร่วมกับ State pattern โดย Memento เป็น storage ที่เราเอา State เข้าไปเก็บ
• Iterator pattern เป็นการเข้าไปหยิบข้อมูลจาก Memento
• Mediator pattern
• Observer pattern
• Strategy pattern
• Template Method pattern
• Visitor pattern

Reference:

Design Patterns

Visitor Pattern

เป็นส่วนที่ไปทำงานบนระบบอื่น เพื่อให้ระบบอื่นเรียกใช้

Mediator Pattern

Interpreter Pattern

เป็นการแปลงข้อมูลจาก format หนึ่งไปยังอีก format หนึ่ง หรือการ convert ข้อมูล

ตัวอย่างของ Interpreter pattern เช่น parser, XML parser

Builder Pattern

Bridge Pattern

Bridge pattern will decouple an abstraction from its implementation so that the two can vary independently

แต่จะทำให้ระบบมีความซับซ้อนขึ้น และมี performance ต่ำลง แต่ว่าจะช่วยให้ระบบมีความยืดหยุ่นมากขึ้น

State Pattern

The State Pattern allows an object to alter its behavior when its internal state changes. The object will appear to change its class.

Proxy Pattern

โดยเมื่อก่อนใช้คำว่า Stub โดยมี Skeleton เป็น implementation หรือ object เป็นตัวที่ตรงกันข้ามกับ Facade คือเป็นตัวกั้นทางออก กั้น request จากภายในระบบกับระบบภายนอก

Observer Pattern

The Observer Pattern defines a one-to-many dependency between objects so theat when one object changes state, all of its dependents are notified and updated automatically.

Observer เช่น เรา subscribe blog เอาไว้ เมื่อมีการ publish subject ใหม่ ก็จะส่ง subject นั้นๆ มาให้ เป็นลักษณะเดียวกับ Event-base system, Event-driven system หรือที่ใช้กันใน Listener
ข้อเสียคือถ้ามี hacker เข้ามา hacker ก็จะเห็นข้อมูลเหมือนกับ observer 

Observer มีอยู่ 2 แบบ

1. publish
2. subscribe

Template Pattern

เป็นการทำ template ไว้ให้เลย

Singleton Pattern

The Singleton Pattern ensures a clas has only one instance, and provides a global point of access to it.

Factory Pattern

The Factory Method Pattern defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

The Abstract Factory Pattern provides an interface for creating families of related or dependent objects without specifying their concrete classes.
Abstract Factory จะเป็น Interface สำหรับ Factory Class เพื่อให้ Factory Class ในระบบมี pattern เดียวกัน เช่น มีชื่อ Factory Method เดียวกัน

Facade Pattern

เป็นตัวกั้น request จากภายนอกที่จะเข้ามาเรียกการทำงานภายในระบบ

ตัวอย่างของ Facade pattern เช่น Front Controller ซึ่งเป็นตัวกั้น request จาก UI กับระบบภายใน

Decorator Pattern

The Decorator Pattern attaches additional reponsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Iterator Pattern

Composite Pattern

Compose objects into tree structures to represent part

Strategy Pattern

The Strategy Pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
มักใช้ร่วมกันกับ Bridge pattern

Strategy Pattern เป็น pattern ที่เปลี่ยนแนวความคิดจากการใช้ Inheritance มาเป็น Composition แทนซึ่งมีความยืดหยุ่นกว่า และเป็น pattern ที่ใช้ในอีกหลายๆ pattern ด้วย

Design principle

• Encapsulate what varies. - Identify the aspects of your application that vary and separate them from what stays the same.
• Program to an interface, not an implementation.

• Favor composition over inheritances.

• Strive for loosely coupled designs between objects that interact.

• Classes should be open for extension, but closed for modification.

• Depend upon abstractions. Do not depend upon concrete classes.

• Only talk to your friends.

• Don't call us, we'll call you.

• A class should have only one reason to change.

หรือในอีกมุมหนึ่งจะดูตามหัวข้อ

• Communication Path and Access Channel 
• Communication Path เป็นการกำหนดเส้นทางสือสารระหว่าง Element ต่างๆ
• Access Channel เป็นการกำหนดการเข้าถึง Element

• Coupling and Cohesion
• Modularity คือการกำหนดหน้าที่ (method) และคุณสมบัติ (property) ให้โมดูลมีความสมบูรณ์ และมีความอิสระ ไม่พึ่งพาโมดูลอื่นๆ
• Classification ต้องใช้ Design Principle หลายชนิด 
• Association, Aggretation, Composition
• Hierarchy, Generalization, Specialization
• Packaging

• Hierarchy, Generalization and Specialization
• Information Hiding, Encapsulation and Abstraction
• Contract, Boundary and Interface Design
• Capability, Operation and Method
• Dispatch and Delegate
• Association, Aggregation and Composition

Reference: Head First Design Patterns - O'reilly

Software Quality

สำหรับคนทำงาน IT ทั้งคนวิเคราะห์ คนเก็บ requirement และทั้งสำหรับลูกค้าที่กำลังมองหา software


Software Quality (หรือเรียกว่า Quality Attribute) ซึ่งมีด้วยกันหลายตัว โดยระบบซอฟต์แวร์ควรจะต้องคำนึกถึง

• Availability ความพร้อมในการให้บริการ
• Modifiability สามารถปรับเปลี่ยนความสามารถได้
• Customizibility customize ได้ (เช่น หน้าจอ) 
• Extensibility เพิ่มเติมความสามารถ (feature) ภายหลังได้
• Integrability ทำงานติดต่อกับ legacy system ได้ เน้นด้าน low level เช่น OS, network, protocol
• Interoperability ทำงานร่วมกันได้ โดยปราศจากข้อจำกัด เน้น high level เช่นทำงานร่วมกับ function ต่างๆ
• Manageability 
• Maintainability
• Portability ทำงานข้ามแพลตฟอร์มได้
• Scalability รองรับการขยายตัวของการประมวลผลที่เพิ่มขึ้น (vertical, horizontal)
• Supportability รองรับ เช่น OS, virtual machine, hardware
• Performance ประสิทธิภาพ, การใช้ resource
• Security ความปลอยภัย (hardware, network, software)
• Safety ปลอดภัยต่อชีวิตและทรัพย์สิน สำหรับ software ที่เกี่ยวข้องกับความปลอดภัย เช่น software ควบคุมลิฟต์
• Testability ทดสอบได้
• Usability ใช้งานง่าย, ได้ประโยชน์ (การประมวลผล และความรู้สึก)

• Reliability มีความน่าเชื่อถือ (การประมวลผล และความรู้สึก)

โดยในระบบหนึ่งๆ อาจจะมี Key Quality (หรือเรียกว่า Architectural Driver) ประมาณ 4 - 7 ตัว ถ้ามากกว่า 7 ตัวจะเยอะเกินไป ยกเว้นในกรณีระบบใหญ่ๆ เท่านั้น

Thailand SPIN 2013

พอดีได้มีโอกาสไปงานค่ะ ไปงานสัมมนาหลังจากไม่ได้ไปงานแบบนี้มานานมาก เพราะไปทีไรก็รู้สึกว่าไม่ได้อะไรเท่าไร แต่อยากบอกว่างานนี้เป็นงานที่คิดว่าคุ้มค่ะที่ไป ไม่เคยได้เจองานสัมมนา IT แบบเสวนาแบบนี้เลย แต่ต้องบอกว่าประทับใจค่ะ ได้อะไรมากกว่าที่คิด

และอยากแชร์บางอย่างที่ได้มาเอาไว้ค่ะ ในงานช่วงเช้ามี section ของการเสวนา Do and Don't ซึ่งจากที่ได้ฟังมาย่อยได้ดังนี้ค่ะ (ขออภัยที่ใช้ภาษาอังกฤษ เพราะว่าตอนจดมาภาษาอังกฤษมันพิมพ์ได้เร็วกว่า)

Requirement phase

- Don't collect requirement from template. หรือถ้าจะใช้ก็ต้องใช้อย่างเข้าใจค่ะ
- Find problem first before requirement.
- Don't use same practice in different project.
- Tester should involve in requirement at requirement phase (almost finish phase), don't wait until test phase
- Don't call it requirement, because customer will be afraid to commit.

Analysis phase

- Don't use much time - do analyse very short, because requirement will continuously change .
- Reuse design as much as you can.
- If testers are for testing function, don't ask technical specification.
- Don't design alone. Do it with all team, with tester, BA, PM, customer, etc.
- Don't over design.

Coding phase

- Don't forget unit test.
- Send test data to developer.
- Tester don't need to ask developer for any to-do check list.
- Do unit test or automated test at coding phase.
- Make developer and tester work together.

Test phase

- Do defect management.
- Do root cause management.
- Do video record.
- Do test case priority.

Deploy phase

- Don't wait to deploy production at last. beware load balancing or other environment change, etc.

Maintenance phase

- Revise test case from production incident.
- Log incident.
- Don't forget production life cycle, that should include maintenance.
- Don't relocate staff frequently.

ทั้งนี้เป็นการย่อยความของตัวเอง ถ้ามีผิดพลาดประการใด ขอรับไว้แต่เพียงผู้เดียวค่ะ

นอกจากนี้ ยังได้ความรู้เกี่ยวกับ Agile Principles ด้วย ซึ่งหลายคนก็อาจจะรู้แล้ว ก็ข้ามไปค่ะ

Agile principles

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

ซึ่งทั้งนี้วิทยากรแนะนำว่าสำหรับใครที่จะทำ Agile ให้ดูเรื่อง TDD (Test Driven Development) ให้ดีๆ ค่ะ และควรจะหา automated test tools เพราะว่าการทำ Agile จะต้องทำ regression test บ่อยมาก

Reference: 

Principles behind the Agile Manifesto