독서에서 한걸음52 객체지향 설계 용어 정리 내가 코드를 설명할 때 사용하는 용어에 대한 질문이 있을 수 있다. (상상) 만약 내가 코드를 리뷰한다면 적절히 통용되는 단어를 선택하여 리뷰를 진행할 텐데, 만약 질문자가 해당 용어에 대해 질문한다면 깔끔히 이를 설명할 수 있어야 한다고 생각했다. 그래서 오늘 아침은 간단하게 객체지향 설계에서 사용되는 용어에 대한 정리를 하려고 한다. 객체는 메시지를 통해 협력한다고 우리는 알고 있다. 그리고 메시지를 메서드와 동일화하는 경향이 있다. 객체지향에서는 메시지와 메서드를 명확하게 구분한다. 메시지는 객체가 다른 객체와 협력하기 위해 사용하는 의사소통 메커니즘이다. 오퍼레이션이 실행되도록 요청하는 것을 메시지 전송이라 하고, 메시지는 협력에 참여하는 전송자와 수신자 양쪽 모두 포함하는 개념이다. 그렇다면 오.. 2023. 2. 28. [오브젝트] 데이터 중심 설계(3) 2023.02.26 - [독서에서 한걸음] - [오브젝트] 책임 중심 설계와 데이터 중심 설계 (2) [오브젝트] 책임 중심 설계와 데이터 중심 설계 (2) 2023.02.25 - [독서에서 한걸음] - [오브젝트] 책임 중심 설계와 데이터 중심 설계 (1) [오브젝트] 책임 중심 설계와 데이터 중심 설계 (1) 조영호 님의 Object라는 책을 통해 객체지향 설계와 데이터 중 chinggin.tistory.com 설계의 과정을 되돌아본다면 데이터 중심 설계, 책임 주도 설계인지 모르고 과거의 배운 대로 생각 없이 만드는 경우가 있다. 이러한 과정이 반복되면 어느샌가 스파게티 코드가 탄생하고 유연하게 변경사항을 반영할 수 없게 되는 경우를 겪어보았다. 그렇다면 지금 코드를 점검하기 시작하여 리팩토링을 해.. 2023. 2. 26. [오브젝트] 책임 중심 설계와 데이터 중심 설계 (2) 2023.02.25 - [독서에서 한걸음] - [오브젝트] 책임 중심 설계와 데이터 중심 설계 (1) [오브젝트] 책임 중심 설계와 데이터 중심 설계 (1) 조영호 님의 Object라는 책을 통해 객체지향 설계와 데이터 중심 설계에 대한 이야기를 읽었다. 객체지향 설계에 대한 가장 중요한 요소는 책임이라는 설명과 이를 객체의 상태에 맞춰 설계를 하 chinggin.tistory.com 책임 중심의 설계를 진행했다면 비교를 위해 데이터 중심 설계를 겪을 차례다. 여기선 데이터가 무엇인가로 시작한다. 이번 예제는 github에 올라와 있는 예제를 쓴다. public class Movie { private String title; private Duration runningTime; private Money .. 2023. 2. 26. [오브젝트] 책임 중심 설계와 데이터 중심 설계 (1) 조영호 님의 Object라는 책을 통해 객체지향 설계와 데이터 중심 설계에 대한 이야기를 읽었다. 객체지향 설계에 대한 가장 중요한 요소는 책임이라는 설명과 이를 객체의 상태에 맞춰 설계를 하면 유연성이 사라지고 높은 의존성과 낮은 응집도를 통해 변경에 취약해진다고 한다. 실제 예시에 대한 설계를 보면서 데이터 중심 설계의 문제를 하나씩 리뷰해 보자. 설계의 기초는 도메인에 대한 이해다. 다만 해당 내용은 책의 내용으로 밝히지 않고 진행하려고 한다. 이 책은 객체지향의 사실과 오해를 읽고 그 다음 순서로 읽는 것을 추천하고 개발자라면 두세 번은 아니더라도 한 번은 꼭 읽어 봤으면 좋겠다. 책임을 중심으로 설계를 진행할 때 해결하려는 문제를 큰 협력이라는 틀을 잡고 이 큰 협력을 해결하기 위해 작은 협력으.. 2023. 2. 25. 아싸 2023. 2. 20. 읽고 싶은 책이 늘었다. 한 권으로 읽는 컴퓨터 구조와 프로그래밍 끙끙거리면서 책을 읽었다. 매우 어려운 내용들이 많아서 이해하기 힘든 부분에 대해 서치 하면서 최대한 이해하려 노력해 보았지만 회로 부분에서 상당히 고생했다. 이제 거의 다 읽었지만 뭔가 부족해 전자회로 관련 수업을 신청해서 공부한 후 관련 부분만 다시 읽을려고 한다. 이 책을 읽다보면 역사를 보는 기분이다. 어떻게 발전되고 우리가 사용하는 모든 것의 기반이 무엇인지 자세하지는 않지만 이해는 시켜주는 책이라고 느껴졌다. 한줄평 : "좋았다. 내 출퇴근 시간을 녹여주는 흥미로운 책이었고 프로그래밍에 대해 생각이 더 열린 기분이다." 요즘 설계문서에 대해 관심이 많다. 설계문서는 필수불가결하게 존재하게된다. 고객의 요구든, 자체 개발을 진행해도 그 과정을 한눈으로 정.. 2023. 2. 6. debounce 장치에 버튼이나 스위치가 들어가는 경우 버튼에 연결된 금속 조각이 접점에 닿으면 금속 조각이 아주 잠깐 bounce를 가지면서 접정에서 떨어진다. 접촉면이 안정될 때까지 이런 돼 튕김이 여러 번 발생할 수 있다. 버튼을 프로세서의 인터럽트 발생 핀에 연결하는 경우 푸쉬 버튼을 한 번 눌러도 인터럽트가 여러 번 발생할 수 있다. 버튼을 디바운스(debounce)되는 현상을 제거할 필요가 있다. 대부분의 시스템에는 주기적인 인터럽트를 만들어내는 일종의 타이머가 있다. 이 인터럽트를 이용해 버튼 디바운싱을 해결할 수 있다. 이를 해결하기 위해서는 일정 시간동안 버튼의 상태를 지속적으로 관찰해야 합니다. 이를 FIR을 사용하면 해결할 수 있다. 타이머를 이용해 주기적으로 인터럽트를 만들어내면서, 버튼 상태를 지.. 2023. 1. 21. 도메인 모델과 경계 한 도메인은 여러 하위 도메인으로 구분되기 때문에 한 개의 모델로 여러 하위 도메인 모두 표현하려고 시도하면 오히려 모든 하위 도메인에 맞지 않는 모델을 만들게 된다. 이유는 하위 도메인마다 사용하는 용어와 의미가 다르기 때문인데, 예를 들어 상품이라는 모델이 있다. 카탈로그에서의 상품, 재고 관리에서의 상품, 주문에서의 상품, 배송에서의 상품 하위 도메인에서 상품은 이름만 갖지 실제 의미하는 것이 다르다. 카탈로그에서는 상품의 정보가 주된 목적이라면, 재고 관리에서는 추적을 위한 정보, 주문에서는 장바구니에 담겨있는 상품들과 가격 정보.. 등등 실제 하위 도메인에서 바라보는 상품은 그 개수가 하나일 수도 여러 개일 수도 있다. 따라서 도메인을 두고 고민을 할 때 다음 내용을 떠올리자. 하위 도메인마다 .. 2023. 1. 3. 도메인 주도 개발 Value Type 절반가량을 읽었다. 정말로 책을 읽으면서 많은 서치를 해서 실제 프로젝트에 적용시킨 개념들도 많았고 도메인 주도 개발이라는 개념이 조금씩은 눈에 들어와 기존에 있던 패키지 구조도 변경을 하니 각각 맡고 있는 도메인들이 한눈에 더 잘 보이기 시작했다. 과거의 코드를 보면서 이 코드는 현재 잘못됫구나 루트 도메인의 하위 도메인에 접근하여 사용하고 있던 것들도 있었고, 여러 가지 위임을 숨기면서 클라이언트가 필요한 메서드를 만들어서 하위 도메인 개념을 숨기기도 하였다. 추가로 충격을 받았던 문구도 있었다. "테이블이 도메인이라고 과거에는 착각을 했었다. 하지만 도메인에 대한 깊은 지식이 쌓일수록 이러한 지식이 잘못된 것을 알았다." 나도 착각을 했었고, 이를 바로잡기위해 더 노력하고 있는 중이다. 아마 해당 .. 2023. 1. 1. Comments 모든 주석이 나쁘지 않다. 필요한 주석도 반드시 있지만 일부 주석은 안 좋은 코드냄새를 나타낸다. 주석을 남겨야 할 것 같다면 먼저 코드를 리팩토링해야한다. 코드를 작성 중에 해당 코드 블럭에 대한 주석이 필요할 것 같다면 해당 부분을 함수로 추출하여 의도를 나타내는 함수 선언부를 변경해야 한다. 이후 적절한 위치로 옮기면 된다. 시스템적으로 어떤 필요한 규칙이 있따면, 어서션 추가하기를 적용할 수 있다. Introduce Assertion 종종 코드로 표현하지 않았지만 기본적으로 가정하고 있는 조건들이 있다. 그런 조건을 알고리듬을 파악하거나 주석을 읽으면서 확인할 수 있다. 그러한 조건을 Assertion을 사용해서 보다 명시적으로 나타낼 수 있다. Assertions은 if나 swtich 문과 달리.. 2022. 12. 28. 이전 1 2 3 4 ··· 6 다음
