# book

55개의 포스트

부의 추월차선을 읽고

저자 엠제이 드마코는 부로 가는 길은 인도, 서행차선, 추월차선 3가지 길이 있다고 한다.먼저 인도는 절약없이 흥청망청 사는 인생이다. 순간의 행복에 충실? 한 길이다. 그리고 서행차선의 경우 월급을 알뜰하게 써서 절약하고 저금해서 나중에 은퇴하고 행복을 찾는 길이다.

2020년 4월 11일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 26장_PROXY와 STAIRWAY TO HEAVEN_서드파티 API 관리

소프트웨어 시스템에는 많은 경계와 장벽이 있다. 프로그램에서 데이터베이스로 데이터를 옮기는 것은 데이터베이스의 장벽을 넘는 것이며, 한 컴퓨터에서 다른 컴퓨터로 메시지를 전송하는 것은 네트워크의 장벽을 넘는 것이다.PROXY 패턴은 우리가 집중하려는 핵심 비즈니스 로직

2020년 4월 6일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 25장_ABSTRACT SERVER, ADAPTER, BRIDGE 패턴

ABSTRACT SERVER 패턴은 디자인 패턴 가운데 가장 단순한 패턴으로, DIP를 지키기 위해 가장 첫 번째로 적용해볼 수 있는 방법이다. 이전의 숱한 예시에서도 익숙하게 사용해 왔던 방식인데, 상위 모듈이 구체적인 하위 모듈에 의존하도록 하지 않고 사이에 인터페

2020년 4월 6일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 24장_OBSERVER 패턴

OBSERVER 패턴은 객체의 상태 변화를 관찰하는 관찰자들, 즉 옵저버들의 목록을 객체에 등록하여 상태 변화가 있을 때마다 메서드 등을 통해 객체가 직접 목록의 각 옵저버에게 통지하도록 하는 디자인 패턴이다.디지털 시계 구현을 예시로 OBSERVER 패턴을 알아보자.

2020년 4월 4일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 23장_COMPOSITE 패턴

동일하게 취급 받는 파생 클래스가 여러개 있을 때, 이 여러 파생 클래스를 멤버 변수로 두고, 똑같은 기반 클래스를 상속하는 COMPOSITE 클래스를 만들 수 있다. 이 패턴의 사용은 단순하지만 가져올 수 있는 이득은 크다.앞서 COMMAND 패턴에 대해 소개하면서

2020년 4월 4일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 21장_FACTORY 패턴

우리는 11장에서 DIP에 대해 배우면서, 구체적인 클래스에 의존하지 않고 사이에 인터페이스를 하나 두어서 추상화에 의존하도록 하는 방법을 배웠다. 하지만 어떤 클래스 내에서 다른 클래스를 새로 생성해야 할 때는 인터페이스가 존재하더라도 무조건 구체적인 클래스에 의존성

2020년 4월 4일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 18장_급여 관리 사례 연구

18장과 19장에서는 간단한 일괄 임금 지불 시스템을 설계하고 구현하는 과정을 소개한다. 이번 장에서는 그 개발 과정의 맨 첫 번째 반복을 보여줄 것이다.다음은 첫 반복에 선택된 사용자 스토리에 관해 고객과 나눈 대화에서 메모한 사항 중 일부이다.몇몇 직원은 시간제로

2020년 4월 4일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 17장_NULL OBJECT 패턴

우리는 위와 같은 null 체크에 대해 익숙하다. 종종 이런 식의 코드는 가독성을 떨어뜨리며 에러가 발생하기 쉽다.이런 경우 NULL OBJECT 패턴을 사용하면 null 검사의 필요를 제거하고 코드를 단순화하는데 도움을 줄 수 있다.NULL OBJECT는 클래스의 정

2020년 4월 4일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 16장_SINGLETON 및 MONOSTATE 패턴

종종 클래스와 인스턴스는 1:N 관계를 가진다. 그리고 인스턴스는 애플리케이션보다 짧은 라이프사이클을 가지며 생성되고 소멸되기를 반복한다.하지만 단 하나의 인스턴스만을 가져야 하는 클래스도 있다. 팩토리 클래스 혹은 매니저 클래스 등이 그 예시인데, 이러한 클래스들은

2020년 4월 4일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 15장_FACADE 및 MEDIATOR 패턴

FACADE 패턴은 복잡하고 일반적인 인터페이스를 가진 객체 그룹에 간단하고 구체적인 인터페이스를 제공하고자 할 때 사용한다.예를 들어, 우리가 직접 작성한 어플리케이션에 DB와 연동되어야 하는 Product라는 객체가 있고, DB 연동 작업을 처리할 수 있도록 하는

2020년 4월 4일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 14장_TEMPLATE METHOD 및 STRATEGY 패턴: 상속과 위임

이 장은 상속과 위임의 차이를 전형적으로 보여주는 두 개의 패턴에 대해 다룬다. TEMPLATE METHOD 및 STRATEGY 패턴은 비슷한 문제를 해결하고 보통 호환되어 쓰인다. 그러나 TEMPLATE MEHOD는 문제를 해결하기 위해 상속을 사용하는 반면, STR

2020년 3월 29일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 13장_COMMAND 및 ACTIVE OBJECT 패턴

COMMAND 패턴은 서로 다른 일을 하는 객체 그룹이 하나의 레벨로 묶이길 원할 때 사용하는 패턴이다. COMMAND 패턴의 핵심은 매우 단순한 인터페이스 하나로 설명될 수 있다.이것은 command 객체 안에 존재하는 do() 함수의 수준을 클래스 수준으로 격상시키

2020년 3월 29일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 12장_인퍼테이스 분리 원칙

위 상황은 ISP가 지양하는 바로 그 상황이다. 각각의 Transaction 파생 클래스들은 모두 하나의 UI 인터페이스에 의존하게 되는데, 자신이 사용하지 않는 메소드에 의존하게 될 수 밖에 없으며 UI의 일부 메소드의 변경에 대한 영향이 이 UI에 의존하는 모든 T

2020년 3월 29일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 11장_의존 관계 역전 원칙

DIP는 물론 매우 유익한 내용을 담고 있는 객체 지향 설계 원칙이지만, 그 이름에 왜 역전(inversion)이라는 단어가 사용되는지 단번에 와닿지 않을 것이다.(나도 이 책을 읽고 나서야 그 이유를 알게 되었다.) 이는 보다 전통적인 소프트웨어 개발 방법에서는 소프

2020년 3월 28일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 10장_리스코프 치환 원칙

위 함수는 LSP를 위반한다. 현재는 Shape라는 기반 클래스를 상속하는 클래스가 Circle 클래스와 Square 클래스 뿐이지만, 이를 상속하는 또 다른 클래스 Triangle이 추가된다면 이 함수에 등장하는 Shape(기반 타입)은 Triangle(하위 타입)로

2020년 3월 26일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 9장_개방 폐쇄 원칙

모듈의 동작을 쉽게 확장할 수 있다는 것을 의미한다. 애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있다.어떤 모듈의 동작을 확장하는 것이 그 모듈의 소스 코드의 변경으로 이어지는 것은 아니다. 한 객체의 변경이 의존관계

2020년 3월 26일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 8장_단일 책임 원칙

클래스는 단 한 가지의 변경 이유만을 가져야 한다.객체 지향 설계에서 '책임'이란 '변경의 축'을 의미한다. 하나의 클래스가 여러 책임을 떠앉고 있을 경우 이 클래스는 변경에 대한 여러 가지 이유를 가지게 되며, 이는 불필요한 관리 포인트를 증가시켜 코드의 유지보수를

2020년 3월 25일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 7장_애자일 설계란 무엇인가

설계가 잘못되었을 때 소프트웨어는 다음과 같은 증상을 보인다.경직성 - 설계를 변경하기 어려움취약성 - 설계가 망가지기 쉬움부동성 - 설계를 재사용하기 어려움점착성 - 제대로 동작하기 어려움불필요한 복잡성 - 과도한 설계불필요한 반복 - 마우스 남용불투명성 - 혼란스러

2020년 3월 25일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 5장_리팩토링

소프트웨어는 고객을 위한 것이지만, 동시에 개발자를 위한 것이기도 하다. 개발자를 위한 소프트웨어라는 측면에서, 소프트웨어는 읽기 쉽고 변경하기 쉬워야 한다. 이 책의 대부분은 읽기 쉽고 변경하기 쉬운 코드를 작성하기 위해 필요한 원칙과 패턴을 소개하고 있지만, 궁극적

2020년 3월 25일
·
0개의 댓글
post-thumbnail

Review: 소프트웨어 개발의 지혜 - 4장_테스트

TDD를 하는 방법은 간단하다. 프로그램을 설계하기 전에 테스트 코드부터 작성하는 것이다. 단순한 방법이지만, 이렇게 함으로써 여러가지 이득을 얻을 수 있다.개발 과정에서 작성하게 되는 모든 코드는 기능을 검증할 수 있는 테스트 코드를 갖게 된다. 빈번하게 변경이 일어

2020년 3월 25일
·
0개의 댓글