이 문서는 가리사니 개발자 포럼에 올렸던 글의 백업 파일입니다. 오래된 문서가 많아 현재 상황과 맞지 않을 수 있습니다.

다음 문서를 참고 하였습니다. https://ko.wikipedia.org/wiki/SOLID

사실 객체지향 프로그래밍에 있어 기본적인 것들인데... 이렇게 5가지 원칙으로 깔끔하게 정리되어 있으니 집고 넘어가 보도록 하겠습니다.

S : 단일 책임 원칙 (Single responsibility principle)

• 모든 클래스는 하나의 책임만 가져야한다.
• 객체가 변경되는 요인도 하나 뿐이여야한다. 사유
• 클래스가 커질 경우 가독성이 떨어진다.
• 의존성이 증가한다.
• 클래스에 사이드 이펙트 관계를 잘 못 알고 고칠 경우 다른 기능까지 피해를 볼 수 있다. 기타
• 하나의 클래스가 여러가지의 일을 해야할 경우.

컴포지트 패턴을 고려해본다. https://ko.wikipedia.org/wiki/%EC%BB%B4%ED%8F%AC%EC%A7%80%ED%8A%B8_%ED%8C%A8%ED%84%B4

O : 개방-폐쇄 원칙 (Open/closed principle)

클래스의 변경은 최소화(Close)하고 확장은 최대화(Open)합니다. 확장가능성을 고려해 자바같은경우 인터페이스나 추상클래스를 이용하여, 내부적인 수정보다는 확장 가능성을 열어두는 방법으로 작성한다.

L : 리스코프 치환 원칙 (Liskov substitution principle)

개방 폐쇄 원칙과 마찬가지로 자바에서는 일반적으로 쓰이고 있는 규칙입니다. (특별한 이유가 없으면 구현체가 아닌 원형을 선언하여 사용하기 때문에...)

List<String> list = new ArrayList<String>();

즉 ArrayList 상위 인터페이스인 List로 업캐스팅 할 경우 완벽한 호환을 보장해야합니다.

I : 인터페이스 분리 원칙 (Interface segregation principle)

인터페이스에 사용하지 않을 규칙들을 분리하는 원칙입니다. 부모 인터페이스는 구현에 있어서 필수인 최소의 추상메서드만 가지고 있어야합니다. 구현에 필요없는 추상메서드가 있다면 이 단위를 더 쪼개거나 설계를 다시 생각해봐야합니다.

D : 의존관계 역전 원칙 (Dependency inversion principle)

오직 하위 객체가 상위 객체에 의존해야합니다. 상위 객체가 하위 객체에 의존해서는 안됩니다. 기초적인 것 이지만 상위 객체가 하위 객체에 의존한다면..... 수정하기도 어려워지고 유지보수도 오류 가능성 확장성 모두를 잃어버리는 걸 포함해... 상위 객체라고 부를수도 없을 것 같습니다...