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 | 31 |
Tags
- kubernetes component
- 상속성
- kubernetes in actin
- 캡슐화
- ArgoCD
- applicationset
- Encapsulation
- kubernetes in action
- Abstraction
- 빌드
- 추상화
- 위임
- 레이블
- 피터코드의 상속규칙
- 메이븐
- 어플리케이션셋
- OOP
- 쿠버네티스 어노테이션
- kubenetes
- argocd applicationset
- 객체지향
- maven
- kube
- kubernetes
- 피터코드
- kubenetes architecture
- kubenetes in action
- delegation
- 레이블 셀렉터
- 쿠버네티스
Archives
- Today
- Total
목록위임 (1)
IT 끄적장

앞선 포스팅에서 일반화를 통한 상속성에 대하여 살펴보았다. 그렇다면 이번 포스팅에서는 어떠한 기준으로 자식 클래스들과 부모 클래스 간 상속관계가 이루어져야 하는 공부 해보자. 사실 많은 개발자들은 단순히 코드의 재사용을 위해 클래스 간 상속 관계를 인위적으로 만들어준다. 그러나, 단순히 코드의 재사용을 위한 상속관계는 클래스 간 결합도를 높여 유지보수를 유연하지 못하게 만드는 부작용이 존재한다. 다음 예시를 통하여 좀 더 자세히 살펴보자. ArrayList 클래스를 상속받아 Stack 클래스를 만들려는 개발자가 있다. 아마도 이 개발자의 의도는 ArrayList에 정의된 메소드를 자신이 구현하지 않고 코드의 재사용을 의도했을 것이다. 재사용성의 측면으로만 본다면 개발자의 의도대로 성공적이었을 것이다. 그..
OOP
2019. 11. 14. 22:50