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

설계가 유연하기 위해서는 의존성을 잘 다룰 수 있어야합니다. 설계가 유연하다는 건 새로운 기능을 추가하거나 제거할 때 큰 비용이 들지 않는 다는 걸 의미합니다. 의존성은 변화의 가능성을 의미합니다. 의존하고 있는 대상이 변경되면 그 변경의 여파가 의존하는 대상에게 까지 미친다는 뜻입니다. 전체 프로젝트를 몰아치는 변화는 큰 비용입니다. 그러니 작은 비용으로 수정을 하고 싶다면 변화와 관련된 의존성을 격리하는 것 부터 시작해야합니다. 그래서 이번 챕터는 주로 의존성에 대한 이야기를 합니다. 우리가 익히 들어 알고있는 OCP에 대한 이야기도 나오게 됩니다. OCP는 코드 수정에는 닫혀있고 기능 확장에는 열린 코드가 좋은 코드라고 말합니다. 컴파일타임 의존성과 런타임 의존성의 차이를 이해하게 되면서 이 문장이..

OOP는 객체간에 메시지로 협력하며 기능을 구현하는 것은 좋습니다. 하지만 이걸론 부족합니다. 협력을 위해서 서로를 참조하며 코드가 커지다 보면 참조의 참조의 참조 문제가 발생하게 됩니다. 하나를 수정하면 그 파급효과가 저 멀리까지 퍼진다는 거죠. 그런 문제가 일어나는 이유는 잘못된 의존성 설계 때문에 그렇습니다. 이번 챕터에서는 의존성이 그 자체로 잘못된 것이 아님을 밝히고 어떻게하면 현명하게 사용할 수 있는지 알려줍니다. 의존성의 바람을 바람직 하게 만들라고 조언합니다. 그 방법에 대해서 정확하게 알려주진 않는 듯 합니다. 어떤 의존성이 바람직한가? 를 알려면 아키텍쳐에 대한 학습이 병형되어야 한다고 생각합니다. 클린 아키텍쳐에서 봤던 경계를 기준으로 단방향 의존성을 가진 시스템을 설계하는 게 괜찮을..

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

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