มาถึงตอนสุดท้ายของ SOLID กันแล้วนะครับ ตัวสุดท้ายตัว  D ซึ่งมาจาก Dependency Inversion Principle (DIP) โดยที่ส่วนตัวผมเองนั้นคิดว่าหลักการข้อนี้ค่อนข้างมีประโยชน์และน่าจะเป็นที่รู้จักกันเยอะระดับนึงอยู่แล้วในโลกของการพัฒนา Software ช่วงนี้

DIP นั้นกล่าวว่า

Class ที่มีการเรียกใช้  Class อื่นๆนั้นไม่ควรที่จะมีการอ้างอิงถึงตัว Object ของ Class ที่ถูกเรียกตรงๆ แต่ควรที่จะเรียกผ่าน Interface หรือ Pointer ของ Base Class

เป้าหมายที่สำคัญของหลักการนี้เพื่อทำให้ Code นั้นมีการผูกติดกันให้น้อยที่สุดกับสิ่งที่เป็น Dependency ของ Class เรา

คำว่า Dependency ในกรณีนี้ก็คือ เช่น เรามี Class SmartPhone แล้วมี Data Member เป็น Object ที่สร้างจาก Class BluetoothDevice เช่น  Code ตัวอย่างนี้

class BluetoothDevice {
 public connect(){ /* do low level network tasks */}
 public scan(){}
} 

class SmartPhone {
 private bt : BluetoothDevice; // มีการถือ object BluetoothDevice ใน Class
 public init(){
   this.bt = new BluetoothDevice(); // มีการสร้าง Object ใน Class
 }
 public connectBluetooth(){
   this.bt.connect();
 }
}

จะเห็นว่า Code ข้างต้นนี้ออกแบบได้ถูกหลัก Single Responsibility แล้วเพราะเราทำการแยก Class ของ SmartPhone และ BluetoothDevice ออกจากกันตามหน้าที่ 🙂 ตามรูปด้านล่าง

Refactor

แต่ถึงอย่างนั้นด้วย DIP เราจะทำให้ Class นี้มี Design ที่ดีขึ้นไปอีกโดยที่เราจะใช้ Interface เป็นตัวกลางในการ Reference เช่นรูปด้านล่างนี้

ดังนั้น Code ที่ทำการ Refactor โดยการ Inversion แล้วก็จะมีหน้าตาแบบนี้แทนครับ

 interface IBluetooth {
   connect();
   scan();
 }
 class BluetoothDevice implements IBluetooth { // class นี้ทำการ implements interface
   public connect(){ 
     /* do low level network tasks */
     console.log('bluetooth connect');
   }
   public scan(){}
 } 
 class SmartPhone {
   private bt : IBluetooth; // อ้างถึง Bluetooth ผ่าน Interface ไม่ใช่ Object
   public init(bt : IBluetooth){ // มีการรับ Object ที่มี Interface IBluetooth เป็น Parameter
     this.bt = bt;
   }
   public connectBluetooth(){
     this.bt.connect();
   }
 }

จาก Code ด้านบนนี้จะเห็นว่า Class SmartPhone นั้นไม่ได้มีการอ้างอิงไปถึง Object ของ Class BluetoothDevice ตรงๆแล้วแต่จะใช้ Interface แทนครับ ทำให้การที่จะเรียกใช้ Method ที่ถูกต้องของ BluetoothDevice นั้นจะต้องมีการสร้าง Instance ของมันให้ถูก

.

.

Code ของฝั่งที่จะสร้าง Object หรือ Instance จาก Class SmartPhone จึงต้องเปลี่ยนไปเป็นเช่นนี้

let sp = new SmartPhone();
sp.init(new BluetoothDevice()); // ต้องสร้าง Object ของ BluetoothDevice ส่งไปให้
sp.connectBluetooth();

ซึ่งการทำการส่ง Object ที่เป็น Dependency ของอีก Class นึงเข้าไปแบบนี้คือการทำสิ่งที่เรียกว่า Dependency Injection ( DI ) นั่นเอง

.

Testable Code

ข้อดีที่เราจะได้รับจากการทำ DIP ก็คือการทำให้ Code ของเรานั้น Unit Test ได้ง่ายขึ้น

ลองคิดดูครับว่าถ้า Class BluetoothDevice ตัวจริงนั้นต้องไปต่อ Network จริงๆ แล้วเราจะเขียน Unit Test ของ Class SmartPhone ได้ยังไง

.

การทำ DIP นั้นจะทำให้เราสามารถ Inject Mock Dependency ลงไปได้เช่นดังตัวอย่างในรูปนี้

class MockBluetoothDevice implements IBluetooth {
 public connect(){
   console.log('just mock connect');
 }
 public scan(){
   console.log('just mock scan');
 }
}

Code ตอนเขียน UniTest

let sptest = new SmartPhone();
sptest.init(new MockBluetoothDevice()); // ส่งตัวปลอม(Mock) ของ BluetoothDevice ไป
sptest.connectBluetooth(); // ไม่ต้องไปต่อ Network จริงๆ

ก็จะเห็นว่า DIP นั้นช่วยทำให้ Code เราเขียน Test ได้ง่ายขึ้น แต่ทั้งนี้ทั้งนั้นทุกวันนี้เราจะเห็นว่ามี Framework ที่ช่วยทำ Dependency Injection มากมายเลยนะครับ แต่ผมอยากให้ทุกคนทราบกันว่านี่คือเบื้องหลังของมันรวมถึงที่มาที่ไปด้วย

เอาล่ะ มาถึงตรงนี้เป็นอันว่าจบหลักสูตร SOLID กันแล้วนะครับ สำหรับคนที่คิดว่ามันเยอะไปสำหรับ 5 หลักนี้ ผมก็คงแนะนำให้ทบทวน 2 ตัว คือ S กับ D ละกันครับ 🙂 และหวังว่าซีรี่ย์นี่จะเป็นประโยชน์กับหลายๆคนนะครับ

SOLID The Series:

มาถึงตอนที่ 4 ของซีรีย์ SOLID กันแล้วนะครับ กับตัว I ซึ่งตัวนี้ย่อมาจาก Interface segregation Principle (ISP)  ที่จะทำให้ Code ที่เขียนด้วยภาษา OOP นั้นดูดีมากขึ้นไปอีกขั้น 😉

ISP นั้นกล่าวถึงหลักการที่ว่า

Class ที่มา Implement เพื่อใช้งาน Interface นั้นๆไม่ควรที่จะต้องมา Implement Method ต่างๆให้ครบโดยที่อาจจะไม่ได้ใช้

ซึ่งถ้าตีความง่ายๆที่สุดเลยก็คือ เราควรอย่าไปกลัวกับการที่จะต้องสร้าง Interface ใหม่ เพราะโดนส่วนใหญ่ Developer อาจจะชอบเพิ่ม Method ใน Interface เดิม ซึ่งมันดูปลอดภัยมากกว่านั่นเอง

เราลองมาดูตัวอย่างกัน …

เริ่มแรกเลย

ผมมี Interface ชื่อ IPhone (ไม่ใช่ Appple iPhone นะครับ :D) ซึ่งมีด้วยกันทั้งหมด 6 Methods

interface IPhone {
        call();
        ring();
        installApp();
        addContact();
        connectWifi();
        connectMobile();
    }

ที่นีผมก็ลองสร้าง Class ชื่อ SmartPhone ที่จะมา Implement ตัว Interface IPhone ดูครับ

class SmartPhone implements IPhone {
 public call(){ /* do something /* }
 public ring(){/* do something /* }
 public installApp(){/* do something /* }
 public addContact(){/* do something /* }
 public connectWifi(){/* do something /* }
 public connectMobile(){/* do something /* }
}

เนื่องจากว่า SmartPhone นั้นมีความสามารถครบก็ดูโอเคดีครับที่เราจะออกแบบ Interface IPhone แบบนี้

แต่ถ้าผมมีอีก Class ชื่อ FeaturePhone ที่ต้อง Implement IPhone แต่ไม่สามารถ install App หรือ ต่อ wifi ได้ล่ะ ด้วยมันก็จะเป็นแบบนี้

class FeaturePhone implements IPhone {
 public call(){}
 public ring(){}
 public installApp(){
     throw new Error('Feature Phone does not support apps..');
 }
 public addContact(){}
 public connectWifi(){
     throw new Error('Feature Phone does not support using Wifi..');
 }
 public connectMobile(){}
 }

และถ้าเรามีอีก Class ชื่อ BasicTablet ที่มันทำอะไรไม่ค่อยได้นอกว่า install App กับต่อ wifi  มันก็จะเป็นแบบนี้

 BasicTablet implements IPhone {
 public call(){
    throw new Error('Basic Tablet does not support call..');
 }
 public ring(){
    throw new Error('Basic Tablet does not support ring..');
 }
 public installApp(){}
 public addContact(){
    throw new Error('Basic Tablet does not support contacts..');
 }
 public connectWifi(){}
 public connectMobile(){
    throw new Error('Basic Tablet does not support using mobile..');
 }
}

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

.

.

เริ่มการ Refactor

แน่นอนว่า Interface IPhone ที่สร้างไว้ตั้งแต่ต้นนั้นมันกว้างไป เทคนิคที่จะใช้ครั้งนี้คือ Extract Interface ซึ่งก็คือทำการแบบ Interface IPhone ออกมาเป็น Interface ย่อยๆตามกลุ่มของ Method ที่เรามี

ซึ่งถ้าเราสังเกตุดูจาก Interface IPhone นั้นจะมี Method อยู่ 3 กลุ่มคือ

1. โทร พื้นฐาน
2. การใช้งาน App
3. การเชื่อมต่อ

ดังนั้นหลักจากที่ทำการ Extract Method แล้วจะได้ผลแบบนี้ครับ

interface IPhone {
  call();
  ring();
  addContact();
}

interface ISmartFeatures {
  installApp();
}

interface IMobileConnect {
  connectMobile();
  connectWifi();
}

class SmartPhone implements IPhone, ISmartFeatures, IMobileConnect {

  public call(){}
  public ring(){}
  public installApp(){}
  public addContact(){}
  public connectWifi(){}
  public connectMobile(){}

}

class FeaturePhone implements IPhone, IMobileConnect {

  public call(){}
  public ring(){}
  public addContact(){}
  public connectMobile(){}
  public connectWifi() {
    throw new Error('Feature Phone does not support using Wifi..');
  }

}

class BasicTablet implements ISmartFeatures, IMobileConnect {

  public installApp(){}
  public connectWifi(){}
  public addContact(){}
  public connectMobile(){}
  public connectMobile(){ 
    throw new Error('Basic Tablet does not support using mobile..'); 
  }

}

มาถึงหลักการข้อ 3 ของ SOLID กันแล้วนะครับ สำหรับตัว L ซึ่งย่อมากจาก Liskov Substitution Principle (LSP)  ซึ่งกล่าวด้วยความ Abstact อีกแล้วว่า

Function ที่ใช้ reference หรือ Object ของ คลาสแม่ (Base Class) นั้นควรจะต้องสามารถใช้ Object ของคลาสลูกมันได้โดยไม่ต้องรู้รายละเอียดหรือข้อจำกัดของมัน

มาถึงตรงนี้ก็งงอีกเช่นเคยใช่มั้ยครับ เนื่องจากหลักการนี้เท่าที่ผมลองศึกษาดูก็มีการตีความหมายไปได้หลายทาง แต่ผมขออธิบายในสิ่งที่ผมเข้าใจละกันครับ ถ้าใครอยากเข้าใจมากขึ้นแนะนำให้ลองค้นคว้ามเพิ่มเติมดีกว่าครับ

…เอาล่ะ เราเป็น Developer เราก็มาลองดู Code กันดีกว่าครับ

*เช่นเดิม Code เขียนด้วย TypeScript

ก่อนอื่นเลยผมมี Class Phone ซึ่งมี  2 Methods คือ call() กับ installApp()

    class Phone {
        public call(){
            console.log('Make call...');
        }
        public installApp(){}
    }

ผมก็ได้ทำการเพิ่ม Class มาอีก 2 Classes คือ SmartPhone กับ FeaturePhone โดยการสืบทอดมาจาก Phone

แต่บังเอิญว่า FeaturePhone ดัน install App ไม่ได้เลยต้องทำการ Throw Exception ออกไป

    class SmartPhone extends Phone {
        public installApp(){
            console.log('SmartPhone install the app...');
        }
    }

    class FeaturePhone extends Phone {
        public installApp(){
            throw new Error('Feature Phone does not support install app...');
        }
    }

ถ้าผมที่ Code ฝั่งที่เรียกใช้ Phone จะเป็นแบบนี้ครับ

let phone = new Phone();
phone.installApp(); // ก็  Work ดี

let smPhone = new SmartPhone();
smPhone.installApp(); // ก็ Work ดี

let ftPhone = new FeaturePhone();
ftPhone.installApp(); // พัง เกิด Exception

ซึ่งจะเห็นได้ว่า ผมต้องมาแก้เป็นแบบนี้ เป็นกรณีพิเศษ เช่นต้องใช้ try/catch

try {
    ftPhone.installApp();
}

และนี่แหละคือการผิดหลักการออกแบบที่ดีของหลักการ LSP เพราะเราไม่สามารถเรียกใช้ Class ลูก (FeaturePhone) ได้แบบที่เหมือนเรียก Class แม่ (Phone) ซึ่งการที่เราจะรู้ได้ว่ามัน Throw Exception นั้นก็ต้องไปดู  Code ที่ถูก Implement ใน Class นั้น ซึ่งถ้าเป็น  Code ที่อยู่ใน Libary หรือพัฒนาโดยคนอื่นล่ะ มันก็คงจะดูไม่ได้ง่ายๆใช่มั้ยครับ

การจะแก้ไขปัญหานี้ที่ถูกต้องตามหลัก OO คือต้อง Refactor โดยใช้เทคนิคชื่อ Push Down Method ครับ (ก็คือย้าย Method ที่ไม่จำเป็นใน Class แม่ลงไปที่ Class ลูก)
ฉะนั้นผมจะได้ Class ใหม่แบบนี้แทน

    class Phone {
        public call(){
            console.log('Phone install the app...');
        }
    }
    
    class SmartPhone extends Phone {
        public installApp(){
            console.log('SmartPhone install the app...');
        }
    }

    class FeaturePhone extends Phone {
        // additional FeaturePhone feature e.g. multi sim cards
    }

สิ่งที่เปลี่ยนไปคือ

1. Method installApp() ถูกย้ายลงมาที่ SmartPhone
2. FeaturePhone จะไม่มี Method installApp() ให้เรียกแล้ว
3. ทำให้แก้ปัญหาที่ Code ที่ใช้เรียก ftPhone.installApp() แล้วต้องใช้ try/catch ไปได้! 🙂

SOLID The Series:

หลังจากที่พูดถึง S (หรือ Single Responsibility) ไปแล้วหลักการต่อมาก็คือ O ซึ่งย่อมาจาก  Open-Closed Principle ซึ่งเป็นหลักการที่ 2 ของ SOLID ที่มีใจความสำคัญแบบ Abstractๆ ว่า

เราควรออกแบบระบบให้ง่ายต่อการเพิ่มเติมอะไรใหม่ๆ โดยที่ไม่ต้องแก้ไขระบบเก่า (ถ้าไม่จำเป็น)

Open-Closed Principle (OCP) จะกล่าวถึงการออกแบบ Class หรือทั้งระบบให้ยืดหยุ่นมากขึ้น โดยที่เราใช้ความสามารถของ OOP มาช่วย โดยยกตัวอย่างเช่น ถ้าเราต้องเพิ่ม Feature ใหม่ให้ Class เรา จุดที่ควรจะแก้ไข Code นั้นควรจะเป็นจุดที่เหมาะสมและไม่ควรกระทบกับสิ่งที่ไม่ควรจะแก้ไข

อธิบายเพิ่มก็ยัง งง อีก…งั้นเรามาดูตัวอย่างกันดีกว่าครับ

เช่นเดิม ผมมี Class SmartPhone ซึ่งมี Constructor ที่มีการ Set ค่าต่างๆให้กับ Object ที่กำลังถูกสร้างตามชื่อ Model เช่น S10 หรือ 8s

*Code ตัวอย่างเป็น TypeScript

    
class SmartPhone {
    private phoneModel : string;
    private phoneFullName : string;
    private screenWidth : number;
    private screenHeigth : number;
    constructor(model : string){
       if(model ==='S10'){
          this.phoneModel ='S10';
          this.screenWidth =5;
          this.screenHeigth =10;
          this.phoneFullName ='Samsung Galaxy S10';
        }
        else if(model ==='8s'){
          this.phoneModel ='8s';
          this.screenWidth =4;
          this.screenHeigth =3;
          this.phoneFullName ='Apple iPhone 8s';
        }
    }
}

จาก Code นี้ถ้าผมทำการเพิ่ม Model ใหม่สิ่งที่ผมต้องทำคือผมต้องผมแก้ Contructor ของ Class SmartPhone โดยการเพิ่ม else if  แล้วทำการเพิ่ม Code ของ Model Nexus 9 เข้าไป

constructor(model : string){
       if(model ==='S10'){
          this.phoneModel ='S10';
          this.screenWidth =5;
          this.screenHeigth =10;
          this.phoneFullName ='Samsung Galaxy S10';
        }
        else if(model ==='8s'){
          this.phoneModel ='8s';
          this.screenWidth =4;
          this.screenHeigth =3;
          this.phoneFullName ='Apple iPhone 8s';
        }
        else if(model ==='Nexus 9'){
          this.phoneModel ='Nx9';
          this.screenWidth =5;
          this.screenHeigth =5;
          this.phoneFullName ='Google Nexus 9';
        }
}

   class SmartPhone { // Base Class
        protected phoneModel : string;
        protected phoneFullName : string;
        protected screenWidth : number;
        protected screenHeigth : number;
        constructor(){
            this.init();
        }
        protected init(){};
    }

    class S10Phone extends SmartPhone{// Inherited จาก Base Class
        protected init(){
            this.phoneModel = 'S10';
            this.screenWidth = 5;
            this.screenHeigth = 10;
            this.phoneFullName = 'Samsung Galasy S10';
        } 
    }

    class i8sPhone extends SmartPhone{// Inherited จาก Base Class
        protected init(){
            this.phoneModel = '8s';
            this.screenWidth = 4;
            this.screenHeigth = 3;
            this.phoneFullName = 'Apple iPhone 8s';
        } 
    }

    class Nx9Phone extends SmartPhone{ // Inherited จาก Base Class
        protected init(){
              this.phoneModel ='Nx9';
              this.screenWidth =5;
              this.screenHeigth =5;
              this.phoneFullName ='Google Nexus 9';
        }
    }

SOLID The Series: