General & OO Design Principles

General design principles และ Object-Oriented design principles มีอยู่มากมาย เชื่อว่าหลายคนคงคุ้นเคยพอสมควรกับคำศัพท์เหล่านี้ แต่จะชำนาญและเข้าใจลึกซึ้งในความหมายและการนำไปประยุกต์กับงานออกแบบมากน้อยเพียงใด? ลองมาทบทวนกันครับ เพื่อให้พื้นฐานการออกแบบซอฟต์แวร์ของเราแข็งแกร่งยิ่งๆ ขึ้นไป…

*พื้นฐานการออกแบบในแนวคิด Object-Orientation สามารถนำไปใช้กับการออกแบบซอฟต์แวร์อะไรก็ได้และภาษาโปรแกรมอะไรก็ได้ แต่ก็มีระบบบางประเภทที่ไม่เหมาะกับ OO design principle บ้าง เช่น การออกแบบ service เพราะบางจุดในการออกแบบ service อาจเหมาะกับแนวคิดแบบ functional design มากกว่า… ดังนั้นการจะออกแบบซอฟต์แวร์หรือระบบลักษณะใด ควรเลือกใช้พื้นฐานการออกแบบหรือแนวคิดการออกแบบให้เหมาะสมด้วยนะครับ สำหรับแนวคิดเรื่อง service design principle ไว้มีโอกาสจะนำมาเล่าสู่กันต่อไปครับ…

มาลุยกันเลย…

Functionality, Non-Functionality

  • Functionality คือ การทำงานของระบบที่สนับสนุนไคลเอ็นต์โดยตรง อาทิ การล็อกอิน, การส่งคำสั่งซื้อ, การดูรายงานยอดขาย เป็นต้น
  • Non-Functionality คือ การทำงานภายในระบบที่ไม่ได้สนับสนุนไคลเอ็นต์โดยตรง ส่งผลต่อการทำงานและคุณภาพของ Functionality และNon-Functionality มักเรียกใช้กันเอง มีชื่อเรียกหลายชื่อ อาทิ Architectural Mechanism (กลไกทางสถาปัตยกรรม), ในทาง AOP (Aspect-Oriented Programming) เรียก ‘Cross-Cutting Concern’ อาทิ transaction management, logging, authenticate, authorization, concurrency control, encrypt-decrypt, data access, cache เป็นต้น


Recursive

  • Recursive คือ การทำงานแบบวนซ้ำ มีโครงสร้างพื้นฐานหลายรูปแบบ อาทิ For Loop, While Loop ในแนวทางแบบ Object-Orientation มีการทำงานคล้ายกันเรียกว่า ‘Enumeration’ และ ‘Iteration’ ซึ่งเป็นการทำงานแบบวนซ้ำ โดยมีประเด็น Encapsulation และ Polymorphism เข้ามาเกี่ยวข้อง
  • Recursive เป็นพื้นฐานสำคัญทั้งในการออกแบบระบบและเขียนโปรแกรม โดยเฉพาะในการออกแบบอัลกอริธึม, การออกแบบทรานแซกชั่น, การจัดการด้าน performance ถึงแม้เป็นพื้นฐานที่ ‘พื้นๆ’ แต่ในบางสถานการณ์หากออกแบบไม่ดีก็สามารถสร้างโอเวอร์เฮดซึ่งส่งผลต่อ performance ได้

Data Structure, Type Conversion

  • Data Structure คือ โครงสร้างข้อมูล ซึ่งในปัจจุบันมีหลากหลายมากขึ้น แตกต่างกันไปตามแต่ละภาษาโปรแกรมและเฟรมเวิร์ก การออกแบบระบบที่ดีจึงควรมีพื้นฐานด้าน Data Structure ของภาษาโปรแกรมและเฟรมเวิร์กที่จะใช้เป็นอย่างดี และเลือกใช้ให้เหมาะสม ถึงแม้ว่าอาจไม่ได้เขียนโปรแกรมแล้ว แต่จะทิ้งความรู้ด้านนี้ไม่ได้
  • Type Conversion คือ การแปลงชนิดข้อมูล (data type) เช่นเดียวกันกับ Data Structure เพราะเป็นพื้นฐานสำคัญ จะออกแบบระบบใดก็ตาม ต้องมีพื้นฐานด้าน data type ของภาษาโปรแกรมที่จะใช้เป็นอย่างดี อาทิ มี data type กี่ประเภท, แบบไหนเป็น mutable แบบไหนเป็น immutable, data type แต่ละชนิดมีขนาดกี่ bit กี่ byte, การสร้างและลบตัวแปรสำหรับ data type แต่ละชนิดต้องทำอย่างไร ส่งผลแตกต่างกันอย่างไร เป็นต้น
  • แต่ละภาษาโปรแกรมอาจมีเทคนิคการทำ Type Conversion ที่แตกต่างกัน จึงต้องมีพื้นฐานตรงนี้ให้มากๆ เพราะการทำ Type Conversion อาจเกิดโอเวอร์เฮดสูงส่งผลต่อ performance ได้

Passing, Communication

  • Passing คือ การรับ-ส่งข้อมูลระหว่างอิลิเม้นต์ ซึ่งต้องเลือกใช้ให้เหมาะสมกับ: การทำงาน, ภาษาโปรแกรม, รูปแบบเน็ตเวิร์ก, รูปแบบสถาปัตยกรรม เป็นต้น
  • Passing ต้องคำนึงถึง Granularity ด้วยเสมอ เพราะปริมาณและขนาดข้อมูลที่รับ-ส่งกันส่งผลต่อ I/O
  • Communication คือ การสื่อสารระหว่างอิลิเม้นต์ต่างๆ ซึ่งมีหลายรูปแบบ อาทิ inter-process communication, intra-process communication, local call, remote call, synchronous call, asynchronous call, sequential call, concurrently call เป็นต้น
  • Communication ต้องพิจารณาเลือกใช้รูปแบบให้เหมาะสมกับงาน
  • การสื่อสารภายในเครื่อง-ผ่าน Bus, การสื่อสารระหว่างเครื่องผ่าน-Network

Coupling, Cohesion

  • Coupling คือ การทำงานของอิลิเม้นต์มีการขึ้นต่อส่วนอื่น ส่วน Cohesion มีความหมายตรงข้ามกับ Coupling
  • Coupling & Cohesion มีวัตถุประสงค์เพื่อกำหนดหน้าที่ของอิลิเม้นต์ให้ชัดเจน,  จำกัดการพึ่งพาอาศัยอิลิเม้นต์อื่นให้อยู่ในระดับที่เหมาะสม, ลดโครงสร้างระหว่างอิลิเม้นต์ที่ซับซ้อน, ลดผลกระทบจากการทำงานของอิลิเม้นต์อื่น ซึ่งมีผลต่อคุณภาพหลายด้าน เช่น modifiability, performance, availability, security เป็นต้น
  • การออกแบบที่ดีควรเป็น ‘Low Coupling & High Cohesion’
  • Loose Coupling เลยก็ไม่ดี เพราะอาจทำให้ระดับ Cohesion สูงมากเกินไป อาจส่งผลกระทบ เช่น เกิดความซ้ำซ้อนระหว่างอิลิเม้นต์, ระดับการ reuse ลดลง
  • Coupling มีหลายประเภท อาทิ Content Coupling (High), Common Coupling, External Coupling, Control Coupling, Stamp Coupling, Data Coupling, Message Coupling (Low), No Coupling (ไม่มี Coupling โดยไม่มีการสื่อสารกับใคร)

Dependency

  • Dependency คือ การอาศัยพึ่งพาอิลิเม้นต์อื่น ในด้านการทำงานหรือข้อมูล
  • Dependency มีความหมายคล้าย Coupling แต่กว้างกว่าเล็กน้อย อาทิ
    • ความสัมพันธ์ระหว่าง implementation class กับ interface โดยคลาสที่อิมพลีเม้นต์อินเตอร์เฟสจะเกิดความสัมพันธ์แบบ Dependency ด้วยเสมอ เพราะ specification ของเมธอดขึ้นกับ specification ของ operation ที่กำหนดในอินเตอร์เฟส
    • การ call กันระหว่างอิลิเม้นต์ เช่น A เรียกเมธอดของ B ก็ทำให้เกิด Dependency ระหว่าง A กับ B เรียกว่า A มี Dependency กับ B
  • Dependency ยังใช้วิเคราะห์ผลกระทบ (Impact Analysis) เพราะจะทำให้ทราบว่าแต่ละอิลิเม้นต์มีการพึ่งพาหรือขึ้นต่อกันกับอิลิเม้นต์ใดบ้าง หากมีการเปลี่ยนแปลงที่อิลิเม้นต์ใดอิลิเม้นต์หนึ่งอาจส่งผลกระทบต่ออิลิเม้นต์ใดบ้าง ซึ่งการวิเคราะห์ผลกระทบนี้คล้ายกับการวิเคราะห์ผ่าน Coupling นั่นเอง

Contract, Boundary, Interface Design

  • Contract คือ ข้อตกลงร่วมกันระหว่างผู้ใช้บริการ (เช่น ไคลเอ็นต์) และผู้ให้บริการ (เช่น เซอร์วิส) หาก Contract มีการเปลี่ยนแปลงจะกระทบทั้ง 2 ฝั่ง โดยเฉพาะกระทบผู้ใช้บริการมากกว่า
  • Contract สามารถเป็นอินเตอร์เฟสในระบบ, หน้าจอ, API, Web Service เป็นต้น
  • Boundary คือ การกำหนดขอบเขตระหว่างไคลเอ็นต์ที่จะเรียกใช้ระบบ กับระบบที่จะเรียกใช้ทรัพยากรหรือระบบภายนอก โดยการออกแบบระบบที่ดีควรกำหนดขอบเขตการจัดการ request ที่จะเข้ามาในขอบเขตระบบ และการส่ง request ออกไปนอกขอบเขตระบบ
  • Interface Design คือ การออกแบบข้อกำหนดการให้บริการ เช่น บริการของระบบ, ของโมดูล, ของคลาส เป็นต้น โดยทั่วไปอินเตอร์เฟสประกอบด้วย operation ซึ่งประกอบด้วยชื่อ operation, parameter และ output การกำหนดอินเตอร์เฟสก่อนเป็นการระบุว่ามีบริการอะไรบ้างที่ให้เรียกใช้ได้ โดยยังไม่จำเป็นต้องนึกถึงการอิมพลีเม้นต์ บางครั้งเรียกว่าเป็นการออกแบบ Interoperation (การทำงานร่วมกัน) เพื่อกำหนดข้อตกลงการทำงานร่วมกัน (การ call กัน) ระหว่างระบบ/โมดูล/คลาส

Modularity

  • Modularity คือ การกำหนดหน้าที่ (เช่น operation, method, function, service) และคุณสมบัติ (เช่น property, class variable) ให้โมดูลมีความสมบูรณ์ในตัวเอง มีความอิสระโดยไม่ต้องพึ่งพาการทำงานหรือคุณสมบัติของโมดูลอื่น
  • Modularity สอดคล้องกับการกำหนด Coupling และ Cohesion ของโมดูล
  • โมดูลที่มี Modularity ที่ดีจะช่วยเพิ่มระดับการ reuse, ง่ายต่อการนำไปใช้, จัดการและปรับปรุงง่าย ไม่เกิดผลกระทบข้างเคียงสูง, ไม่ได้รับหรือได้รับผลกระทบจากโมดูลอื่นน้อย

Classification

  • Classification คือ การจัดวางโครงสร้างคลาสและอินเตอร์เฟส เพื่อช่วยในการจัดกลุ่มสิ่งที่สัมพันธ์กันและจำแนกกลุ่มหรือประเภทของคลาส
    • Classification ต้องอาศัย Design Principle หลายชนิดร่วมกัน อาทิ
    • Association, Aggregation และ Composition เพื่อแสดงความสัมพันธ์ระหว่างคลาส และแสดงการประกอบกันระหว่างคลาส
    • Hierarchy, Generalization และ Specialization เพื่อกำหนดลำดับชั้นโครงสร้างของคลาสหรืออินเตอร์เฟส เช่น การกำหนด super class, child class เป็นต้น
      Packaging เพื่อจัดกลุ่มคลาสและอินเตอร์เฟส
  • Classification มีความสำคัญมาก เพราะช่วยจัดกลุ่ม, ช่วยลดความซ้ำซ้อน ช่วยให้เห็นความสันพันธ์ระหว่างกัน, ช่วยวิเคราะห์ผลกระทบ เป็นต้น
  • Classification สามารถใช้เพื่อจัดวางโครงสร้างโมดูลด้วยก็ได้ ทำให้เห็นความสัมพันธ์ระหว่างโมดูลชัดเจนขึ้น

Hierarchy, Generalization, Specialization

  • Hierarchy คือ การจัดวางลำดับชั้นของคลาสและอินเตอร์เฟส ทำให้เห็นถึงระดับของรายละเอียดและความเฉพาะเจาะจงที่มากน้อยต่างกันในแต่ละระดับ โดยปกติระดับยิ่งสูงยิ่งมีรายละเอียดและความเฉพาะเจาะจงน้อย ส่วนระดับยิ่งต่ำก็จะตรงข้ามกัน
  • Hierarchy สามารถจัดวางได้ 2 ทิศทาง ได้แก่
    • Generalization (Bottom-Up) คือ การพิจารณาตัวร่วมและความคล้ายกัน (general/commonality) ของคลาสหรืออินเตอร์เฟส แล้วแยกสิ่งเหล่านั้นออกมาต่างหาก จัดวางไว้ในระดับชันที่สูงขึ้น ถ้าเป็นคลาสก็เรียกว่า ‘super class’ หรือ ‘base class’ ถ้าเป็นอินเตอร์เฟสเรียกว่า ‘super interface’ หรือ ‘base interface’
    • Specialization (Top-Down) คือ การพิจารณาคลาสหรืออินเตอร์เฟสเพื่อระบุความสามารถ (operation/method) และ/หรือคุณสมบัติ (property) ที่จะมีเพิ่มเติม, เฉพาะเจาะคงมากกว่า และ/หรือแตกต่างจาก super class หรือ super interface แล้วแยกสิ่งเหล่านั้นออกมาต่างหากเป็นคลาสใหม่หรืออินเตอร์เฟสใหม่ ถ้าเป็นคลาสก็เรียกว่า ‘child class’ หรือ ‘sub class’  ถ้าเป็นอินเตอร์เฟสเรียกว่า ‘extended interface’

Association, Aggregation, Composition

  • Association คือ ความสัมพันธ์เชิงโครงสร้างระหว่างคลาส มีการประกอบหรือเป็นส่วนหนึ่งของกันและกัน ไม่ใช่แค่มีความสัมพันธ์กันเพราะมีการเรียกใช้เมธอดของอีกฝ่าย
  • Association สามารถระบุคุณภาพอื่นๆ ประกอบได้ เช่น ชื่อความสัมพันธ์ (Association Name), บทบาท (Role), ทิศทาง (Navigability), จำนวนที่สัมพันธ์กัน (Multiplicity)
  • Aggregation คือ การประกอบกัน โดยแต่ละฝั่งสามารถแชร์กันคลาสหรือโมดูลอื่นได้
  • Composition คือ การประกอบกัน โดยฝั่งที่เป็นส่วนประกอบไม่สามารถแชร์กับคลาสหรือโมดูลอื่นได้

Information Hiding, Encapsulation, Abstraction

  • Information Hiding คือ การซ่อนข้อมูลที่ไม่จำเป็นต่อไคลเอ็นต์ เช่น ไม่มีประโยชน์, เป็นความลับ ซึ่งมีน้ำหนักด้านความปลอดภัยเกี่ยวข้องด้วย โดยข้อมูลสามารถเป็น business rule, technology, process เป็นต้น
  • Encapsulation คือ การจำกัดระดับการเข้าถึงหรือการส่ง request เข้ามาใช้อิลิเม้นต์ภายในระบบ/โมดูล/อ็อบเจ็คต์ ซึ่งมีน้ำหนักด้านความปลอดภัยเกี่ยวข้องด้วย โดยอิลิเม้นต์ที่อยู่ภายใน อาจเป็นแอททริบิวต์, เมธอด, โมดูล, เซอร์วิส, ระบบ, ทรัพยากร เป็นต้น
  • Abstraction คือ การนำเสนอความเรียบง่ายและลดความซับซ้อนที่ไม่จำเป็นต่อไคลเอ็นต์ เพื่อให้ไคลเอ็นต์เข้าถึงและเข้าใจได้ง่าย ซึ่ง Abstraction สามารถมีได้หลายระดับ เรียกว่า ‘Level of Abstraction’
  • Abstraction ยังเกี่ยวข้องกับ Hierarchy, Generalization และ Specialization เพราะโดยทั่วไปยิ่งอยู่ระดับสูงยิ่งมีระดับ Abstraction สูง (มีรายละเอียดและความเฉพาะเจาะจงน้อย หรือยิ่งมีระดับความเป็นนามธรรมสูง)

Capability, Operation, Method

  • Capability คือ ความสามารถหรือบริการของเซอร์วิส (เช่น เว็บเซอร์วิส) ที่เปิดให้ไคลเอ็นต์เรียกใช้ได้ มักใช้ในระดับเซอร์วิส มีระดับความเป็นนามธรรมสูง ไม่ลงรายละเอียดด้านเทคนิคมาก
  • Operation คือ บริการของคลาสหรืออินเตอร์เฟสที่เปิดให้ไคลเอ็นต์เรียกใช้ได้ โดยไม่สนใจการอิมพลีเม้นต์ และไม่มี Coupling กับส่วนอิมพลีเม้นต์ โดย Operation ประกอบด้วย ชื่อ, parameter และ output
  • Method คือ บริการของคลาสที่มีส่วนการอิมพลีเม้นต์อยู่ภายในนั้น ซึ่งเป็นวิธีการที่คลาสอิมพลีเม้นต์ Operation ของ super class หรืออินเตอร์เฟส ทำให้ Method อาจมี Coupling กับ Operation และคลาสหรืออินเตอร์เฟสที่อิมพลีเม้นต์มาได้
  • การออกแบบระบบ/โมดูล/อินเตอร์เฟส/คลาส ควรออกแบบมุ่งเน้น System Behavior หรือเรียกว่า ‘Behavior-Driven Design’ โดยมุ่งเน้นระบุ Capability และ Operation ก่อนยังไม่ต้องรีบคิดถึงวิธีการทำงานภายใน จากนั้นค่อยออกแบบ Method ซึ่งเป็นการทำงานภายในต่ออีกที

Polymorphism

  • Polymorphism คือ การทำงานภายใต้ข้อกำหนดเดียวกันที่สามารถมีได้หลายรูปแบบ
  • ข้อกำหนดดังกล่าวคือ Operation ที่ประกอบด้วย 1) ชื่อ operation 2) พารามิเตอร์ 3) return type
  • Polymorphism มาจากภาษาละตินรวมกัน คำว่า poly แปลว่าหลากหลาย, จำนวนมาก ส่วน morph แปลว่าเปลี่ยนรูปแบบได้
  • Polymorphism ช่วยให้เกิดความยืดหยุ่นสูง

Implementation, Realization

  • Implementation คือ การทำงาน (How) ตามข้อกำหนด (What) ซึ่งอาจมีรูปแบบการทำงาน (เช่น อัลกอริธึม) ได้มากกว่า 1 แบบ, ข้อกำหนดในที่นี้อาจเป็น operation ในอินเตอร์เฟส, operation ในเซอร์วิส, กฏเกณฑ์ เป็นต้น
  • Implementation ทั้งหลายภายใต้ข้อกำหนดเดียวกัน ทำงานแตกต่างกันอันเนื่องจากสาเหตุ อาทิ สภาพแวดล้อมแตกต่างกัน, ไคลเอ็นต์ที่เรียก operation แตกต่างกัน, สิทธิของไคลเอ็นต์แตกต่างกัน, ค่าของพารามิเตอร์แตกต่างกัน ฯลฯ
  • Implementation มี Coupling/Dependency กับข้อกำหนด (เช่น อินเตอร์เฟส) ของมันเสมอ ดังนั้นหากข้อกำหนดมีการเปลี่ยนแปลงจีงกระทบ Implementation เสมอ
  • Realization คือ การนำข้อกำหนดหรือข้อมูลที่มีความเป็นนามธรรม (Abstract) สูง มาต่อยอดเพื่อสร้างรูปแบบการทำงาน หรือนำเสนอให้เห็นชัดเจนเป็นรูปธรรม (Realistic) ยิ่งขึ้น อาทิ การสร้างคลาสอิมพลีเม้นต์อินเตอร์เฟส, การนำภาพสเก็ตช์มาวาและระบายสีให้ชัดเจนยิ่งขึ้น เป็นต้น

Binding

  • Binding คือ การเชื่อมต่อ ที่มักใช้อธิบายการเชื่อมโยงตัวแปรให้เข้ากับอ็อบเจ็คต์ อาทิ
    • Static Binding คือ การเชื่อมโยงตัวแปรแบบคงที่ เช่น

User u = new User()

    • Dynamic Binding คือ การเชื่อมโยงตัวแปรโดยที่ type ของตัวแปรเป็นคนละชนิดกับ type ของอ็อบเจ็คต์ เช่น

User u = new Employee()// Employee คือคลาสที่สืบทอดคลาส User

Service s = new MyService() // MyService คือ คลาสที่อิมพลีเม้นต์อินเตอร์เฟส Service

  • Late Binding คือ การเลื่อน (defer) การเชื่อมโยงตัวแปรกับอ็อบเจ็คต์ออกไปจากซอร์สโค้ด มีหลายรูปแบบ อาทิ
    • Configuration Binding คือ กำหนดการเชื่อมโยงในคอนฟิกฯ
    • Runtime Binding คือ กำหนด/รับรู้การเชื่อมโยง ณ ขณะ runtime
  • Binding มีผลต่อความยืดหยุ่น (Flexibility) ทำให้ modify implementation class ได้ง่าย ไม่มีผลกระทบ และไม่ต้องแก้ไขซอร์สโค้ดเลย หรือแก้ไขน้อย

Primitive

  • Primitive มีความหมายทำนอง: พื้นฐาน, ดั้งเดิม, ขั้นต้น, เรียบง่าย, ไม่ซับซ้อน
  • Data type ที่เป็น Primitive Type อาทิ integer, boolean, double, long, char เป็นต้น
  • Primitive Design คือ การออกแบบที่เน้นพื้นฐาน เรียบง่าย ไม่ซับซ้อน ซึ่งการออกแบบที่ดีจึงควรเริ่มต้นที่หลักการเหล่านี้ ก่อนที่จะต่อยอดเพิ่มเติมรายละเอียด โดยไม่เริ่มต้นการออกแบบด้วยความซับซ้อนก่อนโดยใส่รายละเอียดมากมายเข้าไป ทั้งที่ยังใช้เวลากับเนื้องานยังไม่มาก ซึ่งอาจทำหลุดจากภาพรวม หลุดจากกรอบขอบเขตสำคัญ และอาจเผลอใส่รายละเอียดที่เกินจำเป็นในจุดที่ไม่จำเป็น
  • ทัศนคติและมุมมองของผู้ออกแบบเป็นสิ่งสำคัญ ส่วนความรู้และประสบการณ์เป็นปัจจัยเสริมที่ดีเยี่ยม
  • Primitive Design เป็นแนวทางแก้ไขปัญหาด้วยการเริ่มต้นที่การใช้หลักการพื้นฐาน (Principle) ก่อนเสมอ แทนที่จะเริ่มต้นด้วยการใช้เทคโนโลยี บางครั้งจึงดูเหมือนอนุรักษ์นิยมบ้าง แต่การแก้ปัญหาด้วย Principle คือแนวทางที่อยู่ยั้งยืนยง ไม่เปลี่ยนแปรง่ายและเร็วเหมือนเทคโนโลยี

Granularity

  • Granularity คือ การพิจารณาอิลิเม้นต์หนึ่งๆ ในประเด็นเกี่ยวกับ ขนาดและปริมาณ อาทิ ขนาดของอ็อบเจ็คต์, ขนาดของข้อมูล, ขนาดและปริมาณของ web service message ที่วิ่งอยู่บนเน็ตเวิร์ก
  • Granularity มี 2 ประเภทได้แก่
    • Coarse-Grained Granularity คือ อิลิเม้นต์ที่มีขนาดใหญ่, มีความ common สูง เช่น อ็อบเจ็คต์ Customer, เมธอด getProduct()
    • Fine-Grained Granularity คือ อิลิเม้นต์ที่มีขนาดเล็ก, มีความ common ต่ำ (มีความเฉพาะเจาะจงสูงกว่า) เช่น อ็อบเจ็คต์ Customer Address, เมธอด getProductId()
  • Granularity มีผลต่อ performance มากๆ เพราะหากอิลิเม้นต์ใดมีขนาดใหญ่ (Coarse-Grained Granularity) เกินไปก็ส่งผลต่อ storage หรือ I/O แต่หากมีขนาดเล็กเกินไปก็อาจทำให้เปลือง I/O ได้เช่นกัน เช่นกรณีต้องการข้อมูล Customer แต่เมธอดทั้งหมดเป็น Fine-Grained Method ทำให้ต้อง call อ็อบเจ็คต์ Customer หลายครั้ง การ call แบบนี้จึงเรียกว่า ‘Fine-Grained Call’
  • Granularity ยังมีผลต่อความยืดหยุ่นอีกด้วย เพราะในอีกมุมหนึ่ง Granularity เน้นด้าน Encapsulation เช่น การใช้ data type แบบ Coarse-Grained Type มาห่อหุ้ม Fine-Grained Field เล็กๆ เอาไว้

Reusability

  • Reusability คือ ความสามารถในการ Reuse ได้ของอิลิเม้นต์นั้นๆ อาทิ คลาส, อินเตอร์เฟส, คอมโพเน้นต์, รูปภาพ, process, ระบบ เป็นต้น
  • อิลิเม้นต์ใดที่มีระดับ Reusability ที่สูงแสดงว่ามีความยืดหยุ่นสูง ทำให้เปลี่ยนแปลงแก้ไขได้ง่ายมีผลกระทบต่ออิลิเม้นต์อื่นน้อย (high cohesion & low coupling)
  • ข้อเสียของ Reusability มีหลายประการ อาทิ ทำให้ cost ด้าน คน/เงิน/เวลา ในการออกแบบสูง, อาจทำให้ performance ตก เพราะอาจมี call เพิ่มขึ้น, หากมีระดับ Reusability สูงเกินไปแสดงว่าอาจยืดหยุ่นเกินความจำเป็น บางครั้งอาจทำให้มีความซับซ้อนเกินไป แต่หากจัดระเบียบลอจิกและจัดวางโครงสร้างที่ดีความซับซ้อนที่เกิดขึ้นอาจจัดการให้ง่ายได้ แต่ในทางปฏิบัติทำไม่ได้ง่ายนัก จึงต้องระวังการติดกับดัก ‘Reuse’ !!!
  • การพิจารณาว่าจะให้อิลิเม้นต์นั้นๆ มีระดับ Reusability มากแค่ไหน จึงควรพิจารณาถึงประโยชน์ในอนาคต, การเปลี่ยนแปลงที่อาจเกิดในอนาคต, การต่อยอดในอนาคต และต้องพิจารณาให้สอดคล้องกับข้อจำกัดด้าน ขอบเขตระบบ, ขอบเขตโครงการ, ระยะเวลารับประกันผลงาน, ระยะเวลา maintenance, ระยะเวลาสัญญา, การเปลี่ยนแปลงของเทคโนโลยีที่ใช้ซึ่งรวมถึง logic ต่างๆ เป็นต้น

Create, Destroy

  • ทรัพยากร/อิลิเม้นต์ใดๆ ย่อมมีวงจรชีวิต (Resource Lifecycle) และอาจคล้ายหรือแตกต่างกัน อาทิ create, initialize, run, destroy เป็นต้น
  • Create คือ การสร้าง, สำหรับการออกแบบจุดใดที่เน้น performance และความยืดหยุ่นมากๆ ควรคำนึงถึงการสร้างอิลิเม้นต์ต่างๆ ที่เกี่ยวข้องกับจุดนั้น ซึ่งรวมถึงการ acquire resource ด้วย โดยเมื่อทรัพยากรใดๆ ที่อาจมีรูปแบบการสร้างแตกต่างกัน ผู้ออกแบบจึงควรทราบเทคนิคในการสร้างทรัพยากรนั้นๆ เป็นอย่างดี คำนึงถึง performance และความยืดหยุ่นควบคู่กันเสมอ
  • Destroy คือ การลบหรือกำจัดทิ้ง เช่นเดียวกับ Create ที่ผู้ออกแบบควรทราบเทคนิคในการลบอิลิเม้นต์ชนิดนั้นๆ เป็นอย่างดี คำนึงถึง performance และความยืดหยุ่นเสมอ
  • Construction คือ การสร้างที่มักใช้กับการสร้างอ็อบเจ็คต์ หรืออิลิเม้นต์ที่มีกระบวนการสร้างที่ซับซ้อน
  • Destruction คือ การลบอิลิเม้นต์นั้นๆ ทิ้งเมื่อใช้งานเสร็จแล้ว

One thought on “General & OO Design Principles

ใส่ความเห็น

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s