# 객체지양 설계 내 상호 연관 관점 ## 개념 관점 설계는 도메인 안에서 존재하는 개념과 개념들 사이 관계를 표현 실제 도메인의 규칙 및 제약을 최대한 유사하게 반영 ## 명세 관점 사용자의 영역인 도메인을 벗어나 개발자의 영역인 SW에 초점이 옮겨짐 도메인에서 벗어나 실제 SW안에서 살아 숨쉬는 객체들의 책임에 초점 즉, 인터페이스를 바라봄 '무엇'을 할 수 있는가에 초점 ## 구현 관점 실제 작업을 수행하는 코드와 연관 객체들의 책임을 수행하는 데 필요한 동작하는 코드를 작성 '어떻게' 수행할 것인가에 초점 구현하지 않고 머리속으로만 구상한 설계는 코드로 구현하는 단계에서 대부분 변경됨. 설계 작업은 구현을 위한 스케치 를 작성하는 단계지 구현 그 자체일 수 없음. 중요한 것은 설계가 아니라 코드...

기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적 # 기능 설계 VS 구조 설계 기능 설계 : 제품이 사용자를 위해 무엇을 할 수 있는가 구조 설계 : 제품의 형태가 어떠해야 하는가 훌륭한 기능은 충분조건, 훌륭한 구조는 필요조건 우리는 미래를 예측할 수 없다, 단지 대비할 수 있을 뿐 훌륭한 SW는 좋은 기능을 제공하면서 변경에 유연 좋은 설계는 병결할 수 있는 여지를 남겨 놓는 설계 변경의 여지를 남겨 놓는 가장 좋은 방법은 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하는 것 # 객체지향 설계 기법 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현 : 도메인 모델링 기능은 사용자의 목표를 만족시키기 위해..

각 객체는 책임이 명확하게 주어지는 경우에 행동함 객체지향 공동체를 구성하는 기본 단위는 자율적인 객체임 객체에게 할당되는 책임 수준는 자율적이어야 - 너무 추상적인 책임도 무조건 좋은 것은 아님 자율적 챔임의 특징은 객체가 어떻게(how) 해야 하는가가 아니라 무엇(what)을 해야하는가를 설명하는 것 # 메시지 : 무엇(What) 하나의 객체는 메시지를 전송함으로써 다른 객체에 접근 추가적인 정보가 필요한 경우 메시지의 인자를 통해 추가 정보 제공 # 메서드 : 어떻게(How) 메시지를 처리하기 위해 내부적으로 선택하는 방법 # 다형성 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응하는 것 다형성은 메시지 송신자의 관점에서 동일한 역할을 수행하는 다양한 타입의 객체와 협력할 수 있게 ..

객체지향 페러다임의 목적은 현실 세계를 모방하는 것이 아니라 현실 세계를 기반으로 새로운 세계를 창조하는 것 - 행동에 따라 상태가 변함 - 상태를 결정하는 것은 행동, 행동의 결과를 결정하는 것은 상태 # 갹체의 특징 - 상태를 가지며 상태는 변경 가능함 - 상태를 변경시키는 것은 행동임 --행동의 결과는 상태 의존적, 상태를 이용해 서술 가능 --행동의 순서가 결과에 영향을 미침 - 객체는 어떤 상태에 있더라도 유일하게 식별 가능 ## 상태(state, property) 상태를 이용하면 현재를 기반으로 객체의 행동 방식을 이해할 수 있음 근본적으로 세상의 복잡성을 완화, 인지 과부하를 줄일 수 있음 - 모든 객체의 상태는 단순한 값과 객체의 조합으로 표현 가능 - 링크 : 객체와 객체 사이의 의미 있..