내용 요약객체가 수신하는 메시지들이 객체의 퍼블릭 인터페이스를 구성한다.훌륭한 퍼블릭 인터페이스를 얻기 위해서는 책임 주도 설계 바업을 따르는 것만으로는 부족하다.유연하고 재사용 가능한 퍼블릭 인터페이스를 만드는 데 도움이 되는 설계 원칙과 기법을 익히고 적용해야 한다.이런 원칙과 기법들을 살펴보는 거이 이번 장의 주제다.클라이언트-서버 모델두 객체 사이의 협력 관계를 설명하기 위해 사용하는 전통적인 메타포는 클라이언트-서버(Client-Server)모델이다.협력 안에서 메시지를 전송하는 객체를 클라이언트, 메시지를 수신하는 객체를 서버라고 부른다. 협력은 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이다.메시지와 메시지 전송메시지(message)는 객체들이 협력하기 위해 사용할 수 있는 유일한 ..
내용 요약책임 할당을 위한 GRASP 패턴객체지향이 태어나고 성숙해가는 동안 많은 사람들이 다양한 책임 할당 기법을 고안했다.그중에서 대중적으로 가장 널리 알려진 것은 크레이그 라만(Craig Larman)이 패턴 형식으로 제안한 GRASP 패턴이다. GRASP는 “General Responsibility Assignment Software Pattern(일반적인 책임 할당을 위한 소프트웨어 패턴)”의 약자로 객체에게 책임을 할당할 때 지침으로 삼을 수 있는 원칙들의 집합을 패턴 형식으로 정리한 것이다.정보 전문가에게 책임을 할당하라책임 주도 설계의 방식의 첫 단계는 애플리케이션이 제공해야 하는 기능을 애플리케이션의 책임으로 생각하는 것이다.이 책임을 애플리케이션에 대해 전송된 메시지로 간주하고 이 메시..
내용 요약결합도와 응집도를 합리적인 수준으로 유지할 수 있는 중요한 원칙이 있다. 객체의 상태가 아니라 행동에 초점을 맞추는 것이다.객체를 단순한 데이터의 집합으로 바라보는 시각은 객체의 내부 구현을 퍼블릭 인터페이스에 노출시키는 결과를 낳기 때문에 결과적으로 설계가 변경에 취약해진다. 이런 문제를 피할 수 있는 가장 좋은 방법은 객체의 책임에 초점을 맞추는 것이다. 책임은 객체의 상태에서 행동으로, 나아가 객체와 객체 사이의 상호작용으로 설계 중심을 이동시키고, 결합도가 낮고 응집도가 높으며 구현을 효과적으로 캡슐화하는 객체들을 창조할 수 있는 기반을 제공한다.데이터 중심의 관점에서 객체는 자신이 포함하고 있는 데이터를 조작하는 데 필요한 오퍼레이션을 정의한다.책임 중심의 관점에서 객체는 다른 객체가 ..
문제상황전처리 서비스의 경우 모든 어플리케이션의 역할이 분리되어 안정성과 확장성을 향상 시켰다.각 역할은 간단하게 아래와 같다.API 서버에서 전처리 요청Batch 서버에서 이벤트 발행Worker(카프카) 서버에서 분석 수행요청부터 분석까지 API 서버만 사용하는 경우(동기)에는 모든 Trace Context가 이어져 추적이 가능하겠지만위 처럼 역할이 분리되고 있는 경우 생성된 요청에 대해서 Batch 서버는 API서버의 어떤 요청에 대한 이벤트 발행인지 알 방법이 없다.때문에 하나의 trace_id로 End to End에 대한 추적이 불가능한 상황이였다.Trace ContextDatadog에서 Trace를 남길 때, Trace Context라는 것을 기준으로 Trace를 전파하도록 되어있다.관련 문서 ..
데이터독 계정 생성로컬 환경 설정을 위해 데이터독 계정이 필요하다.데이터독 사이트를 통해 로그인해서 14일 Trial이 가능하다. Tip! 14일 사용이 완료된 경우 Region을 변경해서 다시 14일 사용이 가능하다. 데이터독 APM 수집 원리데이터독 APM 수집을 시각화 하면 아래와 같다.출처 : 데이터독 공식문서INSTRUMENTED APPICATION WITH DD-TRACE LIBRARY데이터독 TRACE 라이브러리(이 문서에서는 dd-java-agent.jar)와 함께 어플리케이션을 계측계측된 데이터를 데이터독 에이전트로 전송DATADOG-AGENT전송 받은 애플리케이션 계측 데이터를 DATADOG-BACKEND로 전달DATADOG-BACKEND에이전트가 수집한 데이터를 BACKEND에서 받아..
내용 요약객체지향 패러다임의 관점에서 핵심은 역할(role), 책임(responsibility), 협력(collaboration)이다.객체지향 설계의 핵심은 협력을 구성하기 위해 적절한 객체를 찾고 적절한 책임을 할당하는 과정에서 드러난다.클래스와 상속은 객체들의 책임과 협력이 어느 정도 자리를 잡은 후에 사용할 수 있는 구현 메커니즘일 뿐이다.애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할과 책임이 필요한지를 고민하지 않은 채 너무 이름 시기에 구현에 초점을 맞추는 것은 변경하기 어렵고 유연하지 못한 코드를 낳는 원인이 된다.협력객체지향 시스템은 자율적인 객체들의 공동체다.객체는 고립된 존재가 아니라 시스템의 기능이라는 더 큰 목표를 달성하기 위해 다른 객체와 협력하는 ..
내용 요약협력, 객체, 클래스객체지향은 객체를 지향하는 것이다. 객체지향 프로그램을 작성할 때 가장 먼저 고려하는 것은 무엇인가?클래스 기반의 객체지향 언어에 익숙한 사람이라면 가장 먼저 어떤 클래스(class)가 필요한지 고민할 것이다.대부분의 사람들은 클래스를 결정한 후에 클래스에 어떤 속성과 메서드가 필요한지 고민한다.안타깝게도 이것은 객체지향의 본질과는 거리가 멀다. 객체지향은 말 그대로 객체를 지향하는 것이다.진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다.이를 위해서는 프로그래밍하는 동안 다음의 두가지에 집중해야한다.어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지를 고민하라. 클래스는 공통적인 상태와 행동을 공유하는 객체를 추상화한 것..
내용 요약로버트 마틴은 소프트웨어 모듈이 가져야 하는 세 가지 기능에 관해 설명한다.여기서 모듈이란 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미한다.마틴에 따르면 모든 모듈은 제대로 실행돼야하고, 변경이 용이해야하며, 이해하기 쉬워야한다.이해 가능한 코드란 그 동작이 우리의 예상에서 크게 벗어나지 않는 코드다.현실에서는 관람객이 직접 자신의 가방에서 초대장을 꺼내 판매원에게 건넨다. 티켓을 구매하는 관람객은 가방 안에서 돈을 직접 꺼내 판매원에게 지불한다. 판매원은 매표소에 있는 티켓을 직접 꺼내 관람객에게서 직접 돈을 받아 매표소에 보관한다.변경에 취약한 코드는 많은 객체사이의 의존성(dependency)이 있는 코드다.의존성은 변경에 대한 영향을 암시한..
