분류 전체보기 (104) 썸네일형 리스트형 Dependency Injection - Chapter1 마지막(DIScope, Summary) 앞서 설명했듯이 DI의 중요한 요소는 다양한 책임 관계를 별도의 클래스로 나누는 것입니다. 클래스에서 분리하는 책임 중 하나는 의존성의 인스턴스를 생성하는 작업입니다. Hello DI! 예제에서 Salutation 클래스에서 종속성 생성 책임이 해제된 예제에서 이에 대해 설명했습니다. 대신 이 책임이 애플리케이션의 Main 메서드로 옮겨졌습니다. 클래스가 종속성에 대한 제어권을 포기하면 특정 구현을 선택하는 것 이상의 것을 포기하는 것입니다. 이느 개발자로서 몇 가지 이점을 얻을 수 있습니다. 처음에는 클래스가 어떤 객체가 생성되는지에 대한 제어권을 포기하는 것이 불리한 것처럼 보일 수 있지만, 제어권을 잃는 것이 아니라 다른 곳으로 옮기는 것일 뿐입니다. 개발자는 종속성에 대한 클래스의 제어권을 제거함.. Dependency Injection - What to inject and what not to inject 이전 섹션에서는 DI에 대해 생각하게 만드는 동기를, 또 느슨한 결합이 얼마나 중요한지와 인터페이스에 대한 프로그래밍이 어떻게 초석이 되는지 설명했습니다. 느슨한 결합이 이점이 있다고 확신한다면 모든 것을 느슨하게 결합하고 싶을 수도 있습니다. 전반적으로 좋은 생각입니다. 모듈을 패키징하는 방법을 결정해야 할 때 느슨한 결합은 특히 유용합니다. ***하지만 모든 것을 추상화하여 플러그형으로 만들 필요는 없습니다. *** 이 섹션에서는 종속성을 모델링하는 방법을 결정하는 데 도움이 되는 몇 가지 의사 결정 도구를 소개합니다. 모든 종속성을 동일하게 취급할 필요는 없습니다. 위험을 초래하지 않는 유형과 애플리케이션의 결합 정도를 강화할 수 있는 유형을 구분하는 방법을 아는 것이 중요합니다. 주로 후자에 집중.. 새로운 퀘스트가 추가되었습니다. 지난 수요일에 글또 커피챗을 진행하면서 여러 주제로 대화를 나눴다. 그러다 문득 사이드 프로젝트 얘기가 나왔는데, 바빠서 잊고 있었던 앱이 생각이 났다. 이따금 생각이 나는 그 앱은, 나의 20대 중반부터 후반까지 열정과 애정을 아낌없이 쏟아부었던 앱이었다. 언젠가 다시 고쳐서 새로 올려야지 올려야지 하면서도 이제는 예전만 못한 열정과 실행력 때문에 여전히 올드한 UI/UX 그대로인 앱. 이 앱은 내게 많은 경험을 하게 해줬기 때문에 아직도 내 인생에서 잊지 못할 추억 중 하나이기도 하다. 생각이 난 김에 아주 오랜만에 개인 계정으로 앱스토어를 로그인했다. 2014년 5월 8일. 내가 만든 첫 앱이 앱스토어에 등록된 그날을 아직도 잊지 못한다. 혹시나 잘못된 부분이 있을까 몇 번이나 체크하고 심사를 요청.. DependencyInjection : (간단한 예제와 DI 이점) 수많은 프로그래밍 교과서의 전통에 따라 화면에 "Hello DI!"를 출력하는 간단한 콘솔 애플리케이션을 구성해보겠다. 또 DI가 주는 이점에 대해 설명하려 한다. 한 줄의 코드로 작성된 Hello World 예제를 본 적이 있을것이다. 그 쉬운 예제를 여기서는 좀 더 복잡하게 만들어 보겠다. Collaborators 프로그램의 구조는 아래와 같다. 플랫폼/언어와 상관없이 이해를 돕도록 Main메서드를 예시로 든다. func Main() { let wirter: IMessageWriter = ConsoleMessageWriter() let salutation = Salutation(writer) salutation.exclaim() } 콘솔에 메시지를 출력하는 기능을 캡슐화한 IMessageWriter.. DependencyInjection - What, Why, and How(Understanding Perpose of DI, Petterns) Understanding Perpose of DI 앞선 게시물 에서 말했듯 DI는 최종 목표가 아니라 목적을 위한 수단일 뿐이다. DI는 느슨한 결합을 가능하게 하고 이는 코드를 더 쉽게 유지관리 할 수 있게 만든다. 이 중요한 메시지를 전달하기 위해 소프트웨어 설계와 몇 가지 설계패턴을 전기 배선과 비교해 보겠다. 매우 쉬운 비유를 들 예정이므로 비전문가에게 소프트웨어 설계를 설명할 때도 이 비유를 사용하면 좋다. 아래에서 설명하겠지만 이 비유에서는 네 가지 특정 디자인 패턴을 자주 언급할 것이다. 그 이유는 이패턴들이 DI와 관련하여 자주 발생하기 때문이다. 이 책에서는 이 중 세 가지 패턴인 데코레이터, 컴포지트, 어댑터 에 대한 예시를 많이 볼 수 있다. Checking Into a Cheap H.. DependencyInjection - What, Why, and How (DI에 대한 오해) 재작년 부터였던가. 매번 읽자 읽자 하다가 내용도 어렵고 너무 방대한 분량 때문에 미뤘던 책 Dependency Injection Principles Practices and Patterns (종속성 주입 원칙 사례 및 패턴) 을 드디어 읽기 시작했다. 사실 영문으로 되어 있기 때문에 번역기로 돌려서 읽는 중이지만… 한글로 번역된 문장들도 쉽게 읽히지 않는것은 내 머리의 한계를 탓할수 밖에 없다. 어쨌거나. 이 ‘의존성 주입’ 카테고리에 포스팅할 내용들은 Dependency Injection Principles, Practies, and Patterns 을 번역, 요약한 글들과 마치 책에 실린 내용인것 마냥 위장하고 있는 내 의견이 있을 예정이다. 시작은 조금 쉬운 내용으로 시작한다. The Depend.. 클린아키텍처 적용하기-03 몇가지 팁과 고민들 클린아키텍처 적용하기-02 테스트 이전 글에 이어서 마무리하는 글. Repository은 그저 중간자 역할뿐인가? 꼭 필요한가? 데이터 엑세스를 하는 Datasource와 UseCase를 연결하기 위한 adaptor 역할이라고 볼 수 있습니다. Datasource와 직접 연결해도 되는것을 불편하게 하나의 과정을 더 밟는게 아닌가 싶지만, 이는 데이터소스의 구체적인 구현 세부사항을 비즈니스 로직으로부터 숨길수 있게 해줍니다. 일관된 인터페이스를 제공해서 비즈니스 로직이 Datasource의 구체적인 구현에 의존하지 않도록 하는것입니다. 때문에 Datasource를 변경하거나 업그레이드 되어도 비즈니스 로직에 영향을 주지 않습니다. 또 데이터 소스로부터 받은 데이터를 애플리케이션이 사용하기 적합한 형태로.. 클린아키텍처 적용하기-02 테스트 클린아키텍처 적용하기-01 개념과 흐름이해 이전 글에 이어서 클린아키텍처를 적용하고 테스트 코드를 어떻게 작성할 수 있는지, 코드를 보고 따라가면서 그 장점을 알아보겠습니다. 클린아키텍처를 적용하고 나니 테스트할때 용이하다는 말이 무엇인지 와닿게 되었습니다. 아래 조금 지루한 내용일테지만 차근 차근 봐주시길 바랍니다. 앱의 버전을 최신 버전과 비교하고 업데이트 필요여부를 확인하는 요구사항이 생겼습니다. 설치버전의 숫자가 현재 앱 버전보다 최신버전이 높은경우 팝업을 띄우고 강제 업데이트(앱스토어 이동)를 진행하고자 합니다. 최신 버전은 LatestVersionDatasource을 채택한 구현체가 서버로부터 값을 받아와서 반환하고 있습니다. protocol LatestVersionDatasource { fu.. 지극히 주관적인 리팩토링 (이벤트로그는 어디에 넣어야하는가?) 회사 프로젝트를 진행하다보면 다양한 코드를 만나게 된다. 작성자의 의도가 분명한 코드도 있는 반면 어느정도 편리함과 타협하여 쉽게 작성한 코드도 보인다. 물론 지극히 내 주관적인 기준으로 판단했을때의 코드이다. 작성자의 분명한 의도를 내가 파악하지 못했을 수도 있다. 요즘 맞닥들인 문제는 내 스타일과 조직내 코딩컨벤션의 갭이 꽤 크다는 것이다. 내가 정답이라는건 아니지만 내가 보고 고쳐야겠다고 생각이 든 코드도 그리 좋아보이지는 않았다. 구성원이 여러명인 조직에 들어온 것은 또 처음이라 내가 적응을 못하고 있는것은 아닐런지, 스스로 생각해보기도 했다. 처음엔 꽤 혼란스러웠지만 이제는 적응이 되었고 어느정도 분위기도 파악되었다. 아래 부터는 내가 생각한 재구성이 필요한 코드가 어떤것이었는지 설명하면서 어떤.. 클린아키텍처 적용하기-01 개념과 흐름이해 배경 최근 진행한 iOS프로젝트에 클린아키텍처를 적용했습니다. 이 글은 클린아키텍처에 대해 학습했던 내용을 복습하고, 실전에 써먹으면서 애매모호 했던 부분들을 나름대로 정리한 글입니다. 배우면서 적용한 첫 프로젝트이기 때문에 중간중간 잘못된 정보가 전달될 수 있으니 이상하다~ 싶은점은 댓글로 남겨주길 바랍니다. 진행했던 프로젝트는 iOS, Android 두 플랫폼에서 동시에 개발이 진행되었습니다. 모바일 아키텍처는 서로 비슷한 부분이 굉장히 많으므로 각 플랫폼 담당자가 아키텍처를 함께 논하고 비즈니스 로직을 맞춘다면 시너지가 있을거라 생각됐습니다. 화면단위로 쪼개어 각 화면에서 필요한 유스케이스를 함께 정의하고 플로우를 맞춘다면 플랫폼이 달라도 담당자끼리 건설적인 대화를 할수 있을거라... 그래서 저와 .. 이전 1 2 3 4 ··· 11 다음
