[이론] 객체지향 5가지 원칙 - SOLID

Sehee·2024년 6월 16일

이것저것 모음집

목록 보기
2/9
post-thumbnail

시작하며,

한창 Spring 스터디할 때 정리해둔 내용이다
중요한 내용인데 맨날 봐도 새로우니 미치겠다
iOS 이번 업데이트 내역 같은 건 흘려들어도 잘 기억나면서 이런건 꼭 뒤돌아서면 까먹더라,,,


요약

SOLID란 객체지향 프로그래밍을 하면서 지켜야하는 5대 원칙을 의미한다
각각 SRP, OCP, LSP, DIP, ISP의 앞글자를 따서 만들어졌다.

SRP (Single responsibility principle) | 단일 책임 원칙
모든 클래스는 각각 하나의 기능만 가진다

OCP (Open/closed principle) | 개방 폐쇄 원칙
원본 불변, 활용 용이

LSP (Liskov substitution principle) | 리스코프 치환 원칙
부모 클래스를 상속한 자식 클래스는 부모 클래스의 역할을 정확히 해내야한다 (메소드를 재정의하더라도!)

ISP (Interface segregation principle) | 인터페이스 분리 법칙
인터페이스의 단일 책임 (작은 단위들로 인터페이스 분리)

DIP (Dependency inversion principle) | 의존관계 역전 원칙
클래스 사이의 의존 관계는 존재하되, 최대한 추상화한 클래스에 의존



SOLID

1. 단일 책임 원칙 (Single responsibility principle) : SRP

There should never be more than one reason for a class to change.

💡 모든 클래스는 각각 하나의 기능만 가진다
→ 해당 클래스가 제공하는 모든 서비스는 단 하나의 책임을 수행하는 데 집중되어야 한다는 원칙

  • SRP 원칙을 적용하면 다른 클래스들이 서로 영향을 미치는 연쇄작용을 줄일 수 있음
  • 응집도 (cohesion) ⬆️ && 결합도 (coupling) ⬇️
  • 책임을 적절하게 분배 ⇒ 코드의 가독성 향상, 유지보수 용이
  • 다른 원칙들을 적용하는 기초가 됨

2. 개방 폐쇄 원칙 (Open/closed principle) : OCP

You should be able to extend a classes behavior, without modifying it.

💡 소프트웨어의 모든 구성요소(클래스, 모듈, 함수)는 확장에는 열려있고, 변경에는 닫혀있어야한다는 원칙

  • 기존 구성요소는 수정이 일어나지 말아야하며 쉽게 확장이 가능하여 재사용할 수 있어야 함 (원본 불변, 활용 용이)
  • OCP는 관리가 용이하고 재사용 가능한 코드를 만드는 기반
  • OCP를 가능하게 하는 중요한 메커니즘 : 추상화, 다형성
  • 클래스를 설계할 때 변할 부분과 변하지 않을 부분을 명확히 구분 해야 함
    • 변할 수 있는 부분 : 추상화하여 상속하는 클래스가 의존할 수 있도록 작성
    • 변하지 않을 부분 : interface로 작성

3. 리스코프 치환 원칙 (Liskov substitution principle) : LSP

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

💡 부모 클래스를 가리키는 포인터에 해당 클래스를 상속하는 자식 클래스를 할당하더라도 모든 기능이 정상적으로 작동해야 하며 자식 클래스의 상세 내부를 부모 클래스는 알 필요가 없다는 원칙

  • 부모 클래스를 상속한 자식 클래스는 부모 클래스의 역할을 정확히 해내야함
  • LSP를 지키는 가장 간단한 방법은 상속을 하되 override를 안하는 것 (무조건적인 방법 X)
  • 상속할 때 override가 필요하다면 기존 부모 클래스의 메소드가 하던 역할을 충실히 수행하고 기능의 추가만 신중하게 수행하면 됨
  • 상속의 과정 중 메소드의 재정의가 필요하다면 자식 클래스가 부모 클래스의 기존 메소드의 의미를 해치지는 않는지 고민하고 올바르게 상속하라는 의미

4. 인터페이스 분리 원칙 (Interface segregation principle) : ISP

Clients should not be forced to depend upon interfaces that they do not use.

💡 자신이 사용하지 않는 인터페이스는 구현하지 말아야 한다는 원칙
→ 하나의 큰 인터페이스를 상속 받기 보다는 인터페이스를 구체적이고 작은 단위들로 분리시켜 꼭 필요한 인터페이스만 상속하자는 의미

  • SRP가 클래스의 단일책임을 강조했다면 ISP는 인터페이스의 단일책임을 강조
  • 인터페이스 하나의 크기가 크다는 건 한번에 지켜야할 약속이 많아진다는 것을 의미

5. 의존관계 역전 원칙 (Dependency inversion principle) : DIP

A. high level modules should not defend upon low level modules. Both should depend upon abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.

'상위 모듈은 하위 모듈에 의존해서는 안된다. 둘다 추상화에 의존해야 한다.'
'추상화는 구체적인 것에 의존해서는 안된다. 구체적인 것은 추상화에 의존해야 한다.'

  • 클래스 사이의 의존 관계는 존재하되, 구체적인 클래스에 의존하지 말고 최대한 추상화한 클래스에 의존하라는 의미
    → interface를 적극적으로 활용하라는 의미
사용자 --의존-> 아이폰(class)

==> 변화

사용자 --의존-> 스마트폰(interface)
				- 아이폰(class)
				- 갤럭시(class)
				- LG (class)


마치며,

대표적인 객체지향 언어로는 C++, JAVA가 있다

Swift는 함수형 프로그래밍이라고들 하지만, 함수형 프로그래밍과 객제지향 프로그래밍을 모두 지원하는 멀티 패러다임 언어이다
프로토콜 프로그래밍도 지원한다던데,,,
콘텐츠 하나 얻었다 조만간 공부해서 기록해야겠다

profile
디자인하는 개발자

0개의 댓글