Study
-
오브젝트 - 계약에 의한 설계Study 2024. 1. 24. 21:08
6장에서 설명한 메시지와 인터페이스 원칙에 따라 의도를 드러내도록 인터페이스를 다듬고 명령과 쿼리를 분리했다고 하더라도 명령으로 인해 발생하는 부수 효과를 명확하게 표현하는 데는 한계가 있다 여기서 말하고 싶은 것은 인터페이스만으로는 객체의 행동에 관한 다양한 관점을 전달하기 어렵다는 것이다 우리에게 필요한 것은 명령에 부수 효과를 쉽고 명확하게 표현 할 수 있는 커뮤니케이션 수단이다. 이럴 때 필요한 것이 계약에 의한 설계이다 계약에 의한 설계를 사용하면 협력에 필요한 다양한 제약과 부수 효과를 명시적으로 정의하고 문서와 할 수 있다 클라이언트 개발자는 오퍼레이션의 구현을 살펴 보지 않더라도 객체 사용 법을 쉽게 이해할 수 있다 계약은 실행 가능하기 때문에 구현 의 동기화돼 있는지 여부를 런타임에 검증..
-
오브젝트 - Chapter 15 디자인 패턴과 프레임워크Study 2024. 1. 24. 21:07
디자인 패턴: 소프트웨어 설계에서 반복적으로 발생하는 문제에 대해 반복적으로 적용할 수 있는 설계의 묶음이다. 프레임워크: 설계와 코드를 함께 재사용하기 위한 것 프레임워크는 애플리케이션의 아키텍처를 구현 코드의 형태로 제공한다. 프레임워크가 제공하는 아키텍처가 요구사항에 적합하다면 견고한 구현 코드를 쉽고 빠르게 재사용할 수 있다. 프레임워크는 각 애플리케이션 요구에 따라 적절하게 커스터마이징 할 수 있는 확장 포인트를 제공한다. 디자인 패턴과 프레임워크 모두 일관성 있는 협력과 관련이 있다. 디자인 패턴은 특정한 변경을 일관성 있게 다룰 수 있는 협력 템플릿을 제공한다. 프레임워크는 특정한 변경을 일관성 있게 다룰 수 있는 확장 가능한 코드 템플릿을 제공한다. 01 디자인 패턴과 설계 재사용 소프트웨..
-
오브젝트 - Chapter 10 상속과 코드 재사용Study 2023. 11. 24. 22:35
객체지향 프로그래밍의 장점 중 하나는 코드를 재사용하기 용이하다는 것이다. 전통적인 패러다임에서 코드의 재사용은 코드를 복사 후 수정하는 것이다. 객체지향에서 코드는 일반적으로 클래스 안에 작성되기 때문에 객체지향에서 클래스를 재사용하기 위한 전통적인 방법은 새로운 클래스를 추가하는 것이다. 이번 장에서는 클래스를 재사용하기 위해 새로운 클래스를 추가하는 가장 대표적인 기법인 상속에 대해서 살펴본다. 상속 재사용 관점에서 상속이란 클래스 안에 정의된 인스턴스 변수와 메서드를 자동으로 새로운 클래스에 추가하는 구현 기법이다. 합성 새로운 클래스의 인스턴스 안에 기존 클래스의 인스턴스를 포함시키는 방법 코드를 재사용하려는 강력한 동기 이면에는 중복된 코드를 제거하려는 욕망이 숨어 있다. 중복 코드가 초래하는..
-
오브젝트 - Chapter 05 책임 할당하기Study 2023. 10. 22. 16:13
책임에 초점을 맞춰서 설계할 때 가장 큰 어려움은 어떤 객체에 어떤 책임을 할당할지를 결정하기 쉽지 않다는 것이다. 01 책임 주도 설계를 향해 데이터보다 행동을 먼저 결정하라 책임 중심 설계에서는 "이 객체가 수행해야 하는 책임은 무엇인가"를 결정한 후에 "이 책임을 수행하는 데 필요한 데이터(상태)는 무엇인가"를 결정한다. 협력이라는 문맥 안에서 책임을 결정하라 협력에 적합한 책임이란 메시지 수신자가 아니라 메시지 전송자에게 적합한 책임을 의미한다. 협력에 적합한 책임을 할당하기 위해서는 메시지를 결정한 후에 객체를 선택해야 한다. 메시지를 수신하기로 결정된 객체는 메시지를 처리할 책임을 할당 받게 된다. 협력이라는 문맥 안에서 메시지에 집중하는 책임 중심 설계는 캡슐화의 원리를 지키기가 훨씬 쉬워진..
-
실용주의 프로그래머 - 9장 실용주의 프로젝트Study 2023. 8. 28. 18:45
프로젝트의 성패를 좌우하는 핵심 Topic 49 실용주의 팀 L 그룹에서 스토펠은 여섯 명의 일류 프로그래머를 감독한다. 이는 말하자면 고양이 떼를 모는 일에 비할 만한 도전적인 관리 업무다. 프로그래머는 고양이 같은 면이 있다. 호기심이 많고 제멋대로이며, 고집이 세고, 독립적인 데다, 가끔은 인터넷에서 숭배를 받기도 한다. 이제까지 우리는 개인이 더 나은 프로그래머가 되게끔 도와주는 실용주의 기법들을 살펴보았다. 이런 방법이 팀에도 적용될까? 제멋대로이고 독립적인 사람들이 모인 팀에서도? 답은 명쾌한 "그렇다!"이다. 실용주의 팀은 작다. 구성원이 대략 10~12명 이하여야 하고, 구성원이 추가되거나 빠지는 일은 드물어야 한다. 모두가 서로 잘 알고, 신뢰하며, 의존해야 한다. Tip 84 작고 안정..
-
실용주의 프로그래머 - 7장 코딩하는 동안Study 2023. 7. 22. 16:04
일단 코딩에 들어가면 대부분 기계적인 작업, 즉 설계 내용을 컴퓨터가 실행할 수 있는 문장으로 바꾸는 일만 하면 된다고들 많이 생각한다. 우리가 보기에는 이런 태도가 소프트웨어 프로젝트가 실패하는 가장 큰 원인이다. 이런 태도 때문에 많은 시스템이 결국 너저분해지고, 비효율적이 되고, 구조가 망가지고, 유지 보수가 힘들어지고, 한마디로 완전 잘못되고 만다. 코딩은 기계적인 작업이 아니다. Topic 37 파충류의 뇌에 귀 기울이기 오직 인간만이 무언가를 직접 보고, 정확한 예측에 필요한 모든 정보를 획득하고, 심지어 순간적으로는 정확한 예측을 한 후에도, 그런데 그것이 아니라고 말할 수 있다. - 개빈 드 베커 본능이란 우리 뇌의 무의식 속에 채워져 있는 패턴에 대한 단순한 반응이다. 프로그래머로서 경험..
-
실용주의 프로그래머 - 6장 동시성Study 2023. 7. 22. 16:01
동시성(concurrency) : 둘 이상의 코드 조각이 실행될 때 동시에 실행 중인 것처럼 행동하는 것 병렬성(parallelism) : 실제로 동시에 실행되는 것 동시성을 얻으려면 실행 중에 코드의 다른 부분으로 실행을 전환할 수 있는 환경에서 코드를 구동해야 한다. 보통은 파이버(fiber)나 스레드, 프로세스 등을 사용하여 동시성을 구현한다. 병렬성을 얻으려면 두 가지 일을 동시에 할 수 있는 하드웨어가 필요하다. 애플리케이션이 실제 세상을 다루기 원한다면 동시성은 필수다. 세상은 비동기적이기 때문이다. 가장 큰 문제는 '공유 상태(shared state)'다. 둘 이상의 코드 뭉치가 하나의 변경 가능한 데이터를 참조하고 있다면 공유 상태가 존재하는 것이다. 그리고 다. 동시성을 갖춘 애플리케이션..
-
실용주의 프로그래머 - 3장 기본 도구Study 2023. 6. 18. 19:31
모든 제작자(maker)는 모두 좋은 품질의 기본 도구 세트가 필요하다. 언제나 일을 하는데 더 나은 방법이 없는지 살펴라. 필요에 따라 도구를 취하도록 하라. 많은 신참 프로그래머가 특정 통합 개발 환경(IDE) 같은 강력한 도구 하나만 고집하는 실수를 저지르고, 그 익숙한 인터페이스에서 떠날 생각을 하지 않는다. 우리는 IDE가 갖는 한계를 넘어설 수 있어야 한다. 유일한 방법은 기본 도구들을 언제나 곧바로 사용할 수 있도록 예리하게 유지하는 것이다. Topic 16. 일반 텍스트의 힘 실용주의 프로그래머로서 우리의 기본 재료는 나무나 쇠가 아니라 지식이다. 우리가 수집하는 요구 사항은 지식이고, 우리는 그 지식을 설계와 구현, 테스트, 문서로 표현한다. 그리고 우리는 지식을 저장하는 최고의 포맷이 ..