1. 의존성 주입이란? 의존성 주입(DI, Dependency Injection) 하나의 객체의 다른 객체의 의존성을 제공하는 기술 의존성과 주입 의존성 : 객체 지향에서 두 클래스 간의 관계, 일반적으로 둘중 하나가 다른 하나를 필요로함 class CPU class Computer { private val cpu: CPU init { cpu = CPU() } } 위 코드를 보면 컴퓨터를 생성할 떄 CPU가 강하게 결합한다. 다른 CPU로 변경이 불가능 -> 'Computer가 CPU에 의존성을 갖는다' 주입 : 생성자나 메서드를 통해 외부로 부터 생성자 객체를 전달 받는 것 class CPU class Computer { private var cpu: CPU? = null fun setCPU(cpu: ..
7. 안드로이드 애플리케이션 설계 패턴 (MVC, MVP, MVVM) 일반적인 MVC, MVP, MVVM 디자인 패턴 7.1. MVC 디자인 패턴 Model, View, Controller 로 관심사 분리 안드로이드 플랫폼 등장 초기에 자연스럽게 적용되기 시작 모델의 역할 애플리케이션의 비즈니스 로직, 사용 되는 데이터를 다룸 표현 형식에 의존적이지 않고, 사용자에게 보이지 않아 어떻게 보일지 신경쓰지 않아도됨 비즈니스 데이터 = DBMS에 의해서 관리 몇 함수를 통해서 데이터를 제공, 입력, 수정 안드로이드에서 데이터베이스의 Entity 를 담당하는 POJO 클래스를 포함한 SQLite, Room, Realm 등 [POJO 클래스 예시] data class Employee( var name: Stri..
4. 안드로이드의 특징 일반적인 애플리케이션 하나의 진입점을 가지고, 하나의 프로세스에서 실행 안드로이드 애플리케이션 액티비티, 서비스, 브로드케스트 리시버, 콘텐츠 프로바이더를 대표적인 컴포넌트로 구성 여러 프로세스로 실행가능 진입점 또한 다양 짧은 시간에 여러 어플과 상호 작용 인스타로 사진찍고 카카오톡으로 공유하는 도중에 전화가 걸려오면? 또는 메모리 부족으로 강제 종료되면? 그래도 사용자는 복귀후 작업을 재개하고 싶을 것이다. (이러한 처리를 잘 해주어야함) 컴포넌트의 생명 주기는 안드로이드 시스템이 제어권을 가지기 때문에 데이터 등을 컴포넌트에 저장하는 것은 치명적일 수 있다. 5. 안드로이드 애플리케이션 설계 원칙 액티비티와 프래그먼트의 클래스 의존성을 최소화하는 것이 좋다. 그 반대의 경우 ..
3. 클린 아키텍처 소프트웨어의 관심사를 계층별로 분리하는 소프트웨어 디자인 철학 주요 원칙 : 코드 종속성이 외부로부터 내부로 의존 내부 계층 코드는 외부 계층의 기능을 알 수 없음 외부 계층에 존재하는 변수, 함수, 클래스 등 모든 엔티티는 안쪽 계층에서 다시 등장 불가 데이터 형식도 계층 간에 별도로 유지하는 것이 좋아 가장 추상 적인 영역은 가장 가운데 있는 녀석 비즈니스 로직을 포함. 플랫폼, 프레임워크에 의존하면 안됨 외부 원은 네트워크, 데이터베이스 접근 등 플랫폼에 특정한 구체적 구현 세부사항이 포함됨. 내부로 갈 수록 추상화 캡슐화 수준이 높아짐 장점 : 계층을 분리. 계층 간의 의존성을 단방향으로 유지. 코드의 재사용성 용이 및 유닛 테스트가 쉬워짐 Entities 전사적 비즈니스 규칙..
1. 애플리케이션 설계란? 구성 요소간 유기적 관계를 표현 요구사항 해결을 위한 계획 및 과정 텍스트, 그림, 다이어그램 등으로 표현 애플리케이션은 일단 구현되고 나면 변경하는데 큰 비용이 듦 잘 설계된 어플리케이션은 유지 보수비를 줄여줌. 성능, 보안, 안정성 등 측면에서 많은 이점이 있음 앱의 경우 미래에 나오는 플랫폼 호환성, 정책 등으로 끊임없는 변화에 대한 대응이 필요함 2. 애플리케이션의 설계 원칙 로버트 C. 마틴의 객체지향 프로그래밍 및 설계에 대한 SOLID 원칙 1. 단일 책임 원칙(Single Responsibility Principle) 모든 클래스는 하나의 책임만 가져야하며, 클래스는 그 책임을 완전히 캡슐화해야 함. 어떤 클래스나 모듈 또는 매서드가 단 하나의 기능만을 가져야 한..