![[오브젝트] 7장 객체 분해](/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fattachment%253Ae47bc891-746c-4fa4-8237-814e4e1e22bb%253A%25E1%2584%258B%25E1%2585%25A9%25E1%2584%2587%25E1%2585%25B3%25E1%2584%258C%25E1%2585%25A6%25E1%2586%25A8%25E1%2584%2590%25E1%2585%25B3.jpeg%3Ftable%3Dblock%26id%3D25ea12d0-8f8e-80c1-9b9b-e8908c481251%26cache%3Dv2&w=1920&q=75)
![[오브젝트] 7장 객체 분해](/_next/image?url=https%3A%2F%2Fwww.notion.so%2Fimage%2Fattachment%253A8623b7cb-959c-480f-9f91-fe4872eade71%253A%25E1%2584%258B%25E1%2585%25A9%25E1%2584%2587%25E1%2585%25B3%25E1%2584%258C%25E1%2585%25A6%25E1%2586%25A8%25E1%2584%2590%25E1%2585%25B3.jpeg%3Ftable%3Dblock%26id%3D25ea12d0-8f8e-80c1-9b9b-e8908c481251%26cache%3Dv2&w=1920&q=75)
객체 분해
불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을 추상화라고 부른다.
객체 지향은 데이터를 중심으로 프로시저를 추상화하는 것이다.
프로시저 추상화와 기능 분해
전통적인 기능 분해 방법인 '하향식 접근법'은 문제점이 많다.
- 시스템은 하나의 메인 함수로 구성돼 있지 않다.
- 기능 추가나 요구사항 변경으로 인해 메인 함수를 빈번하게 수정해야 한다.
- 비즈니스 로직이 사용자 인터페이스와 강하게 결합된다.
- 하향식 분해는 너무 이른 시기에 함수들의 실행 순서를 고정시키기 때문에 유연성과 재사용성이 저하된다.
- 데이터 형식이 변겨될 경우 파급효과를 예측할 수 없다.
데이터와 함께 변경되는 부분과 그렇지 않은 부분을 명확하게 분리해야 한다.
🤔
가장 큰 문제는 요구 사항에 대한 대처가 많이 어렵다는 것
모듈
시스템을 모듈로 분할하는 원칙은 외부에 유출돼서 안 되는 비밀의 윤곽을 따라야 한다.
- 복잡성 : 모듈이 너무 복잡한 경우 이해하고 사용하기가 어렵다. 외부에 모듈을 추상화할 수 있는 간단한 인터페이스를 제공해서 모듈의 복잡도를 낮춘다.
- 변경 가능성 : 변경 가능한 설계 결정이 외부에 노출될 경우 실제로 변경이 발생했을 때 파급효과가 커진다. 변경 발생 시 하나의 모듈만 수정하면 되도록 변경 가능한 설계 결정을 모듈 내부로 감추고 외부에는 쉽게 변경되지 않을 인터페이스를 제공한다.
모듈 외부에서 데이터에 직접 접근할 수 없다.
모듈 외부에서는 모듈 내부에 어떤 데이터가 존재하는지조차 알지 못한다.
모듈 내부의 변수가 변경되더라도 모듈 내부에만 영향을 미친다.
비즈니스 로직과 사용자 인터페이스에 대한 관심사를 분리한다.
전역 변수와 전역 함수를 제거함으로써 네임프세피으 오염을 방지한다.
모듈은 기능이 아니라 변경의 정도에 따라 시스템을 분해하게 한다.
🤔
추상 데이터와 클래스
추상 데이터 타입이 오퍼레이션을 기준으로 타입을 묶는다.
객체 지향은 타입을 기준으로 오퍼레이션을 묶는다.
추상 데이터 타입과 객체지향 설계의 유용성은 설계에 요구되는 변경의 압력이 '타입 추가'에 관한 것인지
아니면 '오퍼레이션 추가'에 관한 것인지에 따라 달라진다.