객체지향 원리
추상화
추상솨는 사물들의 공통된 특징, 즉 추상적인 특징을 파악해 인식의 대상으로 삼는 행위이다.
그러므로 추상화를 한다는 것은 여러 개체들을 집합으로 파악한다는 것과 같다.
각 개체의 구체적인 개념에 의존하지 말고 추상적인 개념에 의존해야 설계를 유연하게 변경 할 수 있다.
캡슐화
캡슐화는 정보은닉을 통해 높은 응집도와 낮은 결합도를 갖도록 한다.
일반화(상속) 관계
- 많은 사람들이 일반화 관계를 속성이나 기능의 상속, 즉 재사용을 위해 존재한다고 오해하고 있다. 그러나 이는 사실이 아니다.
- 기본적으로 일반화 관계는 is a kind of관계가 성립되어야 한다.
- 두 자식 클래스 사이에 is a kind of 관계가 성립되지 않을 때 상속을 사용하면 불필요한 속성이나 연산도 물려받게 된다.
- 기능을 재사용할 필요가 있을때는 상속보다 위임(delegation)을 이용
public class MyStack{
private ArrayList arList = new ArrayList();
}
- 일반화는 자식 클래스들의 적절한 합집합과 교집합으로 이루어진다.
다형성(polymorphism)
객체지향에서 다형성은 서로 다른 클래스의 객체가 같은 메시지를 받았을 때 각자의 방식으로 동작하는 능력이다.
피터 코드의 상속 규칙
피터 코드(peter coad)는 상속의 오용을 막기 위해 상속의 사용을 엄격하게 제한하는 규칙들을 만들었다
- 자식 클래스와 부모 클래스 사이는 '역활 수행' 관계가 아니어야 한다
- 한 클래스의 인스턴스는 다른 서브 클래스의 객체로 변환할 필요가 절대 없어야 한다
- 자식 클래스가 부모 클래스의 책임을 무시하거나 재정의하지 않고 확장만 수행해야 한다.
- 자식 클래스가 단지 일부 기능을 재사용할 목적으로 유틸리티 역활을 수행하는 클래스를 상속하지 않아야 한다.
- 자식 클래스가 역활, 트랜잭션, 디바이스 등을 특수화 해야한다.
예 ) 사람을 상속받는 운전자, 회사원
자세한건 p80
SOLID 원칙
단일 책임 원칙(SRP : single responsiblity principle)
SRP에서 말하는 책임의 기본 단위는 객체를 지칭한다.
즉, 객체는 단 하나의 책임만 가져야 한다는 의미다.
책임
- = 해야하는 것
- = 할 수 있는 것
- 해야 하는 것을 잘 할 수 있는 것
SRP르 따르는 실효성 있는 설계가 되려면 책임을 좀 더 현실적인 개념으로 파악할 필요가 있다.
우리가 설계 원칙을 학습하는 이유는 예측하지 못한 변경사항이 발생하더라도 유연하고 확장성이 있도록 시스템 구조를 설계하기 위해서다.
좋은 설계란 기본적으로 시스템에 새로운 요구사항이나 변경이 있을 때 가능한 한 영향 받는 분분을 줄여야 한다.
가령 어떤 클래스가 잘 설계되었는지를 판단하려면 언제 변경되어야 하는지를 물어보는 것이 좋다.
개방-패쇄 원칙(OCP : open close principle)
어려운 말처럼 들이지만 의미는 매우 명확하다. 기존의 코드를 변경하지 않으면서 기능을 추가할 수 있도록 설계가 되어야 한다는 뜻이다.
리스코프 치환 원칙(LSP : liskov substitution principle)
- LSP는 부모클래스와 자식 클래스 사이의 행위가 일관성이 있어야 한다는 의미다.
- LSP를 이해하려면 일반화 관계를 다시 생각해볼 필요가 있다.
- LSP를 만족시키는 간단한 방법은 재정의하지 않는 것이다.
의존 역전 원칙(DIP : dependency inversion principle)
객체 사이에 서로 도움을 주고 받으면 의존 관계가 발생한다.
DIP는 그러한 의존 관계를 맺을 때의 가이드라인에 해당한다.
누군가의 도움을 받을 때는 무조건 도움을 받으려고 여기저기 손을 내밀 게 아니라 나름대로의 원칙을 가지고 도움을 청해야 효과적인 도움을 받을 수 있다.
DIP는 의존 관계를 맺을 때 변화하기 쉬운 것 또는 자주 변화하는 것보다는 변화하기 어려운 것, 거의 변화가 없는 것에 의존하라는 원칙이다.
- 변화하기 어려운 것 : 정책 전략과 같은 어떠한 흐름이나 개념 같은 추상적인 것
- 변화하기 쉬운 것 : 방식, 사물 등
DIP를 만족하면 의존성 주입(Dependency Injection)이라는 기술로 변화를 쉽게 수용할 수 있는 코드를 작성할 수 있다. 말 그대로 클래스 외부에서 의존되는 것을 대상 객체의 인스턴스 변수에 주입하는 기술이다.
인터페이스 분리 원칙(ISP : interface segegation principle)
클라이언트의 필요에 따라 프린터 기능만 이용하든지, 팩스 기능만 이용하든, 복사기 기능만 이용할 수 있다. 따라서 프린터 기능만 이용하는 클라이언트가 팩스 기능의 변경으로 인해 발생하는 문제의 영향을 받지 않도록 해야한다.
그러기 위해서는 범용의 인터페이스 보다는 클라이언트에 특화된 인터페이스를 사용해야 한다.
즉, 인터페이스를 클라이언트에 특화되도록 분리시키라는 설꼐 원칙이라고도 할 수 있다.
Review
SOLID 원칙은 수십번도 넘게 찾아본 개념이다. 찾을때마다 아 그렇지 그렇지만 바쁘니까 안되라고 생각했던 로직들이 머리에서 떠오르며 반성하게 됬다. 바빠서 못하는게 아니라 어중간하게 지키고 있어서 이정도면 괜찮지 라고 생각했던거 같다.
그 뒤에 디자인 패턴들에 대해서는 읽지 않았다.
ETC
AOP 용어 설명
'Learning' 카테고리의 다른 글
새로운 CSS 레이아웃 (0) | 2019.01.08 |
---|---|
해커를 위한 디자인 레슨 (0) | 2018.11.08 |
도메인 주도 설계 소프트웨어의 복잡성을 다루는 지혜 (0) | 2018.08.01 |
REST API 디자인 규칙 (1) | 2018.07.20 |
프로젝트가 서쪽으로 간 까닭 (0) | 2018.07.10 |
댓글