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

DRY 원칙과 이를 달성하기 위한 방법으로 자주 사용되는 상속에 대해서 다룬 챕터였습니다. 우선 DRY를 판단하는 기준에 대해서 설명하는데 중복 코드의 기준은 코드의 모양이 아니라 변경시 함께 수정되어야 하는가 여부라는 내용이 좋았습니다. 기존 클래스와 유사한 동작을 하는 새로운 클래스를 만들기 위해서 Copy & Paste하는 것의 문제점을 살피고 상속을 활용해서 기존 코드를 재활용하는 방법을 보입니다. 하지만 부주의한 상속의 과정에서 따라오는 문제를 조명합니다. 부모 클래스를 잘못 설계하면 자식 클래스가 부모 클래스의 구현에 강하게 결합되며 부모 클래스를 점진적 개선 시키는 게 어렵다는 내용이였습니다. 상속과 중복 코드 DRY 원칙 중복 코드는 변경 방해 중복 여부 판단하는 기준은 변경이다. (not..

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

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

파일 저장소 구분 internal: 항상 접근 가능, 파일을 저장한 앱에서만 접근 가능, 앱 제거시 함께 사라짐 external: removable한 저장소 (usb, disk 등은 항상 제거될 수 있다), 어디서든 접근 가능, 앱 제거해도 그대로 남아있음. 주의 사항) app-specific external은 그냥 외부 disk (sdcard) 등에 저장될 뿐 앱과 함께 제거되고 접근 가능한 속성을 그대로 가진다. Internal 저장소 사용 예시 class InternalFileStorageUseCase { private lateinit var context: Context // 내부 저장소에 저장된 파일에 접근하기 fun accessStoredFile(): File { val dir = contex..

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

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

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

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