
대부분의 사람들은 이론이 정립된 후 실무가 그에 따라 발전된다고 생각하지만,분야를 막론하고 이론을 정립할 수 없는 초기에는 실무가 먼저 급속한 발전을이룬다. 한마디로 이론보다 실무가 먼저라는 것 이다. 그런 맥락에서 짧은 시간내에 발전한 소프트웨어 분야의 경우 실무에

'영화'와 '상영'을 구분할 필요가 있다. '영화'는 영화에 대한 기본 정보를 나타내고'상영'은 실제로 관객이 영화를 관람하는 사건으로, 관객은 이를 위해 돈을 지불하기때문에 분리하여 생각하는 것이 중요하다.특정 조건을 만족하는 예매자는 요금을 할인받을 수 있다. 할인

객체지향의 관점에서 핵심은 역할, 책임, 협력 이다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 🏙 협력 객체들이 어플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 협력 이라고 한다. 객체가 협력에 참여하기 위해 수행하는 로직을 책임이라고
책임 주도 설계라는 이름에서 알 수 있듯이 역할, 협력, 책임 중에서 가장 중요한 것은 책임이다. 책임이 어플리케이션 전체의 품질을 결정한다. > 객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동이다.

⛳ 책임 주도 설계를 향해 데이터 중심 설계에서 책임 중심 설계로 전환하기 위해서는 다음 두 원칙을 따라야 한다. 데이터보다 행동을 먼저 결정하라 협력이라는 문맥 안에서 책임을 결정하라 핵심은 데이터가 아니라 객체의 책임과 협력에 초점을 맞추라는 것이다. 데이터보다

OOP에 대한 가장 흔한 오해는 애플리케이션이 클래스의 집합이라는 것이다. 하지만 클래스는 실제적, 구체적인 도구일 뿐이고 훌륭한 코드를 위해서는 객체를 지향해야 한다. 좀 더 정확히 말해서 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야 한다. 책임이 객체가 수신할
사람의 기억은 단기 기억과 장기 기억으로 나뉘는데 장기 기억은 먼저 단기 기억의 영역으로 옮긴 후에 처리가 가능하다고 한다. 문제 해결에 필요한 요수의 수가 단기 기억의 용량을 초과화는 순간 문제 해결 능력이 급격히 떨어지는데, 이 현상을 인지 과부하(cognitive
잘 설계된 객체지향 어플리케이션은 작고 응집도 높은 객체들로 구성된다. 작고 응집도 높은 객체란 책임의 초점이 명확하고 한 가지 일만 잘하는 객체를 의미한다. 일반적으로 기능을 구현하기 위해선 객체 사이의 협력이 발생한다. 협력을 위해서는 의존성이 필요하지만 과도한

이 장에서는 8장에서 살펴본 다양한 의존성 관리 기법들을 원칙이라는 관점에서 정리한다.소프트웨어 개체(클래스, 모듈, 함수 등등)는 확장에 대해 열려 있어야 하고, 수정에대해서는 닫혀 있어야 한다.여기서 키워드는 '확장'과 '수정'으로, 애플리케이션의 '동작'과 '코드

객체지향에서 코드는 일반적으로 클래스 내에 작성이 되기 때문에 객체지향에서 클래스를 재사용하는 전통적인 방법은 새로운 클래스를 추가하는 것이다. 객체지향에는 상속과 합성이라는 대표적인 클래스 재사용 기법이 존재한다. 이들의 이점과 차이를 비교해보자.중복 코드는 변경을

상속과 합성은 OOP에서 가장 널리 사용되는 코드 재사용 기법이다. 합성은 전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용한다. 상속에서 부모-자식 클래스 간 의존성은 컴파일타임에 해결되지만 합성에서 두 객체 사이의 의존성은 런타임에

OOP가 주목받기 시작하던 초기에 상속은 타입 계층과 다형성을 구현할 수 있는 거의 유일한 방법이었다. 하지만 최근의 언어들은 상속 외에도 다형성을 구현할 수 있는 다양한 방법들을 제공하고 있기에 과거에 비해 상속의 중요성이 많이 낮아졌다.이번 장은 다형성이 런타임에

상속에 대한 오해를 해소하기 위해 상속이 두 가지 용도로 사용된다는 사실을 이해하자.상속의 첫번째 용도는 타입 계층을 구현하는 것이다. 타입 계층의 관점에서 부모 클래스는 자식 클래스의 일반화이고 자식 클래스는 부모 클래스의 특수화이다.상속의 두번째 용도는 코드 재사용

객체지향 설계의 목표는 적절한 책임을 수행하는 객체들의 협력을 기반으로 결합도가 낮고 재사용 가능한 코드 구조를 창조하는 것이다. 하지만 재사용은 공짜로 얻어지지 않는다. 재사용을 위해서는 객체들의 협력 방식을 일관성 있게 만들어야 한다. 가능하면 유사한 기능을 구현하

소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 해결 방법을 디자인 패턴이라고 부른다. 디자인 패턴이 설계를 재사용하기 위한 것이라면 프레임워크는 설계와 코드를 함께 재사용하기 위한 것이다. 프레임워크는 애플리케이션의 아키텍처를 코드 형태