일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- HTML
- 이종호
- 자스민
- Hitit
- 자바스크립트
- 개발
- 자바스크립트 자료구조
- 리액트 예제
- SWIFT
- 비동기
- hokeys
- react
- IOS
- javascript
- 호키스
- Svelte
- 스위프트
- 자료구조
- 힛잇
- queue
- TDD
- 계명대
- 호키도키
- 리액트
- jest
- 계명대 이종호
- 개발자
- hokidoki
- data structure
- 스벨트
Archives
- Today
- Total
Dog foot print
[Architecture] S.O.L.I.D [I] 본문
서론
지난 포스팅에 이어 오늘은 [i]에 대해서 포스팅 하도록 하겠습니다.
ISP (Interface Segregation Principal) : 인터페이스 분리 원칙
인터페이스 분리 원칙은 어떤 인터페이스로부터 상속받아 클래스를 정의 할 때, 사용하지 않는 메서드까지 상속 받지 말고 새로운 인터페이스를 생성하여 기존 상속하려던 인터페이스를 새롭게 확장하여 상속 받아야 한다는 분리원칙이다.
다음의 클래스다이어그램을 보도록 하자 .
위의 클래스 다이어그램에서 파리,벌,사슴벌레 클래스는 곤충 인터페이스를 상속받는다. 이 경우 파리 클래스에서는 독을 뿜다. 라는 메서드가 필요없으며, 벌 클래스와 사슴벌레 클래스에서는 각각 뿔을 움직인다, 독을 뿜다라는 메서드가 필요없음에도 곤충인터페이스를 상속 받았기 때문에 구현해야 한다.
조금 더 극단적인 클래스 다이어그램을 보도록 하자 .
위와 같은 클래스 다이어그램이 존재 할 때 USER인터페이스를 상속 받는 클래스들은 각각 op1,op2,op3만 실제로 사용한다고 가정해보자. 이러한 경우, 각 클래스에서는 사용하지도 않는 메서드를 모두 구현해야하는 낭비가 발생한다.
ISP는 이러한 불필요하게 인터페이스의 모든 기능을 구현하기보다, 새로운 인터페이스를 만들고 기존 인터페이스를 확장하여 다음과 같이 각각 필요한 메서드만 구현하도록 만들도록 지시한다.
무엇을 얻을 수 있는가 ?
각 클래스가 사용하지 않는 메서드에 의존 할 필요가 없어진다.
반응형
'Architecture' 카테고리의 다른 글
[GOF] 추상 팩토리 메서드 패턴 (0) | 2021.10.23 |
---|---|
[GOF] 팩토리 메서드 패턴 (0) | 2021.10.17 |
[Architecture] S.O.L.I.D [D] (0) | 2021.05.13 |
[Architecture] S.O.L.I.D [L] (0) | 2021.05.06 |
[Architecture] S.O.L.I.D [S,O] (0) | 2021.04.30 |
Comments