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

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..