객체지향의 사실과 오해(6)

p.178

• 길을 직접 알려주는 방법이 기능적이고 해결 방법 지향적인 접근법이라면 지도를 이용하는 방법은 구조적이고 문제 지향적인 접근법이다.

p.180

• 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이다.
• 기능을 중심으로 구조를 종속시키는 접근법은 범용적이지 않고 재사용이 불가능하며 변경에 취약한 모델을 낳게 된다. 이와 달리 안정적인 구조를 중심으로 기능을 종속시키는 접근법은 범용적이고 재사용이 가능하며 변경에 유연하게 대처할 수 있는 모델을 만든다.
• 객체지향은 자주 변경되는 기능이 아니라 안정적인 구조를 기반으로 시스템을 구조화한다.
• 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라.

p.181

• 소프트웨어를 개발하는 초기 단계에서는 사용자가 무엇을 원하는지, 그리고 사용자가 원하는 것을 만족시키기 위해 시스템이 어떤 기능을 제공해야 하는지에 초점을 맞춰야 한다.
• 성공적인 소프트웨어들이 지닌 공통적인 특징은 훌륭한 기능을 제공하는 동시에 사용자가 원하는 새로운 기능을 빠르고 안정적으로 추가할 수 있다는 것이다.

p.182

• 소프트웨어 분야에서 예외가 없는 유일한 규칙은 요구사항이 항상 변경된다는 것이다. 설계라는 행위를 중요하게 만드는 것은 변경에 대한 필요성이다.
• 설계가 어려운 이유는 어제 약속했던 기능을 제공하는 동시에 내일 변경될지도 모르는 요구사항도 수용할 수 있는 코드를 창조해야 하기 때문이다.
• 불확실한 미래의 변경을 예측하고 이를 성급하게 설계에 반영하는 것은 불필요하게 복잡한 설계를 낳을 뿐이다.
• 미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.
• 좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계다.

p.183

• 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계
• 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.
• 안정적인 객체 구조는 변경을 수용할 수 있는 유영ㄴ한 소프트웨어를 만들 수 있는 기반을 제공한다.

p.184

• 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현한다.
• 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위를 표현한다.

p.185

• 도메인 모델에서 모델이란 대상을 단순화해서 표현한 것이다. 추상화하고 단순화한 것
• 도메인 모델이란 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다. 도메인 모델은 소프트웨어 개발과 관련된 이해관계자들이 도메인에 대해 생각하는 관점이다.

p.186

• 설계자는 디자인 모델을 기반으로 만든 시스템 이미지가 사용자 모델을 정확하게 반영하도록 노력해야 한다.

p.187

• 도메인 모델은 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지를 포괄하도록 추상화한 소프트웨어 모델이다.
• 도메인 모델이란 사용자들이 도메인을 바라보는 관점이며, 설계자가 시스템의 구조를 바로보는 관점인 동시에 소프트웨어 안에 구현된 코드의 모습 그 자체이다.

p.188

• 소프트웨어 객체는 현실 객체에 대한 추상화가 아니다. 소프트웨어 객체와 현실 객체 사이의 관계를 가장 효과적으로 표현할 수 있는 단어는 바로 은유이며 은유를 기반으로 재창조한 것이다.
• 은유를 통해 현실 객체와 소프트웨어 객체 사이의 차이를 최대한 줄이는 것이다.

p.189

• 소프트웨어를 이해하고 수정하기 쉽게 만들어주기 때문에 표현적 차이가 중요하다.
• 도메인 모델이 제공하는 구조가 상대적으로 안정적이기 때문에 도메인 모델을 기반으로 코드를 작성한다.
• 도메인 모델의 핵심은 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현하는 것이다.
• 사용자 모델에 포함된 개념과 규칙은 비교적 변경될 확률이 적기 때문에 사용자 모델을 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있을 가능성이 커진다.

p.192

• 기능적 요구사항이란 시스템이 사용자에게 제공해야 하는 기능의 목록을 정리한 것이다.
• 목표를 가진 사용자와 사용자의 목표를 만족시키기 위해 일련의 절차를 수행하는 시스템 간의 상호작용 관점에서 시스템을 ㅂ라라봐야 한다.

p.193

• 산발적으로 흩어져 있는 기능에 사용자 목표라는 문맥을 제공함으로써 각 기능이 유기적인 관계를 지닌 체계를 이룰 수 있게 한다.

p.194~p.195

• 유스케이스의 특성
  • 유스케이스는 사용자와 시스템간의 상호작용을 보여주는 텍스트다. 다이어그램에 노력을 쏟지 말라. 중요한 것은 유스케이스에 담겨있는 이야기이다.
  • 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
  • 유스케이스는 단순한 피처 목록과 다르다. 피처는 시스템이 수행해야 하는 기능의 목록을 단순하게 나열한 것이다. 유스케이스가 단순히 기능을 나열하는 것이 아니라 이야기를 통해 연관된 기능들을 함께 묶을 수 있다는 점이 강점이다.
  • 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
  • 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.

p.196

• 유스케이스가 단지 사용자가 바라보는 시스템의 외부 관점만을 표현한다는 점에 주목하라.
• 단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리 기법일 뿐이다.
• 유스케이스를 기반으로 객체의 구조를 쉽게 추출할 수 있다는 어설픈 설명에 속지마라. 유스케이스는 객체의 구조나 책임에 대한 어떤 정보도 제공하지 않는다.
• 유스케이스 안에 도메인 모델을 구축할 수 있는 모든 정보가 포함돼 있다는 착각에 빠지기 말기 바란다. 유스케이스 안에는 영감을 불러일으킬 수 있는 약간의 힌트만이 들어 있을 뿐이다.

p.197

• 불안정한 기능을 안정적인 구조 안에 담음으로써 변경에 대한 파금효과를 최소화하는 것은 훌륭한 객체지향 설계자가 갖춰야 할 기본적인 설계 능력이다.
• 변경에 유연한 소프트웨어를 만들기 위해서는 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 한다.
• 시스템이라는 객체 안에는 더 작은 규모의 객체가 포함될 수 있다. 이제 시스템이 수행해야 하는 커다란 규모의 책임은 시스템 안에 살아가는 더 작은 크기의 객체들의 협력을 통해 구현될 수 있다.

p.199

• 요구사항들을 식별하고 도메인 모델을 생성한 후, 소프트웨어 클래스에 메서드를 추가하고, 요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하라.
• 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점을 제공한다.
• 책임주도 설계 방법은 시스템의 기능을 역할과 책임을 수행하는 객체들의 협력 관계로 바라보게 함으로써 두 가지 기본 재료인 유스케이스와 도메인 모델을 통합한다.
• 견고한 객체지향 애플리케이션을 개발하기 위해서는 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다는 것이다.

p.202

• 책임 할당의 기본 원칙은 책임을 수행하는 데 필요한 정보를 가진 객체에게 그 책임을 할당하는 것이기 때문이다. 이것은 관련된 상태와 행동을 함께 캡슐화하는 자율적인 객체를 낳는다.
• 시스템을 자율적인 객체로 바라보고 더 작은 객체로 분할하는 방식의 장점

p.203

• 도메인 모델을 구성하는 이유는 안정적이며 다음과 같은 특징을 갖기 때문이다.
  • 도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다.
  • 도메인 모델을 구성하는 개념 간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다.
• 비즈니스 정책이나 규칙이 크게 변경되지 않는 한 시스템의 기능이 변경되더라도 객체 간의 관계는 일정하게 유지된다.

p.205

• 기능이 변경되거나 추가돼도 대부분의 클래스 구조가 그대로 유지되는 이유는 도메인을 구성하는 기본적인 개념과 관계를 포함하는 도메인 모델을 기반으로 시스템의 기능을 대응시켰기 때문이다.
• 안정적인 도메인 모델을 기반으로 시스템의 기능을 구현할 경우 시스템의 기능이 변경되더라도 비즈니스의 핵심 정책이나 규칙이 변경되지 않는 한 전체적인 구조가 한 번에 흔들리지 않는다.
• 객체지향의 가장 큰 장점은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 기법이 동일하다는 점이다. 따라서 도메인 모델링에서 사용한 객체와 개념을 프로그래밍 설계에서 객체와 클래스로 매끄럽게 변환할 수 있다. (연결완전성)
• 객체지향이 강력한 이유는 연결완전성의 역방향 엿시 성립한다는 것이다. 즉, 코드의 변경으로부터 도메인 모델의 변경 사항을 유추할 수 있다.
• 도메인 모델이 코드와 분리된 별도의 산출물이 아니라는 점에 유의하라.

p.206

• 도메인 모델은 문서나 다이어그램이 아니다. 도메인 모델은 사람들의 머릿속에 들어있는 공유된 멘탈 모델이다.
• 사람들이 동일한 용어와 동일한 개념을 이용해 의사소통하고 코드로부터 도메인 모델을 유추할 수 있게 하는 것이 도메인 모델의 진정한 목표다.
• 안정적인 도메인 모델을 기반으로 시스템의 기능을 구현하라. 도메인 모델과 코드를 밀접하게 연관시키기 위해 노력하라. 그것이 유지보수하기 쉽고 유연한 객체지향 시스템을 만드는 첫걸음이 될 것이다.