아장아장거리면서 주책부리는 블로그

객체 지도는 우리가 만드는 객체들이 어떻게 협력하고, 서로간에 메시지를 전해줘야 할지 미리 생각해보는 시간을 만드는 것 같았다. 하나씩 빌드업을 해나가며, 도메인 모델을 만들어가는 과정이다. 사실 이게 역할, 협력, 메시지를 생각하기 전에 우리가 해야할 부분이 아닐까 싶은 생각이 든다. 객체는 협력한다. 객체는 역할을 가진다. 객체는 메시지를 주고 받는다. 객체는 기능을 수행한다. 이를 모두 담은 상태가 되기 위해 우리는 지도를 그린다고 생각한다. 내가 느끼는 방식대로 설명을 해보겠다. 지도에 땅을 그려야 한다 ➡️ 우리가 사용할 역할들이 뭐가 있을지 생각한다. 땅에 있는 길들을 만들어야 한다 ➡️ 역할간의 협력관계를 이어본다. 길들이 도로인지, 인도인지, 자전거 전용도로인지 정리해야 한다 ➡️ 협력관..

이전의 메시지에 대해서 조금 더 자세한 설명을 들을 수 있었다. 그리고, 내가 만든 코드들의 문제가 무엇인가를 생각해볼 수 있었다. 4장에서 내가 만든 코드의 구조를 생각해보았을 때, 결국 증인이 일을 하기 위해 받아야 할 메시지는 존재하지 않는다. 일을 '어떻게' 처리해야하는지 구조를 잡았지만, '무슨' 일을 해야할 지 처리하지 않은 것이다. 책의 예시를 들어보자. 재판관이 증인에게 어제 주방에서 본 것이 있는지 묻는다. 증인은 말을 하기도, 글로 쓰기도, 그림으로 그리기도 할 수 있다. 하지만 하는 말의 내용은 어제 주방에서 본 것들이다. 여기에서 내가 느낀 것은 2가지 이다. 재판관은 무슨 일을 해야 할지 이야기 해야 한다. 이를 위해서 증인은 그 당시 그 장소에 관해 할 이야기가 있는지 확인하고 ..

이번에는 책에서 실제로 디자인 패턴이라는 이야기도 나왔었다. 어떻게 보면 3장에서 추상화를 시키는데, 이를 통해 얻을 이점이 무엇인가를 생각할 수 있었다. 예시를 보자면, 앨리스의 법정 경험(?)이 있을 것 같다. 법정에서 재판장, 관리자, 증인의 역할을 하는 사람들이 존재한다. 이를 역할로 구분해보면 재판장은 관리자에게 다음 증인을 부러오라고 한다. 증인은 증인들중 다음 사람을 골라 불러온다. 증인은 재판장에게 증언을 한다. 재판장은 증인의 증언을 듣고 판단한다. 의 구조를 가진다. 나는 역할을 생각해서 이렇게 각자 하는 일들을 정했다면, 역할명의 인터페이스로 해당 메서드들을 만든다. 지금의 메서드는 void타입으로, 파라미터 없이 만들어둔 후에 객체간의 협력관계를 바탕으로 파라미터를 입력시키거나, 반..

제목에서 보았듯이, 읽자마자 어? 이거 어디서 봤는데? 하는 부분이 상당히 겹쳐있었다. 이전에 CS를 공부하면서, 팩토리 패턴에서 공부했던 내용과 상당히 겹치는 부분이 있다고 느꼈다. 뭐랄까, 팩토리 패턴이라는 하나의 정형화된 패턴을 구현하기 위해서 알아야 하는 추상화라는 부분을 다시 한번 공부한 것 같다는 느낌이 든다. 간단하게 읽은 부분을 스스로 곱씹어본 것을 정리해보았다. 추상화 같은 역할을 하는 객체들을 동일한 역할명으로 추상화를 시킬 수 있었다. 어떻게 보면, 여태까지 이야기하던 역할이라는 부분은 단순하게 보면 인터페이스로 만들 수 있다고 생각이 든다. 그래서, 인터페이스라는 역할을 클래스가 수행하게 되면 되는 것 아닐까 라는 생각이 든다. 이를 2주차를 리펙토링 하고, 3주차를 구현해보았다. ..

소스코드 : https://github.com/JangAJang/the-orient-of-Object-Orientation/tree/main/chapter2 딱 한줄로 2장의 소감을 말하자면, 1장에서 던진 추상적인 질문에 대해서 하나씩 자세한 예시를 들어주는 느낌이었다. 1장은 하나의 큰 화두를 던져준다면, 2장에서는 자세한 썰을 푸는 느낌이다. (진짜 고급진 단어만으로 글을 쓰고싶지만, 내 블로그는 그런 곳이 아니라고 생각된다 하핳) 일단 앨리스부터는, 조금 더 실제 실행시킬 수 있는 모양새의 프로젝트를 만들어보려고 노력했다. 객체지향 생활 체조?도 해보면서 객체지향적인, 클린한 코드 만들기를 습관화를 하려고 노력을 하는 중이다. 로마는 하루에 안만들어지니까, 일단은 뭐다? 앨리스라는 객체가 있다. ..

소스 코드 : https://github.com/JangAJang/the-orient-of-Object-Orientation/tree/feat/Chapter2 객체지향에서는 모든 객체를 위주로 일이 돌아간다는 이야기는 자주 들었다. 그러면 그 일이 어떻게 돌아가는지, 그리고 내가 만든 코드에서 어떻게 이루어져야 조금 더 객체지향적인 결과가 이루어질지 생각해보았다. 일단, 책에 적힌 이론들을 이해해보자. 객체지향 프로그래밍에서는 객체가 스스로 생각하고 결정하게하는, '캡슐화'가 이루어진다. 이를 통해 객체에 자율성이 부여된다. 이렇게 자율성이 있는 객체들이 협력하는 관계를 가지고, 이 관계 안에서 메시지로 소통을 한다. 객체 ---(협력이라는 관계)--- 객체 이 관계에서 각 객체는 메시지를 통해 소통한다..

어제부터 '객체지향의 사실과 오해' 에 관해 동기들끼리 스터디를 하기로 했다. 그 전에 잡담을 하면서 서로의 코드를 리뷰해보고 있었는데( 이거 말고도 보통의 남자들끼리 모이면 하는 그런 이야기도 많이 한다.) 로그인을 위한 validate로직을 보면서, 왜 이렇게 만들었으며 더 나아가 getter를 지양하는게 어떤 방향인지 이야기하게 되어 정리해보려고 한다. 물론 내 코드도 정답은 아니고, 어쩌면 오답에 더 가까운 코드일 수 있다. 하지만, 그런 부분을 짚어주면서 보는 사람이 있다면 나는 이 글을 통해 더 공부하는 거니까 정확한 당시 동기의 코드를 가져오진 않았지만, 당시에 기억나는 대로 똑같이 작성해보았다. 이 부분에 대해서 더 많은 예시와 설명을 위해 대략 20~30분 정도를 사용했던 것 같다. 사실..

2023년 1학기 캡스톤 디자인 프로젝트를 하면서, 다른 동기가 있는 조에서 dto마다 인스턴스들을 초기화시키는 생성자가 있어야 하는 이유는 너무 당연한데, 도대체 인스턴스 없이 만드는, NoArgsConstructor가 왜 존재해야 하는가를 궁금해했던 적이 있었다. 우리 조원들에게도 그 부분에 대해 알까 싶어 물어봤지만, 모른다는 이야기를 들었다. 그래서 이에 대해 정리를 해보려고 한다. 일단, JPA의 특성중에 프록시와 지연로딩에 대해서 먼저 알고오면 쉽다. 프록시는 엔티티를 상속받아 정의된다. 프록시에서는 실제 엔티티와 같은 인스턴스들이 초기화되지 않고 만들어지게 된다. 인스턴스 없는 생성자가 무엇일까? 그게 NoArgsConstructor이다!!!(이렇게 블로그 내용 돌려막다 보면 언젠가는 링크만..

캡스톤을 하다가, 한 동기가 질문했던 부분을 블로그에 남겨보기로 했다. 일단 받은 질문을 간단하게 요약하자면, 스프링은 자바로 동작한다. 자바에서는 에러가 발생하면, RuntimeException(이놈 말고도, IllegalArgumentException처럼 extends RuntimeException을 받는 녀석들이 있다)으로 발생하는 예외들은 분명 러닝과정에서 빨갛게 예외가 발생했다고 뜬다. 근데 이렇게, Response를 이용해 Exception에 대해 뭐시기를 해주는게 의미가 있는가? 였다. 일단, 이러한 유튭..아니 블로그각을 만들어준 동기에게 감사하고 정리를 조금 해봐야겠다. 테스트를 위해 하나의 예외를 집어넣어 실행을 시켜보았다. 이 상태에서, 실행을 시키고 해당 컨트롤러 uri를 요청하면,..

Source Code : https://github.com/JangAJang/Algorithm/blob/main/프로그래머스_Lv2/전력망을%20둘로%20나누기/src/Solution.java https://school.programmers.co.kr/learn/courses/30/lessons/8697 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr 문제의 링크는 여기 있다. 완전탐색의 문제였지만, 완전탐색 하나만 생각해서 풀지 않았던 것 같다. 완전탐색으로 각 경우에 탐색할 때, dfs를 사용했으니 틀린말은 아니겠지...?? 일단, 문제를 어떻게 풀지를..