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

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

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

역할과 책임의 구분이 명확히 이해되지 않습니다. 작은 프로젝트나 쉽게 변경될 수 있는 서비스 코드, 특히 UI를 만드는 입장에서 역할 처럼 구현체의 Slot 처럼 동작하는 게 필요할지 의문입니다. 전체적으로 추상적인 내용이였다고 생각합니다만, 코드를 짤 때 역할, 책임, 협력을 좀 생각해보게 되는 것 같습니다. 아, 그나저나 협력의 과정에서 다른 객체에게 단순히 메시지를 보낸다는 개념은 너무 좋은 것 같습니다. 서버 객체 레벨에서 캡슐화를 얘기할 때는 감이 잘 안왔는데, 클라이언트 객체가 메시지를 보낸다는 개념을 생각하니 클라이언트 입장에서 서버의 세부 구현이 캡슐화 된 것이더군요. 객체지향 패러다임의 관점에서 핵심은 역할, 책임, 협력 (role, responsibility, collaboration)..

무조건 유연한 설계도, 무조건 읽기 쉬운 코드도 정답이 아니라고 합니다. 올바른 구현이라는 망령에 시달린 것 같습니다. 상황에 따라서 트레이드 오프를 적절히 취사선택 하며 개발할 줄 아는 개발자가 되어야겠습니다. 아직 이 책에서 말하는 "적절한 책임"이 무엇인지는 잘 모르겠습니다 영화 예매 시스템 객체지향 프로그래밍을 향해 클래스가 아닌 객체에 초점을 맞춰야 한다. 어떤 객체가 필요한지 고민하라. 협력하는 공동체의 일원으로 봐야 한다. 💡 객체, 협력으로 부터 클래스를 도출하라. 요구사항과 프로그램을 객체라는 동일한 관점에서 바라볼 수 있다. (도메인을 따르는 프로그램) 클래스를 구현하거나 사용할 때 가장 중요한 것은 클래스의 경계를 구분 짓는 것이다. 객체는 상태와 행동을 함께 가지는 복합적인 존재 스..