객체지향 5대 설계원칙

1. OCP(Open-Closed Principle) 개방-폐쇄원칙

모듈 구현은 확장에는 개방되어있어야 하지만, 변경에는 폐쇄되어 있어야 한다.

이미 구현 해 놓은 로직에서 새로운 모듈 추가에는 유용하게 되어야 하지만 추가 한다고 해서, 구현된 코드가 변경 되면 안된다.

이를 지원하기 위해서, 추상메소드, 인터페이스가 존재함.

JAVA 개발시 유의할 점. (해당 모듈 개발 시, 같은 기능의 다른 모듈 을 붙일 수 있는가? 그렇게 만들 수 있는가? 생각하고 반드시 추상메소드, 및 인터페이스를 활용하여 작성해 볼 것.)

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

기반이 되는 부모클래스를 참조하는 다른 클래스들의 경우 부모 클래스의 자식 클래스를 알아야 할 필요를 느끼면 안된다.

이거는 대체적으로, 부모클래스 메소드 오버라이딩 할 때 발생하는 문제 같다. 아무래도 부모클래스에서 결과적으로 보여주는 메소드 자체를, 내부적으로는 변경 할 수 있으나 메소드의 기능 자체를 바꾸면 안된다는 것 같다. 그래야 부모클래스를 참조하더라도, 자식메소드를 볼 필요가 없어지니깐.

3. DIP (Dependency Inversion Principle) 의존관계 역전 원칙

상위모듈 또는 추상화 클래스가, 하위모듈이나 구체화 클래스를 의존하면 안된다.

이는 당연한 듯 보이나. 잘 생각해보면, 인터페이스나 추상화메소드를 더 구체적으로 사용하는데 있어서 어느정도 생각이 필요한 구조를 짜야함을 보여준다.

일례로 내가 이번에 만든 웹 탐색기에서 클라이언트의 구조는

TCP메세지 응답클래스, 파일시스템 접근 클래스, 파일객체 파서. 이렇게 3개로 구분된다.근데 만약, JSON파서가 바뀌어서 JSON형식 말고 다른 메세지 형식으로 변경해야한다 싶을 때는, 메세지 응답 클래스도 같이 변경해줘야 하는 경우가 있다.

위와같이. 하위 모듈을 바로 사용하게되면, 상위클래스가 하위클래스를 의존하게된다.

그래서 이를 해결하기위해, 상위클래스는 하위클래스의 인터페이스, 또는 추상메서드를 참조하고, 하부클래스는 해당 추상화를 실체화하여 구현하는 방식으로 하게 된다.

끝!

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

인터페이스에 메소드들은 필요한 메소드 들을 잘 나눠서 구분하도록 한다.

예를들어 범위를 잘못 지정해 구체화하는 클래스들이 필요 없는 메소드 까지 오버라이딩 하게되는 일들이 없도록 한다.

결국. 잘 구분해서 잘 만들어서 잘 나누라는 것. 보통, 구체화된 여러 인터페이스를 다중상속하는게 맞는거라는 얘기들도 있지만 너무 심하면 힘드니 잘 생각하기.

5. SRP (Single Responsebility Principle) 단일 책임 원칙

클래스를 구분 지을 때는 한번에 한가지 책임을 지도록 만들어야 한다.

위의 ISP의 클래스 버전이라 할 수 있겠다.

하나의 클래스가 할 일을 철저히 잘 구분 하라는 것,! 클래스의 덩치가 점점 커지고, 여러가지 일을 하게되다보면 가독성 및 유지보수가 어려워지게 된다. 그렇다고 클래스를 너무 나누면 오히려 복잡해질 수도 있다.

결과적으로 이것도 경험에의해 느는것인데, 잘! 나누라는 것!.