SOLID 원칙

SOLID 원칙

객체지향에서의 5개의 원칙을 나타냄 소프트웨어 설계와 아키텍처의 품질을 향상시키는 데 도움이 되고, 유지보수가 쉽고, 확장 가능한 시스템을 위한 지침을 제공

1.Single Responsibility Principle(SRP,단일 책임원칙)

• 클래스는 하나의 책임만 가져야하는 원칙
• 한 클래스가 너무 많은 일을 하려고 하면, 클래스는 수정이 필요한 경우가 많아지고, 여러 이유로 변경될 가능성이 커진다.

//하나의 클래스에 하나의 책임
class User {
  constructor(name, age){
  this.name = name;
  this.age = age;
  }
  
  //사용자의 정보
  getUserInfo() {
    return `${this.name}, ${this.age}`;
  }
}

//좋지 않은 예시!
class UserAndOrder{

	//사용자 정보 메서드  
   //주문 정보 메서드
}

2. Open/Closed Principle (OCP, 개방-폐쇄 원칙)

• 소프트웨어 구성요소(클래스, 모듈, 함수 등)는 열려 있어야 하지만, 수정에는 닫혀있어야한다. 기존 코드를 변경하지 않고 시스템의 행동을 확장할 수 있어야한다.

class Shape {
	area() {
    	throw new Error("이 메서드는 오버라이딩 되어야합니다.");
    }
	
}

//좋은 예시 - 확장
class Square extends Shape{
	constructor(length){
    
    super();
      this.length = length;
    }
  
  area(){
  	return Math.pow(this.length,2);
  }
}

//상속 X - 나쁜 예제
class Circle {
	constructor(rad){
    	this.radius =rad;
    }
  
  area(){
  	return Math.PI * Math.pos(this.radius,2);
  }
}

3. Liskov Substitution Principle(LSP, 리스코프 치환원칙)

• 하위 타입은 그것의 상위 타입으로 대체될 수 있어야 한다.
• 이 원칙이 지켜지지 않으면, 상위 타입과 하위 타입이 대체될 수 없기 때문에 상속의 사용이 무의미해진다.

class Bird {
	fly(){
    	//날기
    }
}

class Sparrow extends Bird{
	fly(){
    	//참새가 난다. 
    }
	
}

4. Interface Segregation Principle(ISP, 인터페이스 분리 원칙)

• 클라이언트는 자신이 사용하지 않는 메서드에 의존하지 말아야한다.
• 하나의 종합 인터페이스보다는 여러 개의 특화된 인터페이스가 더 낫다.

interface IInterface1 {
	//언터페이스1
}

interface IInterfcae2 {
	//인터페이스2
}

5. Dependency Inversion Principle(DIP, 의존 역전의 원칙)

• 상위 수준의 모듈은 하위 수준의 모듈에 의존해서는 안된다.
• 둘 다 추상화에 의존
• 이 원칙은 의존성 주입과 같은 패턴에 의해 구현됨

	//좋은예시
	class Database{
    	constructor(pool){
        	this.pool = pool;
        }
      
      save(data){
        	this.pool.save(data);
      }
      
      
    }

	class MongoDB{
    	save(data){
        	//실행
        }
    }


	//나쁜예시
	class Database{
    	save(data){
        	//바로 mongoDB 연결
        }
    }

---

REFERENCE

• 모던 자바스크립트 딥다이브
• ko.javascript.info