• SRP: 단일 책임 원칙 (캡슐화 관련) : 한 클래스는 단일한 책임만 가져야한다. (단일한 책임만 있어야 외부에서 명령을 내려서 결과를 리턴받을 수 있다. 그때 단일한 책임을 가져야 내가 문자열 클래스에다 명령을 내리는지. 캐릭터 클래스에 명령을 내리는지. 외부 입장에서는 그게 딱 구분이 되는 것이다.
  • 클래스는 하나의 기능만 가여야 하며, 클래스는 변경하려는 단 하나 이유만을 가져야 한다.
  • 하나의 기능만 담당하는 클래스는 변경시 벌어지는 연쇄작용에서 자유로워짐
  • 가독성이 향상되고 유지보수가 용이
• OCP: 개방, 폐쇄 원칙 (컴포넌트 원칙) : 클래스는 외부에서 임의로 수정하면 안된다. (다른 팀에서 임의로 수정하면 안되는 것) 해당 값을 다른 클래스에서도 임의로 수정하면 안된다. 그래서 이것을 수정하는 것은 닫혀 있고, 다만 추가 하는 것은 열려 있는 것 (컴포넌트 자체는 외부에서 건드릴 수 없는데. 컴포넌트 안에 추가 해줄 순 있다)
  • 원래 담당하기로 했던 기능에서 다른 기능으로 변경을 줄여야 한다.
  • 가지고 있던 기능의 확장은 적극 권장된다
  • 변경사항이 발생할 경우 가능한 원래 있던 요소들의 변경 없이 확장으로 변경사항을 반영한다
  • 객체지향의 추상화와 다형성을 활용한다.
• LSP: 리스코프 치환 원칙 (상속구조- 부모의 기능을 자식한테 주고 부모를 떼어냈을 때 그 자식들이 실행 될 수 있는 가) 상속구조를 제대로 설계 했다면. 부모가 없어도 부모를 밑으로 내려도 정확히 실행이 되어야 한다.
  • 서브 타입은 기반 타입이 약속한 규약(접근제한자, 예외 포함)을 지켜야 한다.
  • 클래스 상속, 인터페이스 상속을 이용해 확장성을 획득한다.
  • 다형성과 확장성을 극대화하기 위해 인터페이스를 사용하는 것이 더 좋다
  • 합성(composition)을 이용할 수도 있다
• ISP: 인터페이스 분리 원칙
  • 가능한 최소한으로 인터페이스를 구축
  • 클래스를 이용하는 많은 클라이언트가 클래스의 특정 부분만 이용한다면 한개의 인터페이스를 사용하는 부분만 활용하도록 여러개의 인터페이스로 분류해 클라이언트가 필요해하는 기능만 전달한다.
  • SRP가 클래스의 단일 책임이라면, ISP는 인터페이스의 단일 책임
• DIP: 의존성 역전 원칙 (커플링 관련?)
  • 하위 모델의 변경이 상위 모듈의 변경을 요구하는 위계관계를 끊는다.
  • 실제 사용관계는 그대로지만, 추상화를 매개로 메세지를 주고 받으면서 관계를 느슨하게 만든다