객체지향 5원칙 (SOLID)

객체지향은 말 그대로 프로그래밍 개발에 있어서 '객체화를 지향하여 진행한다.'라는 의미입니다.

 

Wiki에 기술되어 있는 정의는 아래와 같습니다.

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

(출처: 위키피디아)

 

개발하시는 분들은 이 정도는 다 아실 것이라 생각합니다.

다만, 이 객체지향이라는 것이 어떻게 적용되고 있는지 자세히 알아야 좀 더 이해가 빠르겠죠.

 

 

따라서 객체지향에는 '어떤 것이 객체지향이지?'라는 물음에 대한 답을 알려주기 위한 지표가 존재합니다.

이를 객체지향 5원칙이라고 부릅니다.

(각 원칙의 앞 글자를 따서 'SOLID'라고도 합니다.)

 

Single-responsibility principle (단일 책임 원칙)

A class should only have a single responsibility, that is, only changes to one part of the software's specification should be able to affect the specification of the class.

소프트웨어의 구성 요소(클래스)는 단 하나의 책임만 갖는다. 즉, 하나의 소프트웨어 명세 변경은 단 하나의 소프트웨어 명세에만 영향을 미칠 수 있다.

 

클래스는 하나의 기능만 갖고 그 기능을 수행하는데에만 쓰인다는 이야기입니다. 또한 어떤 클래스가 변경이 된다면 그 이유는 오직 하나(해당 기능에 대한 변경)라는 의미입니다.

결합도는 낮게, 응집도는 높게라는 말을 들어보셨을 텐데, 이를 위한 원리라고 보시면 될 것 같습니다.

이 원리를 잘 적용한다면, 각 클래스의 역할이 확실하게 구분 될 수 있겠죠.

 

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

Software entities ... should be open for extension, but closed for modification.

소프트웨어 구성 요소는 확장에는 개방적이고, 수정에는 폐쇄적이어야한다.

 

좀 더 풀어 써보면, 변경을 위한 비용은 줄이고 확장을 위한 비용은 극대화 해야 한다는 의미입니다.

1. 요구사항의 변경이 발생하더라도, 기존 구성요소의 수정은 발생하면 안된다.
2. 기존 구성 요소를 확장해서 재사용할 수 있어야 한다.

즉, 미리 발생할 변화를 대비해 높은 추상 단계부터 고려해 개발하는 것이 좋은 방법이라 생각하시면 되겠습니다.

 

예시)

요구사항: 자동차 -> 자동차 클래스 생성

요구사항 변경: 비행기 -> 자동차의 구성을 모두 변경해 비행기로 바꿔야함.

해결책

초기 단계에서 탈 것이라는 좀 더 높은 추상화 단계를 설정

요구사항: 자동차

-> 탈 것을 확장해 자동차 생성 진행

요구사항 변경: 비행기

-> 다른 구성은 그대로 둔 채 탈 것을 다시 확장해 비행기 생성

 

조금 어색하지만 단순하게 설명해봤는데, 어떤 느낌인지 와닿으셨으면 좋겠습니다.

 

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

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

서브 타입은 언제나 기존 타입(변경 없이)으로 대체될 수 있어야 한다.

 

부모 클래스와 자식 클래스 사이의 행위에는 일관성이 있어야 한다는 원칙입니다.

즉, 부모 클래스의 정보를 자식 클래스에서 그대로 사용할 수 있어야하고 부모 클래스와 호환이 되어야 한다는 의미입니다.

 

일반적인 상속 관계에서 부모, 자식 클래스 사이의 연관성을 의미하는 내용으로 보입니다.

 

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

Many client-specific interfaces are better than one general-purpose interface.

하나의 범용적인 인터페이스 보다 많은 수의 구체적인 인터페이스가 낫다.

 

한 클래스는 자신에게 필요한 기능을 가진 인터페이스만 구현해야한다라는 의미도 가집니다.

즉, 기능적인 분리를 이야기합니다.

세분화된 다수의 인터페이스에서 딱 필요한 기능만 구현해 구체적인 기능을 갖는 클래스를 구성하자라는 뜻으로 이해하시면 됩니다.

 

Dependency-inversion principle (의존성 역전 원칙)

One should depend upon abstractions, [not] concretions

구체화가 아닌 추상화에 의존해야한다.

 

즉, 의존관계를 맺을 때 변화하기 쉬운 것 보다 변화하기 어려운 것에 의존을 해야한다는 뜻입니다.

위에서 보셨듯이 추상화가 잘되어 있으면, 확장에도 용이하며 큰 변경이 발생하지 않습니다.

 

이러한 의존 관계에서는 위의 원칙들을 유지하며 좋은 소프트웨어를 만들어 낼 수 있겠네요.

 

 

 

이렇게 다섯가지 원칙에 대해 간략히 정리해봤습니다.

대부분 연관이 되어있고 또 비슷한 느낌이라 잘 이해되고 또 기억에 잘 남더라구요.

개발하는 데 있어 완벽하게 지키진 못하더라도 꼭 신경을 쓰셔서 좋은 개발을 하시길 바랍니다.

 

 

내용은 Wikipedia를 참고했습니다.

잘못된 내용이나, 이해가 잘 안되는 부분은 댓글로 알려주시면 늦지않게 답변 드리겠습니다. 감사합니다.