기술서적 정리/오브젝트 - 코드로 이해하는 객체지향 설계 (15) 썸네일형 리스트형 07 CHAPTER 객체 분해 https://wikibook.co.kr/object/ 오브젝트: 코드로 이해하는 객체지향 설계 역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라! 객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두 번째 걸음은 객체를 wikibook.co.kr ◈ 프로시저 추상화와 기능 분해 하향식 기능 분해 방식이 가지는 문제점을 이해하는 것은 유지보수 관점에서 객체지향의 장점을 이해할 수 있는 좋은 출발점이다. 하향식 기능 분해의 문제점 1. 시스템은 하나의 메인 함수로 구성돼 있지 않다. 2. 기능 추가나 요구사항 변경으로 인해 메인 함수를 빈번하게 수정해야 한다. 3. 비즈니스 로직이 사용자 인터페이스와 강하게 결합된다. 4. 하향식 분해는 너무 이른 .. 06 CHAPTER 메시지와 인터페이스 https://wikibook.co.kr/object/ 오브젝트: 코드로 이해하는 객체지향 설계 역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라! 객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두 번째 걸음은 객체를 wikibook.co.kr 객체지향 프로그래밍에 대한 가장 흔한 오해는 애플리케이션이 클래스의 집합으로 구성된다는 것이다. 클래스가 아니라 객체를 지향해야 한다. 훌륭한 객체지향 코드를 얻기 위해서는 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야 한다. 중요한 것은 책임이 객체가 수신할 수 있는 메시지의 기반이 된다는 것이다. 객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스를 구성한다. 훌륭한 퍼블릭 인터페이스를 얻기 위해.. 05 CHAPTER 책임 할당하기 https://wikibook.co.kr/object/ 오브젝트: 코드로 이해하는 객체지향 설계 역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라! 객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두 번째 걸음은 객체를 wikibook.co.kr 책임에 초점을 맞춰서 설계할 때 직면하는 가장 큰 어려움은 어떤 객체에게 어떤 책임을 할당할지를 결정하기 쉽지 않다는 것이다. GRASP 패턴을 이해하고 나면 응집도와 결합도, 캡슐화 같은 다양한 기준에 따라 책임을 할당하고 결과를 트레이드오프할 수 있는 기준을 알 수 있다. ◈ 책임 주도 설계를 향해 데이터 중심의 설계에서 책임 중심의 설계로 전환하기 위해서는 다음의 두 가지 원칙을 따라야 한다. 1... 04 CHAPTER 설계 품질과 트레이드 오프 https://wikibook.co.kr/object/ 오브젝트: 코드로 이해하는 객체지향 설계 역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라! 객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두 번째 걸음은 객체를 wikibook.co.kr 객체지향 설계의 핵심은 역할, 책임, 협력이다. 협력은 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호작용이다. 책임은 객체가 다른 객체와 협력하기 위해 수행하는 행동이다. 역할은 대체 가능한 책임의 집합이다. 훌륭한 설계란 합리적인 비용안에서 변경을 수용할 수 있는 구조를 만드는 것이다. ◈ 설계 트레이드 오프 이 장에서는 데이터 중심 설계와 책임 중심 설계의 장단점을 비교하기.. 03 CHAPTER 역할, 책임, 협력 https://wikibook.co.kr/object/ 오브젝트: 코드로 이해하는 객체지향 설계 역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라! 객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두 번째 걸음은 객체를 wikibook.co.kr 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 클래스와 상속은 객체들의 책임과 협력이 어느 정도 자리를 잡은 후에 사용할 수 있는 구현 메커니즘일 뿐이다. 애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할과 책임이 필요한지를 고민하지 않은 채 너무 이른 시기에 구현에 초점을 맞추는 것은 변경하기 어렵고 유연하지 못한 코드를 낳는 원인이 된다. 01 협력 협력.. 02 CHAPTER 객체지향 프로그래밍 https://wikibook.co.kr/object/ 오브젝트: 코드로 이해하는 객체지향 설계 역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라! 객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두 번째 걸음은 객체를 wikibook.co.kr 협력, 객체, 클래스 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 1. 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지 고민해야한다. 클래스 : 공통적인 상태와 행동을 공유하는 객체들을 추상화한 것. 그래서 클래스의 윤곽을 잡기 위해서는 어떤 객체들이 어떤 상태와 행동을 가지는지를 먼저 결정해야한다. 2. 객체를 독립적인 존재가 아니라 기능을 구현.. 01 CHAPTER 객체, 설계 https://wikibook.co.kr/object/ 오브젝트: 코드로 이해하는 객체지향 설계 역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라! 객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두 번째 걸음은 객체를 wikibook.co.kr 모든 모듈은 1) 제대로 실행돼야 하고, 2) 변경이 용이해야 하며, 3) 이해하기 쉬워야 한다. 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루면 코드를 작성하는 사람뿐만 아니라 코드를 읽고 이해해야하는 사람 모두에게 큰 부담을 준다. 다른 클래스가 특정 클래스의 내부에 대해 더 많이 알면 알수록 그 클래스를 변경하기 어려워진다. 의존성 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에 의.. 이전 1 2 다음