객체 지향 설계의 원칙 + 전략에 대한 이해

jinhan han·2024년 8월 22일
0
post-thumbnail

보통 좋은 소프트웨어 일수록 모듈의 독립성이 높다고 한다.

독립성이 높다는건? : 응집도(Cohension)는 강할수록, 결합도(Coupling)는 느슨할 수록 독립성이 높은걸 의미한다.

  • 결합도(Coupling)가 높은 클래스의 문제점은 클래스의 규모가 커지기 때문에 이해하기 쉽지 않으며, 특정, 객체의 기능 변화에 따른 다른 요소들에 영향을 주기 때문에, 예측이 어려움.
    결합도가 높다는 건? : 전역 변수라던지 특정, 객체의 기능을 자주 활용하고 의지한다는 말로써, 그 객체가 변한다면 다른 기능에 많은 영향을 줄 수 있다.

  • 응집도(Cohension) 낮은 클래스의 문제점은 코드를 이해하기가 힘들고, 재사용이 힘듦. 또한 유지보수가 매우 쉽지않으며 클래스 변화에 민감함.
    응집도가 높다는 건? : 객체의 기능이 하나의 컨셉으로 명확히 표현되고 다른 객체의 의존을 가능한 하지 않거나 의존을 제공하지 않는 상태에서 한 컨셉 목적의 기능들만을 활용하는 것이다.

따라서 높은 응집도와 낮은 결합도가 이상적인 소프트웨어 모듈이게 된다.

객체지향의 개념과 SOLID 설계 적용

SOLID
SRP (Single Responsibility Principle 단일책임의 원칙)
OCP(Open Closed Principle 개방패쇄의 원칙)
LSP(Liskov Substitution Principle 리스코프 치환의 원칙)
ISP(Interface Segregation Principle 인터페이스 분리의 원칙)
DIP(Dependency Inversion Principle 의존성 역전의 원칙)

SOLID외에 OOP에서 지켜야할 추가적인 규칙 : 의미에 맞는 이름 명칭 사용, 함수안에 매개변수(파라미터) 최소화, 전역적인 형태의 함수 최소화, static 형태의 함수 최소화, 생성자 최소화, 조건문 최소화

SRP (Single Responsibility Principle)

SRP (Single Responsibility Principle 단일책임의 원칙) :
하나의 클래스는 하나의 기능 담당하여 하나의 책임을 수행하는데 집중되도록 클래스를 여러개 설계하라는 원칙

  • 이 개념은 단순한 개념을 기반으로 클래스를 구성하여 결합도를 줄이는 원칙
    Tip : 한 클래스의 개념을 단 한문장으로 표현해야함.
    나쁜 예) 작업을 자동 배분하고, 최단 기간의 작업 결과를 할당한다.
    좋은 예) 작업을 배분한 경우의 수를 활용해 최단 기간의 작업 결과를 할당한다.

최대한 객체를 쪼개라

OCP(Open Closed Principle)

OCP(Open Closed Principle 개방패쇄의 원칙) :
소프트웨어의 구성요소(컴포넌트,클래스,모듈,함수)는 확장에는 열려있고, 변경에는 닫혀있어야 하는 원칙

  • 기존 구성요소는 수정이 일어나지 말아야 하며, 기존 구성요소를 쉽게 확장(예: 상속, 인터페이스 활용)해서 재사용할 수 있어야 한다는 뜻
    클래스가 많아져서 코드관리가 어려워 질 수 있고, 결합도 역시 올라갈 가능성이 존재
    TIP : 확장될 것과 변하지 않을 것을 엄격히 구분하고, 부모 클래스는 추상적이게 함수를 표현 + 인터페이스에 가능한한 의존

다른 객체가 다른 객체를 참조시에는 인터페이스||상위 클래스를 참조하여 객체의 변경/업데이트를 원활히 함

참조

LSP(Liskov Substitution Principle)

LSP(Liskov Substitution Principle 리스코프 치환의 원칙) :
자식 클래스는 부모 클래스에서 가능한 행위를 수행해야 하며, 객제 지향 프로그래밍에서는 부모 클래스의 인스턴스 대신 자식 클래스의 인스턴스를 사용해도 문제가 없다는 것

  • 개발의 유연성과 복잡성의 문제가 생길 수 있지만 유지 보수 및 코드 재사용성이 증가
    TIP : 부모 클래스와 자식 클래스 사이에는 일관된 함수가 존재해야하고, 추가적인 방법으론 공통된 인터페이스를 중심으로 둘이 다른 기능을 만드는 방법으로 구성

하위 클래스는 상위 클래스들의 모든 기능들이 가능해야 함

ISP(Interface Segregation Principle)

ISP(Interface Segregation Principle 인터페이스 분리의 원칙) :
어떤 클래스가 다른 클래스에 종속될 때에는 가능한 최소한의 인터페이스만을 사용해야 함

  • 하나의 일반적인 인터페이스보다는 여러 개의 구체적인 인터페이스가 낫다 라고 정의
    TIP : 인터페이스를 작고 명확하게 분리하고 정의하여 낮은 결합도를 구성

여러 구체적인 하위 인터페이스들을 활용하여, 하위 클래스들의 의존을 가능케함

DIP (Dependency Inversion Principle)

DIP(Dependency Inversion Principle 의존성 역전의 원칙)
이는 의존관계를 맺을 때, 변화하기 쉬운 것보다는 변화하기 어려운 것에 의존해야 한다는 의미이다. 여기서 말하는 변화하기 쉬운 것은 객체지향의 관점에서 보면 구체화 된 클래스를 의미하고, 변화하기 어려운 것이란 추상클래스나 인터페이스를 의미

  • 추상 클래스나 인터페이스에 주로 의존하며 변화하기 어려운 것 거의 변화가 없는 것에 의존
    TIP : 추상화된 클래스나 인터페이스를 설계하며 모듈을 분리하여 결합도를 줄이는게 가능

참조 :
https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4%EC%9D%98-%EA%B2%B0%ED%95%A9%EB%8F%84-%EC%9D%91%EC%A7%91%EB%8F%84-%EC%9D%98%EB%AF%B8%EC%99%80-%EB%8B%A8%EA%B3%84-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EC%89%BD%EA%B2%8C-%EC%A0%95%EB%A6%AC

https://medium.com/@jang.wangsu/%EC%84%A4%EA%B3%84-%EC%9A%A9%EC%96%B4-%EC%9D%91%EC%A7%91%EB%8F%84%EC%99%80-%EA%B2%B0%ED%95%A9%EB%8F%84-b5e2b7b210ff

https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84%EC%9D%98-5%EA%B0%80%EC%A7%80-%EC%9B%90%EC%B9%99-SOLID

https://velog.io/@juhwan9408/%EA%B0%9D%EC%B2%B4-%EC%A7%80%ED%96%A5-%EC%84%A4%EA%B3%84-5%EC%9B%90%EC%B9%99-SOLID

profile
개발자+분석가+BusinessStrategist

0개의 댓글