선생님, 개발을 잘하고 싶어요.

이번 챕터는 추상화와 분해에 대해서 알아보는 시간이었습니다. 저는 추상화라고 하면 어느 순간부터 abstract class니 interface니 하는 구현에 관련된 생각으로 시야가 좁아졌었나 봅니다. 추상화는 왜 하는 것일까요? Open Closed 원칙을 지키기 위해서 일까요? 아니죠. 결국에는 사람이 쉽게 이해하는 코드를 만들기 위해서 나온 개념입니다. 사람은 너무 많은 세부사항을 한번에 기억할 수 없습니다. 적어도 저는 그렇습니다. 비즈니스 로직 작업을 하면서 동시에 화면에 어떻게 그리고 애니메이션 될 지 고민하면 작업이 진행이 도무지 안됩니다. 비즈니스 로직 작업 및 검증 따로, 비즈니스 로직이 정상 동작한다 생각하고 화면 작업 따로 진행합니다. 그래야 일이 진행이 됩니다. 이게 바로 추상화입니다..

메시지와 메서드의 차이를 명확하게 설명하는 챕터였다고 생각합니다. 메시지를 좀더 추상적인 개념으로 받아드리게 되었어요. 이 생각의 변화가 중요하다고 생각한 나름의 이유는 다형성에 있습니다. 결국 코드를 작성하다보면 객체에 함수를 호출하는 형태로 구현되기 마련이죠. 그래서 메시지는 함수인가? 싶은 생각이 들게 됩니다. 하지만 인터페이스나 추상 클래스를 사용하는 경우 코드 상으로는 함수 호출이지만 실제로 실행되는 코드는 런타임에 진짜 객체에 의해서 결정되죠. 그러니까 우리가 생각하는 객체에 함수를 호출하는 행위는 객체에 메시지를 보내는 것입니다. 클라이언트 입장에서 함수의 세부 구현에 대해서 신경쓰지 않는다는 것이죠. 서버로 메시지를 보내면 서버가 타입에 맞게 적절한 구현체를 찾아서 실행합니다. 이 실제 구..

책임 주도 설계... 설계에 대해서 별 생각을 안하고 있었는데 설계 관련된 책을 읽는게 나름의 인사이트를 주는 것 같습니다. 코드의 좋고 나쁨을 평가할 수 있는 스스로의 기준이 마련되어야 내가 좋은 코드를 짜고 좋은 개발자가 될 수 있겠지요. 이런 설계 책을 읽으면 나만의 기준을 잡아가는데 도움이 되는 듯 합니다. (물론 아직 실제로 더 사용을 해봐야하겠지만요) 이 챕터에서 의문인 부분은, "변경의 이유가 하나 이상인 클래스를 조심하라"는 건데요. 흠... 변경의 이유가 여러개라도 그 변경의 파장이 하나의 클래스 범위 내에서만 일어난다면 높은 응집도는 아니더라도 낮은 결합도를 가지고 변경 범위가 클래스 하나 레벨로 좁은, 변경하기 쉬운 코드가 생기지 않을까요. 결국 변경의 이유가 하나 이상인 모듈을 조심..

지금까지는 데이터 중심으로 생각한 것 같습니다. 책임 중심 관점으로 쉬프트를 해볼 가치는 있는 것 같습니다. 근데 객체에게 어느 정도까지 책임을 쪼갤 것이냐 하는 문제가 항상 있습니다. 여기서 저자는 트레이드 오프를 얘기합니다. 책임을 너무 쪼개서 마냥 좋다는 건 아니란 거죠. 그렇다면 어떤 기준을 잡고 쪼개야 할 까요? 이를 우리 스스로 판단할 판단 기준을 알려줍니다. 캡슐화, 응집도, 결합도가 그것입니다. 하지만 이 품질 척도가 절대적으로 지켜저야 하는 건 아니라는 점을 다시 상기하게 됩니다. 이런 척도가 생긴 이유를 항상 상기해야합니다. 변경에 강한 코드를 작성하는 것이 우리의 목적이였습니다. 협력: 기능을 구현하기 위해 메시지를 주고받는 객체간 상호작용 책임: 다른 객체와 협력하기 위해 수행하는 ..