본문 바로가기

전체 글

 (32)
09) 유연한 설계 1. 개방-폐쇄 원칙(OCP) OCP란 확장에는 열려있어야 하고 수정에는 닫혀있어야 한다는 원칙이다. 이전 장에서의 영화예매와 할인정책에서 알 수 있다. 만약 중복할인이라는 기능을 추가하면 기존코드를 손대지 않은 채 정상적으로 작동한다. 이에 따라 애플리케이션의 동작을 확장했다. 따라서 '확장에는 열려있다'. 또한 기존 코드를 수정없이 새로운 클래스(중복할인)를 추가하는 것만으로 할인 정책을 확장하였으므로 '수정에는 닫혀 있다'. 의존성 관점에서 개방-폐쇄 원칙을 따르는 설계란 컴파일타임 의존성은 유지하면서 런타임 의존성의 가능성을 확장하고 수정할 수 있는 구조라고 할 수 있다. 개방-폐쇄 원칙의 핵심은 추상화에 의존하는 것이다. 2. 생성 사용 분리 결합도가 높아질수록 OCP를 따르는 구조를 설계하기가..
08) 의존성 관리하기 1. 의존성 어떤 객체가 예정된 작업을 정상적으로 수행하기 위해 다른 객체를 필요로 하는 경우 두 객체 사이에 의존성이 존재한다고 말한다. 의존성은 변경에 의한 영향의 전파 가능성을 암시한다. 협력을 위해서는 의존성이 필요하지만 과도한 의존성은 애플리케이션을 수정하기 어렵게 만든다. 객체지향 설계의 핵심은 협력을 위해 필요한 의존성은 유지하면서도 변경을 방해하는 의존성은 제거하는데 있다. 1.1 의존성 전이 영화예매에서의 코드를 떠올려보자. 만약 할인조건이 예매에 의존할경우 할인조건은 예매가 의존하는 대상에 대해서도 자동적으로 의존하게 된다. 다시 말해 예매에 영화정보, 날짜, 고객수가 의존할 경우 할인조건 역시 간접적으로 영화정보, 날짜, 고객수에 의존하게 된다. 할인조건 ---> 예매 ----> 영화..
07) 객체 분해 1. 추상화 불필요한 정보를 제거하고 현재의 문제 해결에 필요한 핵심만 남기는 작업을 추상화라고 한다. 가장 일반적인 추상화 방법은 한 번에 다뤄야 하는 문제의 크기를 줄이는 것이다. 프로그래밍 패러다임은 프로그래밍을 구성하기 위해 사용하는 추상화의 종류와 이 추상화를 이용해 소프트웨어를 분해하는 방법의 두 가지 요소로 결정된다. 따라서 모든 프로그래밍 패러다임은 추상화와 분해의 관점에서 설명할 수 있다. 현대적인 프로그래밍 언어를 특징짓는 추상화 메커니즘으로 두 가지가 있다. 프로시저 추상화 : 소프트웨어가 무엇을 해야 하는지를 추상화 기능분해, 알고리즘 분해 데이터 추상화 : 소프트웨어가 무엇을 알아야 하는지를 추상화 데이터를 중심으로 타입을 추상화 - 추상 데이터 타입 데이터를 중심으로 프로시저를 ..
06) 메시지와 인터페이스 훌륭한 객체지향 코드를 얻기 위해서는 클래스가 아니라 객체를 지향해야 한다. 즉 협력 안에서 객체가 수행하는 책임에 초점을 맞춰야 한다. 여기서 중요한 것은 책임이 객체가 수신할 수 있는 메시지의 기반이 된다는 것이다. 1. 협력과 메시지 1.1 클라이언트-서버 모델 협력은 어떤 객체가 다른 객체에게 무언가를 요청할 때 시작된다. 메시지는 객체 사이의 협력을 가능하게 하는 유일한 매개체다. 두 객체 사이의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포는 클라이언트-서버 모델이다. 협력 안에서 메시지를 전송하는 객체를 클라이언트, 메시지를 수신하는 객체를 서버라고 부른다. 가격을 계산하라(메시지) ---> Screening(클라이언트) --------------------------> Movie(서버)
05) 책임 할당하기 1. 책임 주도 설계 데이터보다 행동을 먼저 결정해라 협력이라는 문맥 안에서 책임을 결정해라 1.1 데이터보다 행동을 먼저 결정하라 물론 나도 그렇듯 객체지향에 갓 입문한 사람들은 객체의 행동이 아니라 데이터에 초점을 맞추는 실수를 한다. 하지만 책임 중심의 설계에서는 객체가 수행해야 하는 책임이 무엇인지 결정한 후 이 책임을 수행하는데 필요한 데이터는 무엇인지 결정한다. 다시 말해 책임 중심의 설계에서는 객체의 행동, 즉 책임을 먼저 결정한 후에 객체의 상태를 결정하는 것이다. 1.2 협력이라는 문맥 안에서 책임을 결정하라 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다. 이전에 메시지를 통해서 협력하는 것을 알아보았다. 이 메시지를 전송하는 전송자의 의도에 적합한 책임을 할당해야 한..
04) 설계 품질과 트레이드오프 이번 장에서는 데이터 중심의 설계를 살펴보고 객체지향 설계와 비교하면서 좋은 설계, 나쁜 설계에 대해 또렷하게 배워보는 시간이였다. 이전 장에서 배웠던 내용을 떠올려보자. 객체지향 설계의 핵심은 역할, 책임, 협력이다. 협력은 애플리케이션의 기능을 구현하기 위해 메시지를 주고받는 객체들 사이의 상호작용이다. 책임은 객체가 다른 객체와 협력하기 위해 수행하는 행동이고, 역할은 대체 가능한 책임의 집합이다. 책임은 객체지향 애플리케이션 전체의 품질을 결정한다. 객체지향 설계란 올바른 객체에게 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 만드는 활동이다. 이를 합리적인 수준으로 유지할 수 있는 중요한 원칙은 객체의 상태가 아니라 객체의 행동에 초점을 맞추는 것이다. 응집도 모듈에 포함된 배우 요소들이..
03) 이벤트 조회 및 수정 REST API 개발 1. ErrorsResource, InvalidDefinitionException 에러가 발생하면 메인페이지로 돌아가게 할 수 있도록 index 링크 정보를 전달하려고 한다. 현재는 에러만 넘겨주는 상태에서 ErrorsResource를 만들어서 링크의 정보도 같이 넘겨주려고 한다. @PostMapping public ResponseEntity createEvent(@RequestBody @Valid EventDto eventDto, Errors errors) { if (errors.hasErrors()) { return ResponseEntity.badRequest().body(errors.getAllErrors()); } eventValidator.validate(eventDto, errors); if..
03) 역할, 책임, 협력 1. 협력 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 의미한다. 2장에서 언급했듯이 객체지향 시스템은 자율적인 객체들의 공동체다. 메시지 전송은 객체 사이의 도움을 요청하는 커뮤니케이션 수단이다. 메시지를 수신한 객체는 스스로 어떻게 처리할지는 직접 결정한다. 이것은 객체가 자신의 일을 스스로 처리할 수 있는 자율적인 존재라는 것을 의미한다. 레이싱 경주를 떠올려보자 Race는 각 차량에 대한 정보를 알지 못한다. 차량의 정보와 얼마나 움직일 수 있는지 등 차량에 관련된 정보는 Car객체가 잘 알고 있으므로 메시지를 통해 자신의 일을 위임한다. 자신이 할 수 없는 일을 다른 객체에게 위임하면 협력에 참여하는 객체들의 전체적인 자율성을 향상할 수 있다. 2. 책임 객체가 협력에 참여하..

티스토리툴바