책 토비의 스프링 3.1의 1장 오브젝트와 의존관계를 정리한 내용입니다.

Index

• 객체 지향 설계 원칙 (SOLID)
  • 개방 폐쇄 원칙
  • 높은 응집도와 낮은 결합도
• OOP
• References

객체 지향 설계 원칙(SOLID)

객체지향의 특징을 잘 살릴 수 있는 설계의 특징을 말한다.

오랜 시간 동안 많은 학자와 개발자 사이에서 공감대가 형성된, 객체지향 설계에 관한 여러가지 원리와 원칙을 체계적으로 정리하고 이름과 약자를 만들어 공개한 것이 바로 SOLID이다.

SOLID는 아래 5가지 원칙의 첫 글자를 따서 만든 단어이다.

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

   클래스는 단 한 개의 책임을 가져야 한다.

   이를 지키지 않으면, 한 책임의 변경에 의해 다른 책임과 관련된 코드에 영향이 갈 수 있다.

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

   확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.

   기능을 변경하거나 확장할 수 있으면서, 그 기능을 사용하는 코드는 수정하지 않는다.

   이를 지키지 않으면, instanceof와 같은 연산자를 사용하거나 다운 캐스팅이 일어난다.

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

   상위 타입의 객체를 하위 타입의 객체로 치환해도, 상위 타입을 사용하는 프로그램은 정상적으로 동작해야 한다.

   상속 관계가 아닌 클래스들을 상속 관계로 설정하면, 이 원칙이 위배된다.

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

   인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

   각 클라이언트가 필요로 하는 인터페이스들을 분리함으로써, 각 클라이언트가 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 만들어야 한다.

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

   고수준 모듈은 저수준 모듈의 구현에 의존해서는 안된다.

   저수준 모듈이 고수준 모듈에서 정의한 추상 타입에 의존해야 한다.

   즉, 저수준 모듈이 변경돼도 고수준 모듈은 변경할 필요가 없는 것이다.

디자인 패턴 vs 객체지향 설계 원칙

• 디자인 패턴: 특별한 상황에서 발생하는 문제에 대한 좀 더 구체적인 솔루션

• 객체지향 설계 원칙: 좀 더 일반적인 상황에서 적용 가능한 설계 기준. 예외는 있겠지만 대부분의 대부분의 상황에 잘 들어맞는 ‘가이드라인’ 같은 것

개방 폐쇄 원칙

지금까지 우리는 인터페이스를 사용해 확장 기능을 정의하여, 개방 폐쇄 원칙을 지키는 객체 지향 설계를 해보았다.

이 원칙에 의해 기존에 사용하고 있던 DB 연결 방법이 변경될지라도 UserDao는 DB연결이라는 기능의 확장에 열려있으며 그 동시에 자신의 코드는 수정하지 않아도 확장이 가능하므로 변경에는 닫혀 있게된다.

=> repository를 인터페이스로 분리시켜 구현하는 것도 결국 이 개방 폐쇄 원칙을 따라, 다른 repository로 변경하거나 사용하던 repository에 변경이 생겼을 때, 해당 repository를 사용하고 있는 코드들의 수정 없이 해당 repository 한 곳의 코드만 수정하면 되는. 확장에 열려있고 변경에는 닫혀있는 구조로 만드는 것이다.

높은 응집도와 낮은 결합도

응집도를 높이고 결합도를 줄여야 요구사항 변경에 유연하게 대처할 수 있는 좋은 설계 방법이다.

• 높은 응집도

  • 하나의 모듈이나 클래스가 하나의 책임 또는 관심사에 집중되어 있다.

• 낮은 결합도(Coupling)

  • 책임과 관심사가 다른 오브젝트나 모듈은 느슨하게 연결되어 있다.

• 전략 패턴

  • 변경이 필요한 기능을 인터페이스 통해 통째로 외부로 분리시키고, 이를 구현한 구체적인 알고리즘 클래스를 필요에 따라 바꿔서 사용할 수 있게 하는 디자인 패턴

  • 여기서 알고리즘이란, 독립적인 책임으로 분리가 가능한 기능을 뜻하며 이를 대체 가능한 전략이라 보기 때문에 전략 패턴.

  • DB 연결방식(ConnectionMaker) - 알고리즘

이를 통해 저자는 스프링에 대해 다음처럼 언급한다.

스프링이란, 객체지향적 설계 원칙과 디자인 패턴에 나타난 장점을 자연스럽게 개발자들이 활용할 수 있게 해주는 프레임워크라고.

OOP(Object Oriented Programming, 객체지향프로그래밍)

객체지향 프로그래밍이란, 컴퓨터 프로그래밍 패러다임 중 하나로, 컴퓨터 프로그램을 명령어의 목록으로 바라보는 시각에서 벗어나 여러개의 독립된 단위 즉 객체들의 모임으로 파악하고자 하는 것이다. 각 객체는 메시지를 주고 받고, 데이터를 처리할 수 있다.

패러다임(paradigm)
어떤 한 시대 사람들의 견해나 사고, 관점을 근본적으로 규정하는 테두리로서의 인식의 체계, 또는 사물에 대한 이론적인 틀이나 체계를 의미하는 개념

객체지향의 특징으로 추상화, 캡슐화, 상속, 다형성이 있다.

추상화(Abstraction)

공통적인 성격이나 기능을 따로 뽑아서 분리시켜놓는 것

캡슐화(Encapsulation)

객체가 내부적으로 기능을 어떻게 구현하는지 감추는 것
캡슐화를 통해 모듈간의 결합도를 낮추어 한 곳에서 변화가 일어나도 다른 곳에 미치는 영향을 최소화 시킨다. 캡슐화는 정보 은닉을 활용하면 된다. 예를 들어 private으로 외부에서 접근하지 못하도록 하는 것이다.

상속(Inheritance)

기존에 있던 클래스를 바탕으로 기능을 확장해서 새로운 클래스를 만드는 것.

다형성(Polymorphism)

하나의 타입으로 여러 타입을 참조할 수 있도록 하는 것.

References

토비의 스프링 3.1
https://gyoogle.dev/blog/computer-science/software-engineering/Object-Oriented%20Programming.html