디커플링의 단점 2가지
노트 유형: Cloze
Text
디커플링(추상화)으로 유연성·재사용성을 얻는 대신 생기는 단점 2가지:
- {{c1::직관적이지 못함}} — 구체적이지 않기 때문(추상화의 단점). 어떤 구체 개체가 사용됐는지 알려면 구현 클래스들을 일일이 확인해야 함
- {{c2::내부(구현)를 알아야 더 좋은 경우가 있음}} — 모든 구현에서 동작하게 만들면 특정 구현에는 불필요한 코드가 생김 = {{c3::추상화로 인한 비효율}} (예: Collection의 어느 구현이든 중복 없이 넣으려면 contains() 검사가 필요한데 Set 구현엔 불필요)
Back Extra
- 단점 1이 심해지는 경우: DI 컨테이너를 쓰면 new 하는 코드조차 없이 텍스트 파일로 개체가 결정돼 추적이 더 어려움
- 단점 1의 관련 사례: 프로그램마다 다른 구체 개체를 하나씩만 쓰는 건 다형성 오용 — 다형성은 하나의 프로그램에서 여러 구체 개체를 쓸 때. 이 경우 올바른 방식은 컴파일러 플래그로 구현체 선택 (C#/C++ 방식)
- 단점 2의 대안: 더 구체적인 인터페이스(Set)를 사용하면 최적화 가능 — 대신 받아줄 타입이 좁아지는 트레이드오프
- 코드 예: 801-004-012의 mergeTo() 문제 https://pocu-site.pages.dev/pocu-note/COMP2500/801-exam/801-004-exercise-final/801-004-012-decoupling-fit-and-cost/