티스토리 뷰
1부: https://lsu0503.tistory.com/76
Today I Learned - Day 22 [객체, 그 개념에 관하여 - 1]
오늘날 프로그래밍 언어는 절차적 언어와 객체 지향 언어로 나뉘어 있다.[유니티에서 '정보 지향'이라는 새로운 개념을 꺼내어 들기는 했으나, 사실상 유니티의 단점을 우회하기 위한 것이라서
lsu0503.tistory.com
2부: https://lsu0503.tistory.com/77
Today I Learned - Day 23 [객체, 그 개념에 관하여 - 2]
어제는 객체지향의 발안 배경과 Heap과 Stack을 통한 개념 정리를 작성하였다.그렇다면 이제 객체지향에 대해서 조금 더 세밀하게 퍄고들어 보자. 목차서두프로그래밍 언어의 발전사 - 객체지향
lsu0503.tistory.com
이제 까지, 객체 지향의 개념과 배경, 이점에 대해서 알아보았다.
하지만, 객체지향 언어를 쓴다고 해도 그 사용법을 지키지 않고 쓴다고 해서 이 장점들이 모두 발휘되지는 않을 터다.
그렇다면 이러한 '사용법'은 무엇일까.
한번 정리해 보자.
목차
- 서두
- 프로그래밍 언어의 발전사 - 객체지향은 왜 발안되었는가.
- Class와 Instance, Object의 정의
- 객체지향의 4요소
- 캡슐화
- 추상화
- 상속
- 다형성
- 솔리드 원칙 ※
- 단일 책임 원칙
- 개방 폐쇄 원칙
- 리스코프 치환 원칙
- 인터페이스 분리 원칙
- 의존 역전 원칙
솔리드(SOLID) 원칙은 각 세부 원칙의 첫 알파벳을 따와서 이름 붙인 것으로, '객체 지향을 만들기 위한 지침'에 해당한다.
그렇다면, 각 항목 별로 정리 해 보자.
단일 책임 원칙(Single Responsibility Principle)
작성된 각 클래스는 각기 하나의 기능 만 가지며, 동시에 해당 기능에 대해서는 해당 클래스 혼자서 온전히 책임져야 한다는 법칙이다.
간단하게 말하면 하나의 기능은 하나의 클래스로, 하나의 클래스는 하나의 기능만을 가지도록 구성해야 한다는 법칙으로, 관련객체지향의 4요소 중 캡슐화와 관계 높은 법칙이다.
당연하지만 코드의 가독성이나 독립성에 매우 중요한 법칙이면서 동시에 '기능을 어떤 기준으로 분리하여야 하는가'에 대한 고민을 자아내게 하는 법칙이기도 하다.
또한, 후술할 법칙들의 근간이 되는 요소이기도 하기 때문에 최우선으로 고려해야 하는 법칙.
[최우선이라고는 하지만, 가장 무너지기 쉬운 법칙이기도 하다. 유의하도록 하자.]
개방 폐쇠 원칙(Open Close Principle)
소프트웨어의 구성요소는 확장에는 열려있고 변경에는 닫혀있어야 한다는 원리.
다소 이해하기 난감한 서술이긴 하나, 풀어서 적으면 프로젝트에 변경이 일어나도 각 기능이 유지된다면 그 구성요소는 변화하지 않아야 한다는 법칙 하나와 프로젝트를 변경하는 데에 각 기능의 구성요소가 걸림돌이 되어서는 안된다는 법칙을 한 번에 정리한 것이라고 봐도 무방하다.
즉, 전체적으로 호환성을 유연하게 구성해야 한다는 법칙. 제너릭과 델리게이트와 관계가 깊은 법칙이기도 하다.
리스코프 치환 법칙(the Liskov Substitution Principle)
서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다는 법칙.
간단하게 설명하면 자식 클래스를 부모 클래스와 같은 방법으로 사용할 수 있어야 한다는 법칙이다.
조금 더 풀어서 쓰면 '전혀 다른 클래스를 부모 자식 관계로 역지 말고, 상관 없는 요소를 인터페이스로 묶지 말라'는 법칙.
즉, 상속 관계에 있어서 일관성을 지켜라는 법칙이라고 보면 좋다.
인터페이스 분리 원칙(Interface Segregation Principle)
각 클래스가 사용하지 않는 인터페이스, 즉 미사용 요소가 존재해서는 안된다는 법칙.
관련 요소를 하나로 뭉뚱그려서 작성하기 보다는 인터페이스나 부모 클래스로 공통점을 정의하고, 그 공통점을 상속받은 자식 클래스로 차이점을 정의하는 것이 좋다는 법칙.
인터페이스를 상세하게 나누어서 작성해야 한다고 서술된 경우가 많은데, 정확하게는 '갑자기 특정 요소를 상속받는 객체를 추가된다고 해도 안쓰는 요소가 있지 않도록 구성할 수 있도록' 상세하게 나눈다는 것이다.
구상 단계에서 부터 확장성을 고려하라는 법칙이기 때문에 무너지기는 가장 어렵지만 구성하기도 가장 난해한 법칙.
의존 역전 원칙(Dependency Inversion Principle)
하위 레벨 모듈의 변경이 상위 레벨 모듈의 변경을 요구해서는 안된다는 법칙.
[기존에 존재했던 구조적 문제를 역전시켰기에 의존 '역전' 원칙이라 부른다.]
5개 원칙 중에서 가장 이해하기가 난해한 원칙인데, 간단하게 말하면 '의존관계에 변화가 전파되어선 안된다'라고 볼 수 있다. 때문에 추상화를 적극 사용하거나, 공유 데이터를 담아두는 별개 클래스를 작성한다던지 하는 방법을 추천하는 것을 많이 볼 수 있다.
이로서 객체지향에서 중점적으로 다뤄지는 개념들에 대해서 둘러보았다.
사실 간략하게 설명한 것이라서 구체적인 예시나 방법이 묘사되지는 않았지만, 그래도 최대한 이해하기 쉽게끔 정리해서 작성했다고 생각한다.
앞으로 객체 지향 프로그래밍을 구사하는 데에 조금이라도 보탬이 되기를 바라며, 이만, 글을 마치겠다.
'스파르타 내일배움캠프 > Today I Learned' 카테고리의 다른 글
Today I Learned - Day 26 [AddComponent] (0) | 2024.10.21 |
---|---|
Today I Learned - Day 25 [New Input System] (0) | 2024.10.18 |
Today I Learned - Day 23 [객체, 그 개념에 관하여 - 2] (1) | 2024.10.16 |
Today I Learned - Day 22 [객체, 그 개념에 관하여 - 1] (1) | 2024.10.15 |
Today I Learned - Day 21 [메모리 구조에 대하여] (0) | 2024.10.14 |