SOLID 원칙

Bam·2024년 9월 24일

CS

목록 보기

28/28

사실 오래 전(벌써 2년도 더 전에)에 디자인 패턴에서 소개드린 내용인데요. 포스트 분리도 하고 리마인드도 할 겸 다시 작성했습니다.

SOLID 원칙은 클린 코드로 유명한 로버트 C. 마틴이 정립한 객체지향 프로그래밍을 하면서 지켜야한다고 세운 다섯가지 원칙을 말합니다. 총 5개의 원칙으로 이루어져있으며 각 원칙의 머릿글자를 따서 SOLID라는 이름이 붙게 되었습니다.

서론에서 이야기한 디자인 패턴과 아주 밀접한 관계가 있는데요. 디자인 패턴들이 SOLID 원칙에 따라서 만들어진 패턴들이기 때문에 오래전에 디자인 패턴을 소개드리면서 함께 소개드렸던 기억이 납니다.

하나의 클래스는 단 하나의 책임만을 갖는다.

'책임'은 기능이라고 생각하시면 됩니다. 다시말해 하나의 클래스는 하나의 기능만을 하도록 설계하는 것이 좋다라는 것을 의미합니다.
하나의 클래스가 여러 기능을 가지게 되는 경우 하나의 유지보수가 어려워진다.

기능이 여럿일 경우 한 가지 변경이 다른 여러 기능 관련 클래스에도 영향을 주게 됩니다.

소프트웨어(함수, 클래스, 모듈 등)은 확장에 대해서는 열려있어야하나 변경에 대해서는 닫혀있어야한다.
기능을 추가하거나 변경할 때 원래의 코드를 변경하지 않고 코드의 추가를 통해서 이루어지도록 해야한다.

인터페이스를 직접 변경하기 보단 구현 클래스를 통해 기능을 추가하도록 합니다. (다형성 활용)

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

자식 클래스들은 부모 클래스의 모든 기능들을 수행할 수 있도록 해야합니다.

예를 들어 카운터에서 버튼을 누르면 1씩 늘어나는 버튼이 자식 클래스에서 1이 줄어들도록 하면 안된다라는 이야기. 2씩 늘던지, 3씩 늘던지 아무튼 늘어나도록 설계해서 동일한 동작(=어쨌든 동일하게 늘어남)을 보장.
상속 관계를 제대로 확인하고 상속 관계를 맺어야한다.

하나의 큰 인터페이스보다 작은 인터페이스 여러 개가 낫다.

탈 것 인터페이스로 뭉뚱 그린 범용 인터페이스보다 비행기 인터페이스, 배 인터페이스, 이륜차 인터페이스, 자동차 인터페이스 등으로 작게 나누는게 훨씬 좋습니다.
한 인터페이스에 여러 기능을 넣기보다 기능별로 작은 인터페이스들로 나누어 적재적소에 맞는 메소드들만을 사용하도록 한다.

인터페이스가 명확해지는 동시에 대체가 쉬워집니다.