00. 선요약 SW 설계에서 절대적인 것은 없다. 모든 결정은 경우에 따라 이루어져야 한다. 01. 협력과 메시지 클라이언트-서버 모델 클라이언트-서버 모델은 두 객체 사이의 협력관계를 설명하기 위해 사용되는 전통적인 메타포 이다. 메시지를 전송하는 객체가 클라이언트 역할, 메시지를 수신하는 객체가 서버 역할을 한다. 그리고 협력 안에서 객체는 클라이언트 역할과 서버 역할을 동시에 수행한다. 메시지와 메시지 전송 메시지는 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단이다. 한 객체가 다른 객체에게 도움을 요청하는 것을 메시지 전송(message sending) 또는 메시지 패싱(message passing)이라 부른다. 메시지는 오퍼레이션명과 인자로 구성되며 메시지 전송은 여기에 메시지 전..
책임에 초점을 맞춰야 한다!!! 하지만 이때 우리가 마주하는 문제점은 어떤 객체에게 어떤 책임을 할당할 지 결정하기가 쉽지 않다는 것이다. 이번 장에선 GRASP패턴을 통해 응집도와 결합도, 캡슐화와 같은 다양한 기준에 따라 책임을 분배하고 결과를 트레이드오프할 수 있는 기준을 배운다. 00. 선요약 01. 책임 주도 설계를 향해 책임주도 설계를 위해 지켜야 할 두 가지 원칙 데이터보다 행동을 먼저 결정하라 협력이라는 문맥 안에서 책임을 결정하라 데이터보다 행동을 먼저 결정하라 앞서 데이터 중심 설걔를 했을 때 했던 질문의 순서를 바꿔야한다 이 객체가 수행해야 하는 책임은 무엇인가? 이 책임을 수행하는 데 필요한 데이터는 무엇인가? 즉 책임 중심의 설계에서는 객체의 행동(책임)을 먼저 결정한 후 객체의 ..
설계는 변경을 위해 존재하고 변경에는 어떤 식으로든 비용이 발생한다. 훌륭한 설계를 하면 합리적 비용 안에서 변경을 수용할 수 있는 구조를 만들 수 있다. 00. 선요약 객체지향 설계란 올바른 객체에 올바른 책임을 할당하면서 낮은 결합도와 높은 응집도를 가진 구조를 창조하는 활동. 객체의 상태가 아니라 행동에 초점을 맞추면 결합도와 응집도를 합리적 수준으로 유지할 수 있다. 캡슐화란 변경 가능성이 높은 부분을 내부로 숨기는 추상화 기법. 변경될 수 있는 것은 모두 캡슐화 해야 한다. 01. 데이터 중심의 영화 예매 시스템 객체의 상태는 구현에 속한다. 구현은 불안정하기 때문에 변하기 쉽다. (인터페이스, 추상클래스와 이것들을 일반화한 클래스, 확장한 클래스를 생각하면 이해가 갈 것임.) 상태를 중심으로 ..
00. 선요약 객체지향 패러다임의 관점에서 핵심은 역할(role), 책임(responsibility), 협력(collaboration) 2장에서 알아본 다양한 기술적 매커니즘이 모여 유연하고 재사용 가능한 협력을 만들 수 있는 기반을 제공한다. 객체는 상태와 행동을 함께 캡슐화 하는 실행단위. 객체의 상태와 행동은 객체가 참여하고 있는 협력을 통해 정함. 다양한 객체들이 특정 기능을 구현하기 위해 메시지를 주고받으며 상호작용을 하는 것을 협력이라 함. 객체가 협력에 참여하기 위해 수행하는 로직은 책임이라 부르고 객체들이 협력 안에서 수행하는 책임들이 모여 객체가 수행하는 역할을 구성 함. 01. 협력 요구사항을 구현해 기능을 제공하기 위해선 다양한 객체들이 참여하는 협력을 구축해야 함. 객체지향 원칙을 ..
Serializer 하나 변경하는게 이렇게 큰 결과를 불러올 줄이야... Refactoring의 일환으로 패키지를 변경했다가 Redis 관련 에러가 났고 이를 해결한 경험을 적어놓는다. Redis Serializer redis 는 data를 byte array 형태로 저장한다. spring data redis에서는 user - redis 사이 데이터를 변환할 수 있도록 여러 serializer들을 제공 하고 있다.(참고 사이트) 상황 팀원 중 한 명이 기존 서비스 legacy 코드가 보기가 어려워 한번 정리 하는 셈 치고 패키지들을 변경 시켰다. 나도 리뷰 할 때 '패키지 위치만 변경 한거면 intellij에서 refactoring 잘 해주겠지' 생각에 빌드 잘 되고 테스트 통과한 것만 보..
요새 '오브젝트'라는 책을 다시 보고 있는데, 응집도와 결합도에 관한 내용이 나온다. 대강 LOW COUPLING(낮은 결합도)와 HIGH COHESION(높은 응집도)를 고려해 가며 설계를 하면 변경에 유연한 설계를 할 수 있다는 내용 이었다. 글로는 잘 이해 했다 생각했지만 실제로 어떻게 적용해볼까 고민이 있었는데, 마침 적절한 경험을 한 것 같아서 기록해두려 한다. 예시 상담신청이라는 도메인이 있고, 이번에 타임세일이라는 도메인을 추가하게 되었다. 유저는 상담신청을 할 수 있고, 타임세일을 통해 은 특정 시간에 싼 가격으로 상담신청을 할 수도 있다. @Entity public class Consultation { @Id Long id; ... @ManyToOne @JoinColumn(name = "..
ObjectMapper 설정 Spring에서 설정 모르는 필드에 대해서 Deserialize 할 때 무시하도록 설정을 했어야 했다. 인터넷 글을 검색해가며 ObjectMapper의 Global 설정 방법을 찾아봤지만 막상 적용했을 때 제대로 동작하는게 없었다. SpringBoot를 주로 사용했어서 xml로 bean을 설정하는 방법에 익숙하지 않아서 많이 헤맸었다. 옆에 계신 분의 도움으로 설정할 수 있었다. 설정 파일을 보면 이렇게 ObjectMapper 관련 설정이 HibernateAwareObjectMapper에 있는 것을 알 수 있었고, public class HibernateAwareObjectMapper extends ObjectMapper { private static final long se..
shell script를 kill 할 때 하던 작업을 모두 완료한 후 process를 죽여야 했다. 지금까진 그냥 kill을 했었는데 중간에 kill 하면 데이터가 유실되는 상황 이 있었고 그게 문제가 되었다. 해결법을 이리 저리 찾아보다 적절한 방법을 찾게되어 기록한다. 해결방법 일정 count 만큼 loop를 돌면 shell이 재실행 되지만 그 때까지 마냥 기다릴 순 없었다. 처음엔 shell이 작업하지 않는 타이밍을 찾으려 했다. 하지만 정확한 시점을 찾기가 어려워 보였다. 강제로 종료하는 것이 아니고 작업을 모두 마치고 종료하는 방법이 뭐가 있을까 고민하다 문득 어디에선가 ‘graceful shutdown’이라는 로그를 본 기억이 났다. shell script graceful shutdown 이라..
- Total
- Today
- Yesterday