Thinking About Clean Architecture For Enterprise Application (Story-2)

4 min readSep 19, 2021

solid principle illustration credit from Ugonna Thelma

ကျွန်တော်အခု clean ထဲမှာပါတဲ့ design principle ဖြစ်တဲ့ SOLID principles အကြောင်း ဆွေးနွေးကြည့်ရအောင်။ SOLID Principles ကို Robert C. Martin က Clean Architecture စာအုပ်ရဲ့ Design Principle and Design Patternsအခန်း မှာချပြခဲ့ပါတယ်။

အဲ့တာကိုယူပီး Michael Feathers ကပြန်ပီး တော့ revolution ပြန်လုပ်ခဲ့တာကနေပီးတော့ SOLID Principles တွေကို OOP (Object Oriented Programming) မှာရေးလာကြပါတယ်။

Thinking About Clean Architecture For Enterprise Application (Story-1)

ကျွန်တော်တို့ software ရေးတဲ့အခါနေ့ဒဓူ၀ပြသနာတွေရင်ဆိုင်ရပါတယ်။ ကျွန်တော်ဆိုလဲ နေ့တိုင်းခေါင်းတွေခဲ…

thawzintoe.medium.com

ဒါကတော့ Story 1 ပါ ။ Story 2 မဖတ်ခင် Story 1 လေးပီးအောင်ဖတ်ပေးပါ please

SOLID Principle ဆိုတာဘာလဲ?ဘယ်လိုပိုကောင်းအောင်လုပ်ပေးနိုင်လဲ?

SOLID Principle ဆို concept ငါးခုနဲ့ဖွဲ့စည်းထားပီးတော့ ပိုပီး software တွေကို maintainable , understanable နဲ့ flexible ဖြစ်အောင်လုပ်ပေးထားတာပါ။

အဲ့ concept ငါးခုကတော့

၁. The Single Responsibility Principle (SRP)

၂. The Open-Closed Principle (OCP)

၃, The Liskov Substitution Principle (LSP)

၄. The Interface Segregation Principle (ISP)

၅. The Dependency Inversion Principle (DIP)

ကဲကျွန်တော်တို့ example တွေနဲ့ deep dive သွားကြည့်ရအောင်

The Single Responsibility Principle (SRP)

Single Responsibility Principle ဆိုတာ class တစ်ခုက တာ၀န်တစ်ခုပဲရှိရမယ်။ အကြောင်းတစ်ခုခုကိုchange ခြင်တယ်ဆိုလဲ သူလုပ်တဲ့အလုပ်ပဲဖြစ်ရမယ်။ အဲ့လို concept က software ကောင်းတစ်ခုဖြစ်အောင်ဘယ်လိုဖန်တီးပေးလဲ၊ example လေးကြည့်လိုက်ရအောင်

public class Book {  
    private String name;
    private String author;
    private String text;
    //constructor, getters and setters
 }

ကျွန်တော်တို့ Book class ထဲကို name , author နဲ့ text တွေထည့်ထားတယ်၊ function တွေထပ်ထည့်ကြည့်ရအောင်

public class Book {
     private String name;
     private String author;
     private String text;
     //constructor, getters and setters
     // methods that directly relate to the book properties
     public String replaceWordInText(String word){
         return text.replaceAll(word, text);
     }
      public boolean isWordInText(String word){
         return text.contains(word);
     }
 }

အဲ့လိုဆိုရင် Book class က သေချာအလုပ်လုပ်သွားပါပီ။ Book က Text တွေကိုထပ်ထုပ်လိုက်ကြည့်ရအောင်

public class Book {
     //...
      void printTextToConsole(){
         // our code for formatting and printing the text
     }
 }

အဲ့လိုရေးလိုက်တာကောင်းပေမဲ့ ကျွန်တော်တို့ Single Responsibility Principle ကိုချိုးဖောက်မိသွားပါပီ၊ ဘာလို့လဲဆိုတော့ Book ဆိုတာ စာအုပ်ကစာတွေထုတ်ဖို့တာ၀န်မရှိပါဘူး။ အဲ့တော့ တာ၀န်ရှိတဲ့ BookPrinter လေးထပ်ထည့်လိုက်ရင် Book ကလဲသူ့အလုပ်သူလုပ် BookPrinter ကလဲသူ့အလုပ်သူလုပ်သွားမှာပါ။

public class BookPrinter {
     // methods for outputting text
     void printTextToConsole(String text){
         //our code for formatting and printing the text
     }
      void printTextToAnotherMedium(String text){
         // code for writing to any other location..
     }
 }

The Open-Closed Principle (OCP)

Open-Closed Principle ကတော့ class တစ်ခုက extension တစ်ခုအတွက်ပဲ ဆောက်သင့်တယ် ၊ modification (ပြင်ဖို့) အတွက်မဆောက်သင့်ဘူး ပိတ်ထားသင့်တယ်။ example လေးကြည့်လိုက်ရအောင်…

public class Guitar {
      private String make;
     private String model;
     private int volume;
      //Constructors, getters & setters
}

ကျွန်တော်တို့ Guitar Class လေးဆောက်လိုက်တယ်။ နောက်၅လလောက်ကြာရင် ဒီ class name ကြီးကအဆင်မပြေတော့ဘူး ဒီထပ် modern ဖြစ်တဲ့ metal လျှပ်စစ် Guitar class အဖြစ်ပြောင်းချင်တယ် အဲ့တာဆိုရင်

public class SuperCoolGuitarWithMetal extends Guitar {
      private String flameColor;
      //constructor, getters + setters
}

အဲ့လိုဆိုကျွန်တော်တို့က Guitar Class ကိုပြန်ပြင်စရာမလိုတော့သလို Open-Closed Concept ကိုလိုက်နာပီးသားဖြစ်သွားပါပီ။

The Liskov Substitution Principle (LSP)

Liskov Substitution principle က နည်းနည်းတော့ complex ဖြစ်တယ်။ ဆက်တွေးကြည့်ရအောင်

Ptut Class ရဲ့ daughter က TutTut Class ဖြစ်တယ် အဲ့တော့ TutTut Class က Ptut လုပ်ဆောင်တဲ့ coffee ကိုလုပ်တတ်ရမယ့်အပြင် Espresso တွေပါလုပ်တတ်ရမယ်။

public interface Ptut{
      void MakeCoffee();
 }

ကဲ Ptut ကတော့ coffee လုပ်နေပါပီ လာအားပေးကြဦးနော် xD အဲ့ တော့သူသမီး TutTut က

public class TutTut implements Ptut {
      private Coffee coffee;
      //Constructors, getters + setters
      public void MakeCoffee() {
         //Make Coffee Espresso!
         coffee.makeEspresso();
     }
}

ကဲ အဲ့လိုပဲဖြစ်သင့်ပါတယ်။

The Interface Segregation Principle (ISP)

Interface Segregation principle ကတော့ ကြီးမားတဲ့ interface လေးတွေကို သေးသေးလေးတွေပြန်ခွဲထုတ်တာပါ အဲ့လိုလုပ်ခြင်းအားဖြင့် အရမ်းpurpose တွေများလာတဲ့အခါ သူနဲ့သက်ဆိုင်တာတွေပါ ထပ်မလုပ်ရတော့ပဲ သပ်သပ်စီလုပ်လို့ရသွားပါတယ်။ example လေးကြည့်လိုက်ရအောင်

public interface Ptut {
     void eat();
     void sleep();
     void coding();
 }

ကျွန်တော်တို့simple လေးတွေးကြည့်ရအောင် စားတဲ့နဲ့ အိပ်နေတာနဲ့တစ်ပြိုင်တည်းလုပ်လို့မရပါဘူး အဲ့တာကို class တစ်ခုကခေါ်မယ်ဆိုအကုန်လိုက်လုပ်နေရမှာပါ အဲ့တော့ ကျွန်တော်တို့ပြန်ခွဲလိုက်မယ်

public interface PtutEat {
     void eat();
 }
public interface PtutSleep {
     void sleep();
}
public interface PtutCoding {
     void coding();
 }

ကဲအဲ့လိုခွဲလိုက်တော့ စားတဲ့ နဲ့ coding နဲ့ကတွဲလုပ်လို့ရတော့ ဒီလိုရေးလို့ရသွားတယ်

public class PtutCarrer implements PtutEat, PtutCoding {
      public void eat() {
         //eating Hotpot...
     }
      public void coding() {
         //coding clean architecture...
     }
 }

sleep ဆိုတဲ့ function ကြီးမလိုတော့ဘူးနော်လိုလဲမလိုအပ်ဘူး အဲ့တော့ သပ်သပ်ရပ်ရပ်လေးဖြစ်သွားတာပေါ့

The Dependency Inversion Principle (DIP)

Dependency Inversion Principle ဆိုတာ အရမ်းတာ၀န်များနေတဲ့ module ကို တာ၀န်နည်းနည်းဆီဖြစ်အောင်ပြန်ပြောင်းပေးရတာပါ coding အရ coupling ဖြစ်နေတဲ့ class တွေကို decoupling ဖြစ်အောင်ပြန်လုပ်ပေးရတာပေါ့ အဲ့လိုလုပ်လိုက်ရင် abstractions တွေအပေါ်မှာပဲမူတည်သွားပီး ပြန်ပြင်ရအဆင်ပြေလာပါလိမ့်မယ်။ example လေးကြည့်ရအောင်

public class PcComputer {}

PcComputer ဆိုတဲ့ class တစ်ခု မှာ monitor နဲ့ keyboard မရှိရင်မရပါဘူးအဲ့တော့ ကျွန်တော်တို့ထပ်ထည့်ကြည့်မယ်

public class PcComputer {
     private final GamingKeyboard keyboard;
     private final Monitor monitor;
     public PcComputer() {
         monitor = new Monitor();
         keyboard = new GamingKeyboard();
     }
  }

class ကတော့အဆင်ပြေပြေအလုပ်လုပ်ပါပီ ။ ဒါပေမဲ့ သတိထားမိလားဗျ Keyboard ကို သပ်သပ်သုံးလို့မရဘူး အသေကြီးဖြစ်နေတယ် Pc ပါဆိုမှ ကိုယ်ကြိုက်တဲ့ monitor နဲ့ keyboard တပ်မှာပေါ့ အသေကြီးဆို တစ်ခုလုံးလဲနေရမှာ အဲ့တော့

public interface Keyboard { }public class PcComputer{
      private final Keyboard keyboard;
     private final Monitor monitor;
      public PcComputer(Keyboard keyboard, Monitor monitor) {
         this.keyboard = keyboard;
         this.monitor = monitor;
     }
 }

အဲ့လိုဆောက်လိုက်ပီး GamingKeyboard ကို သပ်သပ်inject ပေးလိုက်မယ်ဆိုရင်

public class GamingKeyboard implements Keyboard { }

အဲ့လိုဆို ရင် ကြိုက်တဲ့ keyboard နဲ့တွဲလို့ရပါပီ

ကျွန်တော်အခု Clean Architecture ထဲမှာပါတဲ့ SOLID Principles အကြောင်းကိုတတ်နိုင်သမျှအကောင်းဆုံးပုံလေးတွေနဲ့တစ်ကွရှင်းပြထားပါတယ်။ နောက်တစ်ခါ Story 3 မှာဘာတွေပါလာမလဲဆိုတော့ မကြာမှီလာမည်မျှော် 😎 😎