객체지향 해석

보통 컴퓨터의 역사에서 절차지향과 객체지향이 나온 동기를 이해하며 객체지향을 배운다.나는 이런 기본이 부족하기 때문에 내 식대로 객체지향을 해석할 것이다.나의 사상은 이렇다. 소프트웨어는 순수하게 사람이 만든 것이기 때문에 소프트웨어의 모든 것엔 의도가 존재한다. 나의

개인적으로 소프트웨어에서 중요하다고 생각하는건 돈을 버는 것이라고 생각한다.사용자든 고객이든 만족시켜서 돈을 버는것이 중요하므로 소프트웨어에서 가장 중요한 건 요구사항을 이끌어내고 만족시키는 것이다.요구사항과 객체지향은 아주 근접해있다. 사실 소프트웨어의 거의 모든 것

Domain-Driven-Design

보통 TDD는 다음과 같은 절차를 가진다.RED: 실패하는 테스트 코드를 먼저 작성한다.GREEN: 테스트 코드를 성공시키기 위한 실제 코드를 작성한다.BLUE: 중복 코드제거, 일반화등의 리팩터링을 실행한다.내가 TDD를 싫어하는 이유다.하지만 나는 TDD를 사랑한다

추상화?? 추상화를 대표하는 학문은 수학이다. 수학의 추상화는 정말 어렵다. 수학의 추상화를 즐길 수 있다면 그게 수학 재능이다. 수학의 추상화가 너무 악명이 높기 때문에 프로그래밍의 추상화 또한 어려울 것이라고 생각한다. 수학의 추상화와 프로그래밍의 추상화는 같다

나는 파인만을 좋아한다. 물리학과를 나오면 파인만의 빨간책이란 걸 읽는데 읽다보면 그의 전기도 읽는게 보통이다. 파인말 왈 쉽게 표현하면 되는데 뭐하러 어렵게 표현하나.그래서 파인만은 이론도 그림으로 다이어그램 만들어서 노벨상탐아무튼 내가 하고 싶은 말은 객체지향 설명

요구사항, 계약, 메시지 객체지향을 설명하면서 강조했던 세 가지이다. 세 가지가 독립적인 게 아니고 유기적으로 연결되어 있다는 걸 이제는 잘 알 것이다. 이 글 시리즈의 내용 또한 세 가지의 유기적인 흐름을 그대로 보여주었을 뿐이다. 인터페이스와 다형성은 그냥 갈아