Notice
Recent Posts
Recent Comments
Link
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
Tags
- 디자인패턴
- builderPattern
- factory method
- 디자인패턴 #
- r
- 빌터패턴
- 코틀린
- 추상 팩토리
- ㅋㅁ
- El
- F
- Design Pattern
- 프로토타입 패턴
- Functional Programming
- a
- 싱글톤
- Observer Pattern
- designPattern
- Singleton
- 옵저버 패턴
- Kotlin
- 함수형프로그래밍
- Abstract Factory
- 팩토리 메소드
- 추상팩토리패턴
- ㅓ
- PrototypePattern
Archives
- Today
- Total
오늘도 더 나은 코드를 작성하였습니까?
Interface Segregation 본문
인터페이스 분리 원칙은 클라이언트가 자신이 이용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다.
인터페이스 분리 원칙은 큰 덩어리의 인터페이스들을 구체적이고 작은 단위들로 분리시킴으로써 클라이언트들이 꼭 필요한 메서드들만 이용할 수 있게 한다. 이와 같은 작은 단위들을 역할 인터페이스라고도 부른다. 인터페이스 분리 원칙을 통해 시스템의 내부 의존성을 약화시켜 리팩토링, 수정, 재배포를 쉽게 할 수 있다.
예를 들어 탱크의 기능을 가진 인터페이스를 정의 하고 이를 구현하려고 한다.
아래의 6개의 기능을 정의 하였다.
interface Tank{
fun forward()
fun backward()
fun turnLeft()
fun turnRight()
fun aiming()
fun shoot()
}
하지만 이렇게 1개의 큰 인터페이스를 생성하여 구현하는 것보다는, 2개의 세분화되고 좀 더 구체적인 기능을가진 인터페이스들로 분리하여 2개의 인터페이스를 구현한 객체를 생성하는것이 조금더 유지보수 및 확장성에 있어 용이하다.
/* 화기류 */
interface Firearms{
fun aiming()
fun shoot()
}
/* 이동수단 */
interface Vehicle{
fun forward()
fun backward()
fun turnLeft()
fun turnRight()
}
'디자인패턴' 카테고리의 다른 글
전략패턴(Strategy Pattern) (0) | 2022.07.11 |
---|---|
Dependency Inversion Principle (0) | 2021.12.28 |
리스코프 치환법칙(Liskov Substitution) (0) | 2021.12.28 |
Open-Closed Principle (0) | 2021.12.24 |
디자인 패턴의 원칙 (Single responsibility) (0) | 2021.12.24 |