sh1mj1_log

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

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

상속은 부모 클래스와 자식 클래스를 연결해서 부모 클래스의 코드를 재사용하고 합성은 전체를 표현하는 객체가 부분을 표현하는 객체를 포함해서 부분 객체의 코드를 재사용합니다. 상속 관계는 is-a 관계입니다. 자식 클래스가 Cat, 부모 클래스가 Animal 이면 Cat is a Animal 인 것이죠. 합성은 has-a 관계입니다. Cat has a Claw(발톱). 형식이지요. 이 둘은 코드 재사용이라는 동일한 목적을 가지지만, 이것을 제외하면 구현 방법, 변경을 다루는 방식이 다릅니다. 상속은 부모 클래스의 코드를 자식 클래스가 자신의 것처럼 사용하고, override 할 수 있게 합니다. 하지만 부모 클래스의 내부 구현, 의도를 자세히 알고 이해해야 상속을 제대로 사용할 수 있기 때문에 자식 클래스..

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

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

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

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

지난 1년 간 스프링을 공부하고 안드로이드 앱 개발 프로젝트를 하면서 dependency(의존성)을 관리하는 것이 굉장히 중요하다는 이야기를 계속해서 접했고 공부했습니다. Spring boot 에서 bean 과 @Autowired 라는 어노테이션을 통해 의존성을 주입하고, 안드로이드 코트린에서는 hilt 라는 의존성 관리 라이브러리를 사용하여 의존성을 관리했습니다. 이 의존성은 결국 객체지향의 핵심일 것이다. 실무적인 관점에서 의존성을 공부하고 다루어 보니 객체지향을 더 깊게 공부해야 할 때가 온 것 같습니다. 그래서 '오브젝트 : 코드로 이해하는 객체지향 설계 - 조영호' 책을 읽으면서 정리해보고자 합니다. 책의 머릿말에서 이 책은 실무 경험이 있으며 설계에 대한 고민을 충분히 한 사람들이 읽으면 좋을..