💡 조영호님의 오브젝트를 읽고 생각을 정리하였습니다. 객체지향 설계를 하는 이유는 궁극적으로 앞으로의 설계 변경에 쉽게 대응하기 위함인 것 같다. 책에서는 왜 객체지향설계를 하면 설계변경에 대응하기 쉬운지 데이터지향 설계를 했을 때의 단점을 보여주면서 설명해 주고 있다. 또한 좋은 설계를 판단하는 기준으로 캡슐화, 응집도, 결합도에 대해서 설명하고 있다. 캡슐화 목적 객체의 내부 구현을 외부로 부터 감추는 것 구현이란? 변경 가능성이 높은 부분 인터페이스? 상대적으로 안정적인 부분 불안정한(변경가능성 높은) 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화하자 궁극적으로 이뤄내려는 것 높은 응집도와 낮은 결합도는 캡슐화로 부터 나온다 응집도 변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도 하나의 변경..

💡 조영호님의 오브젝트를 읽고 생각을 정리하였습니다. 이번 장에서는 시스템을 객체지향 패러다임을 통해 만들기 위해 “객체들의 협력하는 공동체”를 만들어야한다는 전제하에 어떤 사고의 흐름을 통해 만들어 낼 수 있을 것인가를 설명하고 있다. 객체 한 개를 만들기 위해 어떤 사고 과정을 거쳐 나가야할까? 어떤 애플리케이션에 객체가 존재하는 이유는 해당 객체가 “협력”에 참여 하고 있기 때문이다. 즉, 객체는 협력에 필요한 특정 행동을 하고 있을 것이다. 따라서 아래의 사고 과정을 거쳐서 하나의 객체를 만들 수 있을 것이다. 기능 제공을 위해 어떤 협력이 필요할까? (베이스 깔고 가는생각) 협력은 설계를 위한 문맥을 제공하기 때문에 가장 우선시 되어 생각되어야한다. 협력 안에서 어떤 책임(행동)이 필요할까? 시..

💡 조영호님의 오브젝트를 읽고 생각을 정리하였습니다. 조영호님의 “객체지향의 사실과 오해”라는 책을 읽고 어느 정도 객체지향이란 무엇 인가에 대해 느낌을 얻을 수 있었습니다. 하지만 해당 책에서는 코드보다는 이상한 나라의 엘리스에서의 예시를 가지고 설명을 해주어서 모호한 느낌을 받은 부분이 있었습니다. 현재 프로그램을 개발하면서, 객체의 책임과 역할에 대해서 생각해보고 어떤 메세지를 통해 서로 소통할 수 있게 할 것인가 고민하던 찰나 좋은 코드를 보고 싶다는 생각이 들었습니다. 마침 “ 오브젝트” 라는 책에서는 실제 코드를 기준으로 이야기를 해준다고 해서 읽게 되었고 읽은 내용을 정리하고자 합니다. 첫번째 챕터는 마치 “객체지향의 사실과 오해” 요약본 같았습니다. 중요 키워드로는 의존성, 캡슐화, 설계 ..

들어가기 컴퓨터 그래픽스를 공부하면서 Blender와 같은 간단한 렌더러를 우선 만들어 보는 것을 목표로 하였습니다. OpenGL, DirectX 사용해 보면서 처음 GPU를 활용한 렌더링을 해보았는데 이때 중요한 개념인 그래픽 파이프라인에 대해 정리해 보려고 합니다. [틀린 부분이 있다면 댓글로 알려주시면 감사하겠습니다!] 파이프라인이란? 먼저 파이프라인이란 간단하게 데이터 처리 단계를 말합니다. 따라서 그래픽 파이프 라인이란 화면에 어떤 물체를 그리기 위해 행해지는 일련의 데이터 처리 단계입니다. 데이터 처리는 어디서 이루어 질까? [CPU VS GPU] 물체를 화면에 그리기위해서 처리 되어야 하는 데이터의 종류는 다양합니다. 데이터의 종류에 따라 CPU 혹은 GPU에서 처리됩니다. CPU에서 처리되..

💡 조영호님의 객체지향의 사실과 오해를 읽고 정리하였습니다 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라 기능 설계 vs 구조 설계 예측 불가능한 요구사항을 만족하는 기능을 제공하는 동시에 요구사항 변경에 유연하게 대처할 수 있는 구조를 가지는 소프트웨어를 만들어야함 변경을 수용할 수 있는 선택의 여지를 설계에 녹여 놓아야함 변경에 소요되는 비용을 낮출 수 있음 어떻게?? 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하자! 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템의 기능을 객체 간의 책임으로 분배 두가지 재료 : 기능과 구조 기능 사용자가 목표달성을 위해 사용할 수 있는 시스템의 서비스 구조 시스템의 기능을 구현하기 위한 기반 기능변경을 수용할..

💡 조영호님의 객체지향의 사실과 오해를 읽고 정리하였습니다 자율적인 책임 객체가 어떤 행동을 하는 유일한 이유는 다른 객체로 부터 요청(메세지)를 받았기 때문임. 받은 요청을 처리하기 위해 객체가 수행하는 행동을 ‘책임’이라고함 책임을 수행하는데 있어 방법은 객체마다 다를 수 있고 자율적임. 해당 방법을 요청하는 객체가 제한하는 것은 좋지 않음 따라서, 어떻게 책임 질 것인가 보다는 무엇을 책임질 것인가가 중요함 메시지와 메서드 메세지 하나의 객체는 메세지를 전송함으로서 다른 객체에 접근함 왕이 모자 장수에게 ‘증언하라’라는 메세지를 보낸는 경우 모자 장수.증언하라(인자) 인자에는 증언에 필요한 정보가 들어갈 수 있음(언제, 어디서 등등) 메서드 메세지를 수신하는 객체가 메세지를 처리하기 위해 내부적으로..

💡 조영호님의 객체지향의 사실과 오해를 읽고 정리하였습니다 기억에 남는 문구 객체의 세계에서 협력이라는 문맥이 객체의 행동 방식을 결정함 객체지향 설계의 전체품질을 결정하는 것은 여러 객체들이 모여 이뤄내는 협력의 품질 어떤 협력에 참여 하는지가 객체에 필요한 행동을 결정, 필요한 행동이 객체의 상태를 결정 결론 : 객체지향 설계란 애플리케이션의 기능을 구현하기 위한 협력 관계를 고안하고, 협력에 필요한 역할과 책임을 식별한뒤 이를 수행할 수 있는 적절한 객체를 식별해 나가는 과정 객체지향의 세계는 동일한 목적을 이루기위해 협력하는 객체들의 공동체 협력 협력의 본질은 요청과 응답으로 연결되는 사람들의 네트워크 특정 요청을 보냈다는 것은 해당 객체가 요청에 대한 의무를 가지고 있고 요청에 필요한 지식을 가..

데이터 베이스 시스템의 구성 데이터 베이스에 데이터를 저장하고 이를 관리하여 조직에 필요한 정보를 생성해주는 시스템 사용자 데이터 언어 데이터 베이스 관리 시스템 데이터 베이스 데이터 베이스의 구조 스키마와 인스턴스 스키마 데이터 베이스에 저장되는 데이터 구조와 제약조건을 정의 한 것 인스턴스 스키마에 따라 실제 데이터 베이스에 실제로 저장된 값 3단계 데이터 베이스 구조 미국 표준화 기관에서 제안 데이터 베이스를 관점에 따라 3가지로 나눈 것 외부 단계(external level) : 개별 사용자 관점 개념 단계(conceptual level) : 조직의 전체 관점 내부 단계(internal level) : 물리적인 저장 장치 관점 데이터 독립성을 위해 3 단계로 나누었음 하위 단계에 변화가 있더라로 ..