sh1mj1_log

상속은 크게 두 가지로 목적으로 사용됩니다. 상속은 타입 계층을 구현하기 위해 사용됩니다. 부모 클래스는 계층 안에서 일반적인 개념을 구현하고 자식클래스는 특수한 개념을 구현합니다. 상속은 코드 재사용을 위해 사용됩니다. 간단한 선언으로 부모 클래스의 코드를 재사용할 수 있습니다. 하지만 재사용을 위해 상속으 사용하면 부모 클래스와 자식 클래스가 강하게 결합되기 때문에 변경하기 어려운 코드를 얻게 될 확률이 높습니다. 그러므로 상속의 사용의 일차적인 목표는 타입 계층을 구현하기 위함이어야 합니다. 코드 재사용을 목표로 상속을 사용하면 부모, 자식 클래스가 강하게 결합되어 설계의 변경을 방해합니다. 하지만 타입 계층을 목표로 상속을 사용하면 다형적으로 동작하는 객체들의 관계에 기반하여 확장 가능하고 유연한..

상속은 클라이언트 관점에서 인스턴스들을 동일하게 행동하는 그룹으로 믂고 싶을 때 사용해야 합니다. 단지 단순히 코드를 재사용하기 위함이 목적이면 안 됩니다! 다형성은 런타임에 메시지를 처리하기에 적합한 메서드를 동적으로 찾는 과정을 통해서 구현됩니다. 또 상속은 이런 메서드를 찾기 위한 탐색 경로를 클래스 계층의 형태로 구현하기 위한 방법입니다. 상속의 관점에서 다형성이 구현되는 기술적인 매커니즘을 먼저 살펴봅시다. 다형성 다형성(Polymorphism)은 여러 타입을 대상으로 동작할 수 있는 코드를 작성할 수 있는 방법입니다. 객체지향 프로그래밍에서 다형성은 아래처럼 분류될 수 있습니다. 오버로딩 다형성: 하나의 클래스 안에 동일한 메서드 존재하는 경우입니다. 흔히 말하는 메서드 오버로딩이 이 경우이죠..

잘 설계된 객체지향 App. 은 작고 응집도 높은 객체들로 구성됩니다. 책임이 명확하고 한 가지 일을 잘하는 객체이지요. 이 객체들이 협력을 하는 것입니다. 협력은 하면 필연적으로 의존성이 발생합니다. 너무 과한 협력은 과한 의존성을 발생시키므로 결국 '적당히' 가 중요합니다. 충분히 협력적이면서도 유연한 객체르 만들기 위한 의존성 관리에 대한 글입니다. 의존성 변경과 의존성 의존성은 의존하고 있는 대상의 변경에 영향을 받을 수 있는 가능성입니다. 실행 시점 의존성: 의존하는 객체가 정상적으로 동작하기 위해서는 실행 시에 의존 대상 객체가 반드시 존재해야 함. 구현 시점 의존성: 의존 대상 객체가 변경될 경우 의존하는 객체도 함께 변경됨. 위 글만 읽으면 무슨 소리인지 잘 이해가 안되는데, 코드를 통해서..

프로시저 추상화와 데이터 추상화 프로그래밍 언어의 두가지 추상화 메커니즘은 프로시저 추상화(procedure abstraction) 와 데이터 추상화(data abstraction) 입니다 . 각각 소프트웨어가 무엇을 해야 할지를 추상화하고, 소프트웨어가 무엇을 알아야 하는지를 추상화합니다. 시스템을 분해하는 방법을 결정하려면 프로시저 추상화를 중심으로 할 것인지, 데이터 추상화를 중심으로 할 것인지를 결정해야 합니다. 프로시저 추상화를 중심으로 하면 기능 분해(functional decomposition) == 알고리즘 분해(algorithmic decomposition) 을 하는 것이며, 데이터 추상화를 중심으로 하면 데이터를 중심으로 타입을 추상화(type abstraction) == 추상 데이터 ..

메시지와 인터페이스 객체 지향 애플리케이션의 가장 중요한 재료는 클래스가 아닌 객체들이 주고받는 메시지입니다. 객체를 수신하는 메시지들이 객체의 퍼블릭 인테페이스를 구성합니다. 책임 주도 설계 방법 + 좋은 퍼블릭 인터페이스를 얻기 위한 설계 원칙과 기법을 익히고 적용해야 합니다. 협력과 메시지 클라이언트 - 서버 모델 두 객체 사이의 협력 관계를 설명할 때 전통적으로 클라이언트 - 서버(Client - Server) 모델 을 사용합니다. 메시지를 전송하는 객체가 클라이언트, 수신하는 객체가 서버입니다. 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이죠 위 그림에서 클라이언트 Screening 이 가격을 계산하라 메시지를 전송하여 도움을 요청하고 서버 Movie 는 가격을 계산하는 서비스를 제공하..

https://sh1mj1-log.tistory.com/131 이 글에서는 책임 중심 설계의 객체 지향 코드의 대략적인 모양, https://sh1mj1-log.tistory.com/133 이 글에서는 역할, 책임, 협력이 객체지향적인 코드를 작성하기 위한 핵심이라는 사실, https://sh1mj1-log.tistory.com/137 이 글에서는 데이터에 초점을 맞출 때 생기는 문제점에 대해 알아보았습니다. 이번에는 책임 중심 설계의 설계 과정을 하나씩 따라가보면서 책임 할당 기본 원리를 살펴봅시다. 책임 할당 책임 주도 설계를 향해서 두가지 원칙을 지켜야 합니다. 데이터보다 행동을 먼저 결정하자 협력이라는 문맥 안에서 책임을 결정하자 데이터보다 행동을 먼저 결정하자 먼저 '이 객체가 수행해야 하는 책..

이전 글 https://sh1mj1-log.tistory.com/133 에서 객체지향 설계의 핵심은 역할, 책임, 협력 이라고 했습니다. 협력: 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호작용. 책임: 객체가 다른 객체와 협력하기 위해 수행하는 행동. 역할: 대체 가능한 책임의 집합. 책임이 객체지향 애플리케이션 전체의 품질을 결정합니다. 책임 할당은 응집도와 결합도와 같은 설계 품질과 깊이 연관되어 있습니다. 설계는 변경을 위해 존재하고 변경에는 비용이 발생합니다. 좋은 설계는 비용을 최소화하는 것이지요. 응집도가 높고 결합도가 낮은 것이 좋은 설계입니다. 그를 위해서 객체의 상태가 아닌 행동에 집중합니다. 또 그를 위해 객체의 책임에 초점을 맞추는 것이 좋습니다. 이번 장..