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

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

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

이번달에 캡스톤 디자인 프로젝트를 만들어서 배포까지 경험을 해보았다. 따로 인강을 보거나, 강의를 찾아보지 않고 최대한 공식문서와, gpt를 활용해보았다. 사용해본 기술은 Vue.js를 이용한 프론트엔드 Figma를 이용한 디자인 ( 남정네 셋인지라 디자인을 오픈소스의 도움을 많이 받았다. CSS는 그냥 거기서 다 떼왔다 ) NginX를 이용한 배포 ( 원리를 생각해보니까 생각보다 건드려야 할 부분들이 뭔지 알 것 같았다. ) 정도였다. 이번에 경험했던 부분들을 조금씩 정리를 해보려고 한다. Obsidian에 정리중인데, 정리가 좀 되면 블로그에도 포스팅해야겠다. 정보가 정확하지 않은 메모도 존재한다. 예를 들면, 프론트엔드는 다른 배포에서는 npm run build로 Vue를 html, css, js로..

이 게임을 해본 사람은 알 것이다. 옵저버가 있으면 상대 플레이어를 실시간으로 볼 수 있다. 이를 통해, 우리는 상대방의 행동이나 전략에 따라 유동적으로 반응할 수 있다. 이게 디자인 패턴으로 존재할 때, 어떤 느낌인지 보자. Source Code : https://github.com/JangAJang/cs/tree/main/src/design/observer 옵저버 패턴이란? 계속해서 변하는 객체가 있다고 해보자. 옵저버들이 해당 객체에 연결되어, 객체의 변경을 감지에, 이에 따른 결과를 가져오게 한다. 예시를 생각하자면, 채팅 기능을 생각해보면 될 것 같다. 채팅방이라는 객체와 채팅방에 참여하는 사용자(옵저버)들이 존재할 때, 채팅방에 누군가 글을 올리면, 모든 사람들이 이에 대한 변경을 감지해 글을..

대학생들의 중간고사가 몰린 4월말을 지나, 5월에 접어들었다. 오늘 우아한 테크캠프 1차 코딩테스트를 보았다. 알고리즘에 대한 지식 자체는 예전과 동일한 것 같지만, 여태까지 알고리즘 코딩테스트를 보면서 뇌가 조금 더 말랑말랑(?)해진 것 같다. 사실 이게 이번 글의 주제는 아니다. 이번 달에는 공부의 개념보다, 나 자신의 지나온 길들에 대한 회고를 하고 있었다. 객체지향의 사실과 오해에 대한 스터디는 착실하게 하고있다. 그래도 매주 1회, 안되면 두 단원을 격주에 한번 하는 식으로 코드와, 스스로 이해한 지식에 대해 토론하며, 그룹 스터디의 순기능만을 챙기기 위해 노력했다. 그래서인지, 다른 사람들이 말하는 다 같이 공부할 때 안좋은 점은 느끼지 못했다. CS에 대한 지식도 틈틈히 읽어보고 있다. 학교..

싱글톤과 팩토리 패턴의 디자인은 만들면서 새롭다는 느낌, 활용하기 좋다는 느낌을 받았다. '객체지향의 사실과 오해' 책을 보면서 이를 팩토리 패턴과 함께 활용하면 좋겠다, 싱글톤 패턴의 아쉬운 부분들이 무엇일까를 고민하게 해주었다. 하지만, 이와 반대로 전략 패턴은 오히려 객체지향의 사실과 오해에서 공부했던 부분들을 하나의 패턴으로써 정의했다고 생각한다. 전략패턴이라는 것이 무엇일까? 소스코드 : https://github.com/JangAJang/cs/tree/main/src/design/strategy 전략패턴이란? 전략패턴을 이해하는 과정에서 객체지향의 사실과 오해 3장에서 배웠던 추상화를 생각나게 한다. 객체들의 역할은 대체될 수 있다는 문구가 있었다. A라는 역할을 수행하는 a객체가 있는데, b..

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

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

싱글톤 패턴에서는 모든 객체가 지연 초기화되거나, Holder로 즉시초기화 시켜 있는 객체를 불러와 사용하는 방식이다. 소스 코드 : https://github.com/JangAJang/cs/tree/main/src/design/factory 팩토리 패턴이란? 팩토리 패턴은 말 그대로 '공장' 이다. 공장에서 상품을 만들기 위해서 어떻게 할까? 발주를 받는다. 발주 받은 주문서를 보고 이에 따라 상품을 만든다. 상품을 준다. 의 방식으로 동작하게 된다. 이것과 비슷할까? 팩토리 패턴은 어떨까? Factory에 메서드(어쩌면 static 메서드)로 객체 생성을 요청한다. 파라미터로 요청사항을 받는다. 요청사항에 맞게 객체를 생성한다. 객체를 반환한다. 이런 식으로 처리하게 된다. 여기에서 몇가지 주의해야 ..

싱글톤이란 무엇일까? 싱글톤 패턴이란, 오직 하나의 객체만을 생성할 수 있는 클래스를 말한다. 언제든 객체의 유일성을 보장할 수 있으며, public static 객체클래스 getInstance() 로 해당 객체를 어디서든 불러와 동일한 객체로 동작할 수 있게 해준다. 코드의 구조는 어떨까? 코드는 이렇게, private으로 생성자를 두고, public static 클래스 getInstance로 클래스를 불러와 사용하게 해준다. 이렇게 되어있을 때, getInstance를 부를 때 클래스를 초기화 시키는 방식으로 '지연 초기화'된다. 지연 로딩은 이렇게 있는 구조와 동일하게 여겨진다. 이렇게 하면, 명시적으로 null값이면 초기화 시켜서 인스턴스를 반환하게 해준다. 이 때 문제는, 멀티 쓰레드일 때 생길..