일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |
- 너비우선탐색
- 자료구조
- 컴공
- 알고리즘
- OS
- DP
- 북리뷰
- 정석
- 컴퓨터공학과
- 개발
- cs
- Computer science
- 컴공과
- bfs
- 백준
- 정석학술정보관
- 그래프
- Operating System
- 브루트포스
- 코테
- vector
- 오에스
- c++
- coding
- Stack
- 스택
- 구현
- 코딩
- 오퍼레이팅시스템
- 문제풀이
- Today
- Total
Little Jay
객체 지향의 원칙들(SOLID) 본문
객체 지향의 원칙들
- 단일 책임 원칙 (Single Responsibility Principle)
- 개방 폐쇄 원칙 (Open-closed Principle)
- 리스코프 치환 원칙 (Liskov Substitution Principle)
- 인터페이스 분리 원칙 (Interface Segregation Principle)
- 의존 관계 역전 원칙 (Dependency Inversion Principle)
Single Responsibility Principle
모든 클래스는 단 한가지의 책임만을 갖고
클래스 안에 정의되어 있는 모든 기능은
이 하나의 책임을 수행하는데에 집중되어야 한다
즉,하나의 클래스로 너무 많은 일을 하지 말고 한 가지의 책임만 수행하라는 뜻이다.
Open/Closed Principle
클래스는 확장에는 열려있어야 하며, 수정에는 닫혀 있어야한다.
확장이 열려있다는 것은 기존 프로그램의 기존 가능을 확장할 수 있다는 것이고,
수정에 닫혀있다는 것은 한 번 작성한 코드를 바꾸지 않아도 된다는 뜻이다.
결국 이는 추상 클래스를 상속시킴으로서 해결 할 수 있다
추상 클래스로 함수들을 오버라이딩 시키면 된다
물론 isInstance 메소드를 사용해도 되지만
협업하는 개발의 관점에서 볼 때 추상클래스를 활용하면 개발 및 유지, 보수에 편하다
Liskov Substitution Principle
부모 클래스의 인스턴스를 사용하는 위치에
자식 클래스 인스턴스를 대신 사용했을 때
코드가 원래의 의도대로 작동해야 한다
즉, 부모클래스의 행동 규약을 자식 클래스가 위반하면 안된다
대표적인 예로 자식 클래스가 부모 클래스의 함수를 오버라이딩 하는 경우 인데,
이때, 자식 클래스가 부모 클래스의 변수의 타입을 바꾸거나, 메소드의 파라미터, 혹은 리턴값, 갯수를 바꾸는 경우와 자식 클래스가 부모 클래스의 의도와 다르게 메소드를 오버라이딩 하는 경우이다.
Interface Segregation Principle
인터페이스: 추상 클래스에서 추상 메소드들만 있고 일반 메소드는 없는 것
클래스가 사용하지 않을 메소드에 의존할 것을 강요하면 안된다
즉, 클래스가 나중에 사용하지도 않을 메소드를 가지도록 강제하면 안된다는 것이다.
(추상클래스를 상속받으면 자식 클래스들은 추상 메소드를 반드시 오버라이딩 해야한다)
이 원칙은 지나치게 많은 추상 메소드를 가진 거대한 인터페이스 하나(뚱뚱한 인터페이스)를, 관련된 추상 메소드들만 모여있도록 작은 크기의 인터페이스로 분리하라는 뜻이다. 이렇게 해야 하는 이유는 지나치게 큰 인터페이스는 그걸 상속하는 클래스가 자신에게 필요하지도 않은 메소드를 굳이 오버라이딩하도록 만들기 때문이다.
인터페이스가 서로 관련성이 높은, 적절한 개수의 추상 메소드들을 포함하게 될 때 그걸 역할 인터페이스(role interface)라고 하게 된다. 큰 인터페이스 하나가 있는 것보다는 작은 역할 인터페이스 여러 개가 있으면 각 클래스가 본인에 해당하는 인터페이스만 적절히 상속받게 할 수 있다. 그럼 각 클래스가 어떤 기능을 갖는지 더 세밀하게 파악할 수 있게 해준다는 장점이 있다. 인터페이스를 분리할 때 어떤 기준으로 나눌지는 상황에 따라 당연히 것이지만, 중요한 것은 관련있는 기능끼리 한 인터페이스에 모으고 한 인터페이스가 지나치게 커지지 않도록 하겠다는 생각을 갖고 인터페이스를 설계하는 것이다.
Dependency Inversion Principle
"상위 모듈은 하위 모듈의 구현 내용에 의존하면 안 된다. 상위 모듈과 하위 모듈 모두 추상화된 내용에 의존해야 한다."
여기서 상위 모듈이란 다른 클래스를 사용하는 주된 클래스, 하위 모듈은 사용되는 클래스를 나타낸다. 상위 모듈은 보통 프로그램의 메인 흐름에 좀더 가깝고 하위 모듈은 상대적으로 좀더 멀리 있는 것.
의존 관계 역전 원칙은 상위 모듈이 하위 모듈을 사용할 때 직접 인스턴스를 가져다가 쓰지 말라는 뜻이다.
왜냐하면 인스턴스를 바로 가져다가 쓴다는 말은 하위 모듈의 구체적인 내용에 상위 모듈이 의존하게 되어 하위 모듈에 변화가 있을 때마다 상위 모듈의 코드를 자주 바꿔줘야 하기 때문이다. 이에 대한 해결책은 추상 클래스로 상위 모듈과 하위 모듈 사이에 추상화 레이어를 만드는 것이다. 이렇게 되면
- 상위 모듈에는 추상 클래스의 자식 클래스의 인스턴스를 사용한다는 가정 하에 그 하위 모듈을 사용하는 코드를 작성해두면 되고,
- 하위 모듈은 추상 클래스의 추상 메소드들을 구현(오버라이딩)만 하면 된다.
그럼 상위 모듈은 새로운 하위 모듈이 생겨도 기존 코드를 수정하지 않고 새 하위 모듈을 자유롭게 가져다 쓸 수 있게 된다. 그만큼 코드를 유지보수하기 편해진다.
'Univ > Study' 카테고리의 다른 글
[Study] 코드 표절검사 by Stanford Moss (0) | 2022.05.18 |
---|---|
[OS] pthread.h 실행 명령어 (0) | 2022.05.10 |
[C++] for 문을 사용할때 조건식에서 주의해야 할 점(unsigned와 size_type 그리고 overflow) (0) | 2022.02.17 |
[C++] emplace_back()과 push_back(), 그리고 Clang-Tidy Bug (0) | 2022.02.16 |
[C++] Attributes (0) | 2022.02.03 |