일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
- 코틀린
- UWP
- android push
- mfc
- android architecture component
- Java
- flutter firestore
- FLUTTER
- C
- 프로그래머스
- Python
- NDK
- Django REST Android
- 안드로이드
- 안드로이드 구글맵
- Django REST framework
- Android
- kodility
- Flutter TextField
- C++
- Rxjava2
- RxJava
- C/C++
- 알고리즘
- dart
- RxAndroid
- Django REST
- Android P
- Kotlin
- livedata
- Today
- Total
개발하는 두더지
[Effective Java 규칙18] 추상 클래스 대신 인터페이스를 사용하라 본문
[Effective Java 규칙18] 추상 클래스 대신 인터페이스를 사용하라
Effective Java 2/E 책과 구글링을 통해 내용을 정리하고 개인적인 견해가 포함된 글입니다.
이미 존재하는 클래스를 개조해서 새로운 인터페이스를 구현하는 것은 간단하다. 자바 플랫폼에 Comparable 인터페이스가 추가된 이후, 많은 기존 클래스들이 Comparable을 구현하도록 개조되었다. 인터페이스는 믹스인(mixin)을 정의하는데 아주 유용한데 믹스인이 무엇이냐면
어떤 주기능 A를 제공하는데 선택 기능 B를 제공하여 기능을 혼합할 수 있다는 것을 의미한다.
예를들어 Comparable을 구현한 클래스를 예를 들어보자. 클래스는 원래 본연의 기능A가 있을 것이다.. 하지만 Comparable을 구현(implements)함으로써 자신의 객체는 다른 객체와 비교 결과에 따라 순서를 가진다는 기능B를 가지게 되는데 이런 인터페이스를 믹스인 인터페이스라고 한다.
인터페이스는 다양한 구현이 가능한 클래스 확장하는 좋은 방법이다. 유연하고 강력한 API를 만드는 것보다 개선이 쉬운 API를 만드는 것이 중요한 경우에는 추상 클래스를 사용해야 하는데, 단점을 잘이해하고 수용할 수 있는 경우에만 사용해야 한다. 중요한 인터페이스를 API에 포함시키려는 경우에는 스켈레톤 구현 클래스를 함께 제공하는 것이 어떨지 고려해야 한다. 마지막으로 public 인터페이스는 주의해서 설계해야 하며, 실제로 여러 구현을 만들어보면서 광범위하게 테스트해야 한다.
평소에 업체에 제공할 API를 만들 때 위의 내용을 고민하지 않고 기능 위주로 구현하고 완성되면 바로 릴리즈하고 배포했는데 아주 심각하게 잘못 된 것 같다. 혼자서 별다른 고민없이 만든 것이 일단 최초의 문제 같다. 앞으로 배포할 때는 신중하게 설계에 대해 고민을 하고 테스트 케이스를 조금이라도 만들어 봐야겠다.
'Java,Android' 카테고리의 다른 글
[Effective Java 규칙19] 인터페이스는 자료형을 정의할 때만 사용하라 (0) | 2018.09.26 |
---|---|
WorkManager로 안드로이드 하위 버전부터 오레오 버전까지 백그라운드 작업 통합 (1) | 2018.09.19 |
[Effective Java 규칙17] 상속을 위한 설계와 문서가 없다면 상속하지 마라 (0) | 2018.09.17 |
[Effective Java 규칙16] 상속(extends)하는 대신 구현(implements)하라 (0) | 2018.09.17 |
[Effective Java 규칙15] 변경 가능성을 최소하하라 (0) | 2018.09.14 |