블로그명..?

WorkManager? WorkManager는 앱이 종료되거나 재시작되어도 신뢰가능한 비동기 작업을 쉽게 예약할 수 있게 도와주는 API이다. FirebaseJobDispatcher, GcmNetworkManager, Job Scheduler 등의 이전 스케줄링 API들의 대안으로 적합하다. WorkManager는 API 버전 14와 역호환 되는 이전 스케줄링 API들의 특징들을 통합하고 배터리 수명의 지속에도 도움을 줄 수 있다. 특징 작업 제약 조건 네트워크 상태에 따라 작업 제약 조건을 선언할 수 있다. (예를 들어, Wi-fi 상태일 경우 또는 Device가 대기 상태일 경우 또는 어느정도의 저장 공간을 가지고 있는지. 등등) 강력한 작업 예약 WorkManager는 유연한 스케줄링 작업창을 통해..

Dagger란? 수동적으로 의존성 주입을 가진 프로젝트를 구성하려고 하면 프로젝트의 사이즈가 커지고 복잡성이 올라가는 문제가 발생할 수 있는데, 대거를 사용함으로써 코드 복잡성과 프로젝트의 스케일을 획기적으로 제한하는 것이 가능하다. 대거는 클래스에 어노테이션을 붙여주는 것만으로 사용자가 직접 손으로 썼어야할 코드들을 컴파일 타임에 자동으로 생성해준다. Dagger의 이점 다음과 같은 요소들로 보일러플레이트 코드를 줄여준다 수동 DI 섹션에서 수동으로 구현한 AppContainer 코드를 생성한다. application graph에서 사용가능한 클래스의는 Factory를 생성한다. 이를 통해 내부적으로 의존성을 충족해준다. Scope를 설정하여 재사용할 것인지 새로 생성할 것인지 지정해줄 수 있다. Da..

DI 란? Dependency Injection의 약자. 의존성 주입을 뜻함. 특정 객체의 인스턴스를 외부에서 생성하여 전달하는 기법. DI의 장점 재사용성을 높여준다. 테스트에 용이함 코드 가독성 증대 코드 단순화 결합도는 줄이고, 확장성과 유연성을 확보 가능 의존성이란? class AClass { private val b = BClass() fun test(){ b.action() } } class BClass { fun action(){ print("Action B") } } 위 처럼 A 클래스에서 내부에 B클래스의 변수를 사용하게 됨으로써, A클래스는 B클래스에 대해 의존성을 가지게 된다. -> B클래스가 변경되는 경우에 A클래스가 영향을 받게 된다. 주입이란? 클래스 내부가 아닌 외부에서 객체를..

REP(Reuse/Release Equivalence Principle) - 재서용/릴리스 등가 원칙 CCP(Common Closure Principle) - 공통 폐쇄 원칙 CRP(Common Reuse Principle) - 공통 재사용 원칙 REP: 재사용/릴리스 등가 원칙 재사용 단위는 릴리스 단위와 같다. 소프트웨어 컴포넌트가 릴리스 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부여되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 할 수도 없고, 하지도 않을 것이다. 릴리스 번호를 통해 재사용 컴포넌트들이 서로 호환되는지 알 수 있다. 개발자들은 릴리스 변경사항을 살펴보고 이를 적용할지 결정할 수 있다. 이 원칙은 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 ..

SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해준다. 큰 빌딩과 마찬가지로 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다. 컴포넌트는 배포 단위다. 컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다. 예시) 자바 - jar 루비 - gem 닷넷 - DLL 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있다. 또는 여러 컴포넌트를 서로 묶어서 .war 파일과 같은 단일 아카이브로 만들 수도 있다. 또는 컴포넌트 각각을 .jar나 .dll 같이 동적으로 로드할 수 있는 플러그인이나 .exe 파일로 만들어서 독립적으로 배포할 수도 있다. 잘 설계된 컴포넌트는 반드시 독립적으로 배포 가능한, 따라서 ..

의존성 역전 원칙에서 말하는 '유연성이 극대화된 시스템'이란 소스코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템이다. 자바와 같은 정적 타입 언어에서 이 말은 use, import, include 구문은 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야 한다는 뜻이다. 구체적인 대상에는 절대로 의존해서는 안 된다. 루비나 파이썬 같은 동적 타입 언어에도 동일한 규칙이 적용된다. 소스 코드 의존 관계에서 구체 모듈은 참조해서는 안 된다. 하지만 이들 언어의 경우 구체 모듈이 무엇인지를 정의하기가 힘들다. 호출할 함수가 구현된 모듈이라면 참조하지 않기가 특히 어렵다. 이 아이디어는 확실히 비현실적이다. 소프트웨어 시스템이라면 구체적인 많은 장치에 의존하기 때문이다. 예를 들어 자바의..

인터페이스 분리 원칙은 위 다이어그램에서 유래했다. 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다. User1은 오직 op1을 User2는 op2만을, User3는 op3만을 사용한다고 가정해보자. 그리고 OPS가 정적 타입 언어로 작성된 클래스라고 해보자. 이 경우 User1에서는 op2와 op3를 전혀 사용하지 않음에도 User1의 소스 코드는 이 두 메서드에 의존하게 된다. 이러한 의존성으로 인해 User1과 관련된 코드는 변경되지 않았어도 OPS 클래스에서 op2의 소스 코드가 변경되면 User1도 다시 컴파일 후 새로 배포해야 한다. 이러한 문제는 아래처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다. User1의 소스 코드는 U1Ops에 의존하지만 OPS에는 전혀 의존하지 않..

1988년 바바라 리스코프는 하위 타입을 아래와 같이 정의했다. S 타입의 객체(o1), 각각에 대항하는 T 타입 객체(o2)가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다. 상속을 사용하도록 가이드하기 위 License라는 클래스는 calcFee()라는 메서드를 가지며, Billing 애플리케이션에서 이 메서드를 호출한다. License에는 PersonalLicense와 BusinessLicense라는 두 가지 '하위 타입'이 존재한다. 이들 두 하위 타입은 서로 다른 알고리즘을 이용해서 라이선스 비용을 계산한다. 위 설계는 LSP를 준수한다. Billing 애플리케이션의 행위가 License 하위 타입..