데이터 중심 설계와 책임 중심 설계의 차이 객체를 단순한 데이터의 집합으로 바라보는 시각은 객체의 내부 구현을 퍼블릭 인터페이스에 노출시키는 결과를 낳는다. 결과적으로 설계가 객체들의 내부 구현 변경에 취약해진다. 데이터 중심 설계에서는 객체의 행위보다 상태를 우선 생각한다. 데이터 중심의 관점에서 객체는 자신의 데이터를 조작하는데 필요한 오퍼레이션을 정의한다. 데이터 중심 설계에서도 형식적인 데이터 캡슐화는 가능하다. 객체에서 스스로의 데이터는 private으로 숨기고 대신 접근자와 수정자(getter, setter)를 드러내는 것이다. 그러나 이는 public으로 드러낸 것과 마찬가지이며 진짜 캡슐화가 아니다. 모든 인스턴스 변수를 접근자로 드러내기 때문에 그러한 인스턴스 변수들의 정보를 퍼블릭 인터..
What? 이전에는 @Value 를 사용해 *.yml , *.properties 의 프로퍼티 값들을 가져왔습니다. 개인적으로는 기능에 문제가 없었기 때문에 개선의 필요성을 인지하지 못하고 있었는데, 지인분의 추천으로 @ConfigurationProperties 과 @ConstructorBinding 어노테이션을 알게 되어 공유합니다. Why? 기존의 문제점부터 짚고 넘어가겠습니다. 아래와 같은 yml이 있다고 가정합니다. server: port: 8080 domain: http://localhost:8080 동적 타입 문제 @Value("${server.port}") private String stringPort; @Value("${server.port}") private Integer integerPo..
객체지향 패러다임의 핵심은 역할, 책임, 협력이다. 협력 : 애플리케이션의 기능을 구현하기 위해 객체들이 수행하는 상호작용 책임 : 협력에 참여하기 위해 객체가 수행하는 로직 역할 : 객체가 수행하는 책임들이 모여 구성된 것 협력은 객체지향의 세계에서 기능을 구현할 수 있는 유일한 방법이다. 두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 메시지 전송은 객체 사이의 협력을 위해 사용할 수 있는 유일한 커뮤니케이션 수단이다. 결과적으로 객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 캡슐화하는 것이다. 캡슐화를 통해 변경에 대한 파급 효과를 제한할 수 있다. 그렇기 때문에 자율적인 객체는 변경하기 쉬워진다. 만약 Movie가 캡슐화를 하지 않는다면, 내부 구현을 ..
객체와 객체 지향 진정한 객체지향 패러다임으로의 전환은 클래스가 아닌 객체에 초점을 맞출 때에만 얻을 수 있다. 첫째, 클래스 이전에 어떤 객체들이 필요한지 고민하라. 클래스의 윤곽을 잡기 위해선 어떤 객체들이 어떤 상태와 행동을 가지는지 먼저 결정해야 한다. 둘째, 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야 한다. …이것은 설계를 유연하고 확장 가능하게 만든다. 프로그램이 사용되는 분야를 도메인이라고 부른다. 객체지향 패러다임이 강력한 이유는 요구사항 분석 단계부터 프로그램 구현 단계까지 객체라는 동일한 추상화 기법을 사용할 수 있기 때문이다. 인터페이스와 구현의 분리 클래스의 내부와 외부를 구분해야 하는 이유는 무엇일까? 경계의 명확성이 객체의 자율성을 보장하..
초심은 참 지키기 어렵다. 대학교에서 c언어를 배울 때만 해도 초심이 있었다고 생각한다. 포인터가 어떻게 동작하고, 컴퓨터에 데이터가 어떤 식으로 저장되는지 호기심을 갖고 공부할 때가 있었다. 포인터의 크기가 64 비트 os상에서 8바이트라는건 아직도 바로 기억이 난다. 데이터구조, 알고리즘 등도 비슷했다. 원리에 대해서 나 스스로 곱씹어보고 호기심을 해결해나갈 때 기분이 좋았다. 그러나 백엔드 프로젝트를 해가면서 조금씩 초심이 무너졌다. 정확히 말하자면 나의 게으름이 그 원인이다. 프로젝트를 처음 할 때만 해도, 김영한님의 강의들을 보고 토이프로젝트를 만들어보면서 호기심을 하나 하나 풀어갔다. 스프링은 어떻게 요청을 받고 어떻게 응답을 처리하는지, 스프링은 DB와 커넥션을 어떻게 만드는지 찾아봤었다. ..
‘오브젝트: 코드로 이해하는 객체지향 설계’를 읽고 공부한 내용입니다. 공부하며 작성한 내용이기 때문에 오류 사항이 있을 수 있습니다. 잘못된 부분은 피드백 부탁드립니다. 1장 내용 의존성 : 다른 객체 내부를 알면 알수록 변경에 취약해진다 초기의 코드는 Theater (극장) 객체에서 관객, 관객의 가방, 초대장, 티켓, 티켓 판매원, 티켓 판매소를 알고 있는 상태입니다. 그리고 티켓 구매 로직까지 모두 책임지고 있습니다. 전형적인 절차지향적 프로그래밍이라고 할 수 있습니다. public class Theater { private TicketSeller ticketSeller; public Theater(TicketSeller ticketSeller) { this.ticketSeller = ticket..
2023년은 작년보다 조금 더 바쁘게 지내며 크고 작은 결실을 맺은 해였다. 요약하자면, 스프링 백엔드 개발자가 되기 위해 노력한 해이다. 스프링 전향, 공부 시작 올해 1월부터는 자바 스프링 백엔드 개발이 유망하다고 생각해 스프링으로 전향하게 되었다. 김영한님 강의를 들으며 공부했다. 아무래도 이전에 django, node.js 프로젝트를 했어서인지 전반적인 흐름을 빠르게 파악할 수 있었다. 가장 어려웠던건 IoC, DI 등 객체지향 언어의 프레임워크로써 갖는 스프링의 특징들이었다. 솔직히 OOP도 감으로만 익힌 상태였어서, 이것들이 왜 필요하고 어떻게 동작하는지 바로 이해하기 힘들었던 것 같다. 이때 크게 느낀게, 나는 이론만 공부하는 것보다는 구현하면서 부딪혀보면서 빠르게 배우는 타입이라는 점. 올..
💡 발단 아침에 일어나자마자 섬뜩한 슬랙 알림을 보게됐다. EC2 CloudWatch를 확인해보니 CPU 사용률이 99%를 찍고 사실상 중지된 모습. DB 커넥션은 급락했다. 서버가 정상 작동하지 않는다는 간접적인 신호인 것으로 파악했다. 원인 파악 시나리오 1 : 누군가의 무분별한 요청 ❌ 몇주동안 잘 작동하고 있었기 때문에 외부 변수부터 찾으려고 했다. CloudWatch에서 서버 요청 로그를 확인했다. 무분별한 해외 IP 요청 때문에 스레드 풀이 초과됐다는 레퍼런스를 봤었기 때문이다. https://mopil.tistory.com/128 아래는 서버가 죽을 당시의 로그 기록. 확인해보니 헬스 체크 컨트롤러로 계속해서 요청이 들어오고 있었다. 그런데 이게 의문사의 원인이라고는 생각하지 않는다. 해외 ..
