다크모드 적용기

개발/안드로이드 2021. 10. 14. 20:00 Posted by 아는 개발자

최근 기존 프로젝트에 다크모드를 적용하는 일을 진행했었다. 꽤 오랜 시간이 소요될 줄 알았지만 안드로이드에서 제공하는 기능을 통해서 생각보다 빠르게 적용할 수 있었다. 이번 포스트에서는 다크모드를 적용하면서 유용했던 기능을 정리해봤다.

 

0. 동일한 이름으로

 

다크모드를 적용할 때 주요하게 변경하는 부분은 텍스트 색깔, 그림 파일 형태의 앱 내 아이콘, XML로 생성한 그림 파일(사각형이나 그라데이션 등등) 이다. 다크모드를 적용하더라도 각각의 파일 이름은 그대로 가져가야 앱 내에서 수정하는 부분을 최소화 할 수 있기 때문에 리소스의 이름은 동일하게 유지하고 라이트모드, 다크모드 각각의 상태에서는 다른 파일을 사용하도록 진행했다.

 

1. 아이콘 리소스 분리

 

안드로이드에서는 리소스 폴더에 키워드를 넣어서 앱의 Configuration에 따라 다른 리소스를 사용하도록 설정할 수 있다. 해상도에 따라서 다른 아이콘을 적용하고 싶은 경우에는 drawable-xhdpi, drawable-xxhdpi 이런식으로 적용할 수 있는데 다크모드를 사용하는 경우에는 night 키워드를 넣어서 분기할 수 있다. drawable-night-xhdpi 이런 형태의 폴더를 만들면 xhdpi 해상도에서 다크모드인 경우에 이 폴더의 아이콘을 사용하게 된다.

 

추가한 폴더

 

2. 색상 분리 작업

 

라이트모드에서 다크 모드로 전환 할 때 색깔별로 어느정도 규칙이 생긴다. 예를 들면 라이트 모드에서 검은색 텍스트를 사용했다면 다크 모드에서는 흰색으로 바뀌게 된다. 나의 경우엔 이 부분에 대해선 디자인 팀에서 가이드라인을 받았고 규칙에 맞게 모드에 따라서 색상 파일로 분리한 다음에 각각의 리소스에 등록해주었다.

 

색상 정보를 가지고 있는 파일은 colors.xml 이었고 values 폴더 내에 있었다. 아이콘과 마찬가지로 이 폴더도 values-night로 하면 다크모드일때만 바라보는 폴더를 만들 수 있었다. 이 안에 colors.xml 을 추가하고 동일한 색상 이름이 다른 hexa 값을 가지도록 변경했다.

 

<!-- values/colors.xml -->

    <color name="hashtag_selected">#07c3ff</color>
    
<!-- values-night/colors.xml -->

    <color name="hashtag_selected">#404245</color>

 

이렇게 구분한 색상 값을 뷰 클래스에 적용하면 모드의 상태에 따라 다른 색상을 보여줄 수 있다. 텍스트뷰나 XML로 만든 그림 파일에도 동일하게 적용 가능하다. 

 

<shape xmlns:android="http://schemas.android.com/apk/res/android"
    android:shape="rectangle">
    <solid android:color="@color/hashtag_selected" />
    <corners android:radius="18dp" />
</shape>
728x90

'개발 > 안드로이드' 카테고리의 다른 글

다크모드 적용기  (0) 2021.10.14
RxJava - Disposable Deep Dive!  (0) 2021.09.17
RxJava dispose()  (0) 2021.09.16
ListAdapter, DiffUtil  (0) 2021.08.20
Coroutine + Retrofit | Coroutine + Room  (0) 2021.07.22
suspend fun  (0) 2021.07.22

Kafka - Event Streaming Platform

기술 2021. 10. 13. 20:30 Posted by 아는 개발자

 

Event Streaming Platform

 

Kafka를 간단히 설명하면 Event Streaming Platform이다. 그래서 Kafka에 대해서 이해하려면 먼저 Event Streaming Platform이 무엇인지 먼저 이해할 필요가 있다. Kafka 공식 문서에서는 Event Streaming을 다음과 같이 정의한다. 

 

Technically speaking, event streaming is the practice of capturing data in real-time from event sources like databases, sensors, mobile devices, cloud services, and software applications in the form of streams of events; storing these event streams durably for later retrieval; manipulating, processing, and reacting to the event streams in real-time as well as retrospectively; and routing the event streams to different destination technologies as needed. Event streaming thus ensures a continuous flow and interpretation of data so that the right information is at the right place, at the right time.

 

간단히 요약하면 다양한 비즈니스 로직에서 발생하는 이벤트 데이터들을 적합한 장소에 실시간으로 전달해줄 수 있는 기술을 Event Streaming 이라고 한다. Kafka 는 Event Streaming을 지원하기 위해 세가지 핵심 기능을 제공한다. 

 

- 다른 시스템에서 이벤트를 배포하고(write) 구독할 수 있다(read) 

- 사용자가 원할 때 까지 Stream을 견고하게 저장할 수 있다

- Event stream 각각은 발생할 때마다 처리할 게 한다. 

 

그리고 모든 기능은 분산화되고 확장가능하며 장애 복구가 가능하고(Faule Tolerant) 보안이 제공되는 형식이다. 카프카는 순수 하드웨어, 가상 머신, Container에 설치가 가능하다. 

 

Main Concepts and Terminology 

 

Event 

 

비즈니스에서 일어난 어떤 일에 대한 기록이다. Kafka에 데이터를 발행하거나 구독할 때 Event의 형태를 사용하게 된다. 개념적으로 이벤트는 키, 값, 시간, 그리고 추가데이터로 구성된다.

카프카 공식 문서에서 예시로 든 이벤트

Producers

 

Kafka에 이벤트를 발행하는 클라이언트 애플리케이션이다. 

 

Consumer

 

Producer에서 추가한 이벤트를 처리하고 구독하는 주체다 .

 

Producers - Consumer 

 

Producer와 Consumer는 완전히 분리되는데 이는 Kafka가 높은 확장성을 가질 수 있는 핵심 디자인 요소다. 예로 들면 이렇게 분리된 형태 덕분에 Producer는 Consumer를 기다리지 않고도 새로운 이벤트를 발행 할 수 있게 된다.

 

Topic 

 

이벤트가 조직화되고 저장되는 장소다. 간단하게 설명하면 파일시스템의 폴더이며 이벤트는 이 폴더 내의 파일로 존재한다. 예로 Topic의 이름은 payments가 될 수 있다. Topic은 내부에 이벤트를 추가할 수 있는 여러개의 Producers를 가질 수 있으며 마찬가지로 이벤트를 구독 할 수 있는 여러개의 Consumer를 가질 수 있다.

 

Topic은 Partition 돼있는데 여러개의 다른 Kafka broker의 Bucket을 저장할 수 있는 형태로 되있다. 이렇게 분산화된 데이터 저장은 확장성에 매우 중요한데 왜냐하면 클라이언트 애플리케이션이 여러개의 Broker로부터 데이터를 읽고 쓸 수 있게 해주기 때문이다. 새로운 event가 Topic에 추가되면 실제로 Topic의 파티션중 하나에 추가된 것이다. 동일한 이벤트 키를 가진 Event는 동일한 Partition에 기록되며 Kafka는 주어진 topic partition의 Consumer는 반드시 해당하는 Partition의 Event를 읽도록 해 Event가 발행된 순서대로 처리할 수 있게 한다. 

 

728x90

'기술' 카테고리의 다른 글

Kafka - Event Streaming Platform  (0) 2021.10.13
JAVA 파일 생성/읽기/쓰기  (0) 2018.11.25
스택, 힙, 코드, 데이터영역  (6) 2018.11.10
VNC와 RDP  (2) 2018.09.12
jupyter notebook 소개  (0) 2018.08.04
URI (Uniform Resource Identifier)  (0) 2018.07.02

RxJava - Disposable Deep Dive!

개발/안드로이드 2021. 9. 17. 20:00 Posted by 아는 개발자

1. Disposable 클래스의 역할

 

 

RxJava 공식 문서에서는 Observable과 Observer의 관계를 위 그림으로 표현한다. Observable에서 데이터를 전달 할 때는 onNext() 함수가, 더이상 전달할 값이 없을 때는 onComplete() 함수가 마지막으로 에러가 발생하면 onError()가 호출되는 방식이다. 이런 설명 방식도 조금 디테일하게 분석해보면 Observable과 Observer 사이에 Disposable 객체를 추가하는 것이 조금 더 정확할 것 같다.

 

 

Disposable 객체는 Observable에서 노출할 자원을 갖고 있고 Observer에게 이벤트로 전달하는 객체다. 그래서 RxJava 내부 소스코드를 분석해보면 첫번째 그림에 보여진 Observabe -> Observer에서 호출되는 함수는 사실 Disposable를 구현한 클래스 객체 내부에서 호출되고 있다. Observable은 Disposable을 생성하기 전까지 스트림을 대신 관리해주는 클래스고 실질적으로 값을 보내는 작업은 Disposable 내부 클래스에서 실행되고 있다.

 

2. 짧은 RxJava 코드

 

구체적으로 설명하기 위해 짧은 RxJava 코드 실행시 생성되는 객체들의 연관관계를 그려봤다. 

 

 

1. Observable.Just 는 단일 아이템을 생성하는 Observable 객체다. 이 객체를 생성하면 ObservableJust가 생성된다. 

2. doOnNext는 앞서 받은 Observable 아이템을 처리하고자 생성하는 루틴인데, 스트림을 유지하고자 ObservableDoOnEach를 만들었다. doOnNext의 내부 루틴은 DoOnEachObserver 객체에서 처리한다. 

3. doOnError도 doOnNext와 마찬가지로 스트림을 유지하고자 ObservableDoOnEach를 만들었다. doOnErro 내부 루틴은 DoOnEachObserver에서 처리한다. 

4. subscribe()가 호출되면 아래 스트림부터 최상단 스트림까지 차례로 구독 관계가 형성된다. ObservableDoOnEach -> ObservableDoOnEach -> ObservableJust 순서로 subscribe가 재귀로 호출되면서 Observer 간의 구독 관계가 완성된다

5. 최상단 ObservableJust는 값 1을 발행하는데 이 이벤트는 ScalarDisposable 에서 담당한다. ObservableJust는 DoOnEachObserver 내부 onSubscribe 함수를 호출해서 스트림 간에 down/upstream 을 구축한다.

6. ScalarDisposable 내부에서는 DoOnEachObserver 내부 onNext 함수를 호출해서 값 1을 전달한다. 

 

3. ScalarDisposable

 

ScalarDisposable 에서 값을 전달하는 부분은 Runnable로 동작하게끔 구현되있다. Observable.just 형태의 스트림을 구독하면 매번 새로운 쓰레드가 생성되서 실행된다.

 

 

4. Memory Leak 가능성

 

다른 Disposable 를 구현한 클래스를 찾아보면 Observable의 역할에 따라서 Runnable인 경우도 있고 Scheduler로 돌리는 경우도 있다. Intervar 처럼 긴 시간 돌리는 작업이면 따로 dispose() 함수를 호출하지 않는 이상 쓰레드가 종료되지 않고 계속 실행된다. 이런 코드가 증가하게 되면 불필요한 쓰레드 개수가 늘어나 Memory Leak이 발생할 소지가 있다. RxJava()를 사용할 때 CompositeDisposable() 객체를 활용해서 dispose() 시키라는 이유가 여기에 있다.

728x90

'개발 > 안드로이드' 카테고리의 다른 글

다크모드 적용기  (0) 2021.10.14
RxJava - Disposable Deep Dive!  (0) 2021.09.17
RxJava dispose()  (0) 2021.09.16
ListAdapter, DiffUtil  (0) 2021.08.20
Coroutine + Retrofit | Coroutine + Room  (0) 2021.07.22
suspend fun  (0) 2021.07.22

RxJava dispose()

개발/안드로이드 2021. 9. 16. 20:00 Posted by 아는 개발자

이번 포스트에서는 RxJava를 사용할때 왜 dispose() 함수를 호출해서 메모리 정리를 해야하는지를 사례를 통해서 정리해보고자 한다.

 

class LeakActivity : AppCompatActivity() {
    private var disposable1 : Disposable? = null

    companion object {
        private const val TAG: String = "leak_activity_tag"
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val observeSource = Observable.interval(1, TimeUnit.SECONDS)
        disposable1 = observeSource.subscribe { Log.d(TAG, "subscriber1 value: $it") }
        observeSource.subscribe { Log.d(TAG, "subscriber2 value: $it") }
    }

    override fun onDestroy() {
        super.onDestroy()
        Log.d(TAG, "onDestroyCalled")
        disposable1?.dispose()
        disposable1 = null
    }
}

 

이 액티비티는 생성하면서 1초 마다 이벤트를 보내는 Observable을 생성하고 두개의 subscriber로 구독하고 있다. 그리고 종료될 때는 첫번째 subscriber만 구독 모델을 해지한다. Activity를 종료하기 전까지는 두 subscriber에서 동시에 로그가 출력되는데

 

2021-09-16 17:48:01.106 subscriber2 value: 0
2021-09-16 17:48:01.106 subscriber1 value: 0
2021-09-16 17:48:02.106 subscriber1 value: 1
2021-09-16 17:48:02.107 subscriber2 value: 1
2021-09-16 17:48:03.106 subscriber2 value: 2
2021-09-16 17:48:03.106 subscriber1 value: 2
2021-09-16 17:48:04.106 subscriber1 value: 3
2021-09-16 17:48:04.106 subscriber2 value: 3

 

액티비티를 종료하고 나면 subscriber2에서 계속 로그가 출력된다. 화면이 없어졌는데도 이벤트를 지속적으로 구독하고 있다.

 

2021-09-16 17:48:44.907 onDestroyCalled
2021-09-16 17:48:45.106 subscriber2 value: 44
2021-09-16 17:48:46.107 subscriber2 value: 45
2021-09-16 17:48:47.106 subscriber2 value: 46

 

심각한 것은 백버튼으로 앱을 종료한 후 다시 실행해도 계속 구독하고 있게 된다는 것이다.  아래 로그를 보면 subscriber2 로그가 두번씩 찍히는데 이것은 이전에 남아있는 액티비티에서 구독한 subscriber가 계속 출력되기 때문이다.

 

2021-09-16 17:50:58.964 subscriber2 value: 0
2021-09-16 17:50:58.964 subscriber1 value: 0
2021-09-16 17:50:59.106 subscriber2 value: 178
2021-09-16 17:50:59.964 subscriber1 value: 1
2021-09-16 17:50:59.965 subscriber2 value: 1
2021-09-16 17:51:00.106 subscriber2 value: 179
2021-09-16 17:51:00.963 subscriber1 value: 2
2021-09-16 17:51:00.963 subscriber2 value: 2
2021-09-16 17:51:01.106 subscriber2 value: 180
2021-09-16 17:51:01.963 subscriber2 value: 3
2021-09-16 17:51:01.963 subscriber1 value: 3
2021-09-16 17:51:02.106 subscriber2 value: 181

 

단발성 이벤트를 구독했다면 큰 문제는 되지 않는다 하지만 위 코드처럼 지속적으로 이벤트를 보낸다면 그리고 subscriber 내부에서 메모리 할당 작업이 포함돼있었다면 메모리 릭이 발생하게 된다. 

728x90

'개발 > 안드로이드' 카테고리의 다른 글

다크모드 적용기  (0) 2021.10.14
RxJava - Disposable Deep Dive!  (0) 2021.09.17
RxJava dispose()  (0) 2021.09.16
ListAdapter, DiffUtil  (0) 2021.08.20
Coroutine + Retrofit | Coroutine + Room  (0) 2021.07.22
suspend fun  (0) 2021.07.22

IoC container and Bean

개발/spring 2021. 9. 6. 21:00 Posted by 아는 개발자

IoC Containner and Bean

 

In Spring, the objects that form the backbone of your application and that are managed by the Spring IoC 
container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a bean is simply one of many objects in your application. Beans, and the dependencies among them, are reflected in the configuration metadata used by a container.

 

IoC Container는 Spring에서 객체 의존성을 대신 관리해주는 플랫폼이고 이 플랫폼 내에서 생성되고(instantiated) 조립되고(assembled) 관리되는(managed) 객체를 Bean 이라고 한다. 간단하게 Bean은 애플리케이션 내에서 존재하느 수 많은 객체인데 Spring Container에서 관리되고 있다고 보면 된다. Spring 을 사용하면 Spring IoC 컨테이너에서 객체의 생성과 의존성 주입을 관리 할 수 있다. 

Application Context

 

The interface org.springframework.context.ApplicationContext represents the Spring IoC container and is responsible for instantiating, configuring, and assembling the aforementioned beans. The container gets its instructions on what objects to instantiate, configure, and assemble by reading configuration metadata. The configuration metadata is represented in XML, Java annotations, or Java code. It allows you to express the objects that compose your application and the rich interdependencies between such objects.

 

ApplicationContext 인터페이스를 통해 Spring IoC container를 만들수 있고, 이 인터페이스는 Bean 객체를 생성하고(instantiating) 설정하고 (configuration) 조립하는 (assembling)한다. 설정 metadata를 읽어서 이 작업을 처리하는데 meta data 포맷은 XML이나 Java 어노테이션 또는 자바 코드를 통해서 가능하다.  

 

Dependencies 

 

Dependency injection (DI) is a process whereby objects define their dependencies, that is, the other objects they work with, only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse, hence the name Inversion of Control (IoC), of the bean itself controlling the instantiation or location of its dependencies on its own by using direct construction of classes, or the Service Locator pattern.

 

Dependency Injection은 객체 간의 의존성을 정의하는 작업인데 즉 다른 객체간 어떻게 일하는지 의존하는 관계를 객체의 생성자나 setter 함수를 통해서 정해줄 수 있다. Container는 Bean 객체를 생성할 때 이 의존성을 대신 주입해준다. 이 과정은 완전히 역전된 관계라서 Inversion of Control 이라고 부른다. Dependency Injection을 사용하면 코드가 깔끔해지고 디커플링도 효율적으로 수행할 수 있게돼 결과적으로 클래스가 테스트하기 쉬워진다.

 

DI 방법은 생성자를 이용하는 방법과 Setter 함수 기반이 있다.

 

 

https://docs.spring.io/spring-framework/docs/3.2.x/spring-framework-reference/html/beans.html

 

5. The IoC container

The BeanFactory provides the underlying basis for Spring's IoC functionality but it is only used directly in integration with other third-party frameworks and is now largely historical in nature for most users of Spring. The BeanFactory and related interfa

docs.spring.io

 

728x90

'개발 > spring' 카테고리의 다른 글

IoC container and Bean  (0) 2021.09.06
@Bean vs @Component  (0) 2021.09.06
Node.js vs Spring Boot  (5) 2021.03.13
Spring 테이블 칼럼이 아닌 필드 데이터 받아오기  (0) 2021.03.05

@Bean vs @Component

개발/spring 2021. 9. 6. 20:00 Posted by 아는 개발자

Spring IoC 컨테이너 내에서 관리하는 객체들을 Bean 이라고 하고 Bean으로 사용 될 수 있는 객체는 XML이나 코드상에서 지정이 가능하다. 어노테이션을 사용하는 경우 @Bean, @Conponent 같은 어노테이션을 이용해 Spring IoC 컨테이너에 클래스를 객체로 등록할 수 있다. 

 

@Bean 

 

@Bean 어노테이션은 method 레벨 어노테이션으로 개발자가 수정할 수 없는 3rd 라이브러리 객체를 IoC Container에 등록하고 싶을 때 사용한다. 예를 들면 아래 코드처럼 애플리캐이션 전체에서 공통적으로 사용하고 싶은 Kafka 클래스를 만드려는 경우 아래와 같은 코드로 Bean을 등록 할 수 있다. @Bean을 사용할 때는 @Configuration 어노테이션이 추가된 클래스 내부에서 생성 할 수 있다. 

 

@Configuration
public class KafkaConfig {
    ...
    @Bean
    public KafkaTemplate<String, String> kafkaTemplate() {
        return new KafkaTemplate<>(producerFactory());
    }

 

@Component 

 

@Component는 개발자가 직접 작성한 클래스를 Bean으로 등록할 수 있는 방법이다. 아래 코드처럼 공통적으로 사용하고 싶은 클래스가 있다면 클래스 이름 위에 @Component 어노테이션을 붙여준다. 

 

@Component
class Utils {
   fun print() { }
}

 

차이점

 

@Bean과 @Component를 헷갈릴 수 있는데 Third party 라이브러리를 Bean으로 등록하는 경우에는 @Bean을 사용하고 그렇지 않은 경우에는 @Component로 사용한다고 생각하면 쉽다. 사실 이럴수 밖에 없는 것이 @Component는 클래스 이름 위에서 선언이 가능한데 Third party 라이브러리는 클래스 수정이 불가능하므로 method level 어노테이션인 @Bean을 사용할 수밖에 없다.

728x90

'개발 > spring' 카테고리의 다른 글

IoC container and Bean  (0) 2021.09.06
@Bean vs @Component  (0) 2021.09.06
Node.js vs Spring Boot  (5) 2021.03.13
Spring 테이블 칼럼이 아닌 필드 데이터 받아오기  (0) 2021.03.05

오브젝트 리뷰 - 7

카테고리 없음 2021. 8. 29. 13:34 Posted by 아는 개발자

다형성

 

다형성 

 

강제다형성은 언어가 지원하는 자동적인 타입 변환이나 사용자가 직접 구현한 타입 변환을 이용해 동일한 연산자를 다양한 타입에 사용할 수 있는 방식을 가리킨다.

 

매개변수 다형성은 제너릭 프로그래밍과 관련이 높은데 클래스의 인스턴스 변수나 메서드의 매개변수 타입을 임의의 타입으로 선언한 후 사용 시점에 구체적인 타입으로 지정하는 방식을 가리킨다. 

 

포함 다형성은 메시지가 동일하더라도 수신한 객체의 타입에 따라 실제로 수행되는 행동이 달라지는 능력을 말한다. 객체지향 프로그래밍에서 가장 널리 알려진 형태의 다형성이다. 포함다형성을 위한 전제 조건은 자식 클래스가 부모 클래스의 서브타입이어야 한다는 것이다. 상속의 진정한 목적은 코드 재사용이 아니라 닿령성을 위한 서브타입 계층을 구축하는 것이다

 

상속의 양면성 

 

상속의 목적은 코드 재사용이 아니라 프로그램을 구성하는 개념들을 기반으로 다형성을 가능하게 하는 타입 계층을 구축하기 위한 것이다. 타입 계층에 대한 고민 없이 코드를 재사용하기 위해 상속을 사용하면 이해하기 어렵고 유지보수하기 버거운 코드가 만들어질 확률이 높다. 

 

자식 클래스 안에 상속받은 메서드와 동일한 시그니처의 메서드를 재정의해서 부모 클래스의 구현을 새로운 구현으로 대체하는 것을 메서드 오버라이딩이라고 하고 부모 클래스에서 정의한 메서드와 이름은 동일하지만 시그니처는 다른 메서드를 자식 클래스에 추가하는 것을 메서드 오버로딩이라고 부른다. 

 

업캐스팅과 동적 바인딩 

 

부모 클래스 타입으로 선언된 변수에 자식 클래스의 인스턴스를 할당하는 것이 가능하다. 이를 업캐스팅이라고 한다. 

 

선언된 변수 타입이 아니라 메시지를 수신하는 객체의 타입에 따라 실행되는 메서드가 결정된다. 객체지향 시스템이 메시지를 처리할 적절한 메서드를 컴파일 시점이 아니라 실행 시점에 결정하기 때문이다. 이를 동적 바인딩이라고 한다. 

 

반대로 코드를 작성하는 시점에 호출할 코드가 결정되는 경우. 컴파일 타임에 호출할 함수를 결정하는 방식을 정적 바인딩 또는 컴파일타임 바인딩이라고 부른다. 

 

상속대 위임 

 

자신이 수신한 메시지를 다른 객체에게 동일하게 전달해서 처리를 요청하는 것을 위임(delegation)이라고 부른다. 위임은 본질적으로 자신이 정의하지 않거나 처리할 수 없는 속성 또는 메서드의 탐색 과정을 다른 객체로 이동시키기 위해 사용한다. 이를 위해 위임은 항상 현재의 실행 문맥을 가리키는 self 참조를 인자로 전달한다. 이것이 self 참조를 전달하지 않는 포워딩과 위임의 차이점이다.

 

서브클래싱과 서브타이핑

 

타입 

 

프로그래밍 언어의 관점에서 타입은 호출 가능한 오퍼레이션의 집합을 정의한다. 객체지향 프로그래밍에서 오퍼레이션은 객체가 수신할 수 있는 메시지를 의미한다. 따라서 객체의 타입이란 객체가 수신할 수 있는 메시지의 종류를 정의하는 것이다. 객체지향 프로그래밍에서 타입을 정의하는 것은 객체의 퍼블릭 인터페이스를 정의하는 것과 동일하다.

 

타입 계층 

 

타입 계층을 구성하는 두 타입 간의 관계에서 더 일반적인 타입을 슈퍼타입이라고 부르고 더 특수한 타입을 서브타입이라고 부른다. 객체지향 프로그래밍에서 객체의 타입을 결정하는 것은 퍼블릭 인터페이스다. 일반적인 타입이란 비교하려는 타입에 속한 객체들의 퍼블릭 인터페이스보다 더 일반적인 퍼블릭 인터페이스를 가지는 객체들의 타입을 의미한다. 

 

서브클래싱과 서브타이핑

 

타입 계층의 의미는 행동이라는 문맥에 따라 달라질 수 있다. 올바른 타입 계층이라는 의미 역시 문맥에 따라 달라질 수 있다. 따라서 슈퍼타입과 서브타입 관계에서는 is-a 보다 행동 호환성이 더 중요하다. 어떤 두 대상이 is-a 라고 표현할 수 있더라도 상속을 사용할 예비후보 정도로만 생각해야한다. 

 

타입의 이름 사이에 개념적으로 연관성이 있다고 하더라도 행동에 연관성이 없다면 is-a 관계를 사용하지 말아야 한다. 행동 호환 여부를 판단하는 기준은 클라이언트 관점이다. 클라이언트 관점에서 두 타입이 동일하게 행동할 것이라고 기대한다면 두 타입을 타입 계층으로 묶을 수 있다. 그렇지 않다면 두 타입을 타입 계층으로 묶어서는 안된다. 

 

서브클래싱은 다른 클래스의 코드를 재사용할 목적으로 상속을 사용하는 경우를 가리킨다. 구현상속 또는 클래스상속이라고 부른다. 서브타이핑은 타입 계층을 구성하기 위해 상속을 사용하는 경우를 가리킨다. 부모 클래스는 자식 클래스의 슈퍼타입이 되고 자식 클래스는 부모 클래스의 서브타입이 된다. 인터페이스 상속이라고 부르기도 한다.  서브타이핑과 서브클래싱을 나누는 기준은 상속을 사용하는 목적이다. 

 

서브타이핑 관계가 유지되기 위해서는 서브타입이 슈퍼타입이 하는 모든 행동을 동일하게 할 수 있어야 한다. 어떤 타입이 다른 타입의 서브타입이 되기 위해서는 행동호환성을 만족시켜야 한다. 

 

리스코프 치환 원칙 

 

올바른 상속 관계의 특징을 정의하기 위해 리스코프 치환원칙이 있다. 자식 클래스가 부모 클래스와 행동 호환성을 유지함으로써 부모 클래스를 대체할 수 있도록 구현된 상속관계만을 서브타이핑이라고 볼 수 있다. 

 

상속관계는 클라이언트 관점에서 자식 클래스가 부모 클래스를 대체할 수 있을때만 올바르다.  is-a 관계는 객체지향에서 중요한 것은 객체의 속성이 아니라 객체의 행동이라는 점을 강조한다. 

728x90

ListAdapter, DiffUtil

개발/안드로이드 2021. 8. 20. 09:24 Posted by 아는 개발자

ListAdapter는 RecyclerView.Adapter의 확장기능으로 리스트내에 노출할 아이템의 변경 여부를 백그라운드 쓰레드에서 판단할 수 있는 기능을 제공한다. 생성자에는 DiffUtil.ItemCallback의 구체 클래스를 넘겨주는데 여기서 구현하는 두 함수를 이용해 아이템 변경 유무를 판단한다

 

class BookAdapter() : ListAdapter<Book, RecyclerView.ViewHolder>(object : DiffUtil.ItemCallback<Book>() {
    override fun areItemsTheSame(oldItem: Book, newItem: Book): Boolean {
        return oldItem.isbn13 == newItem.isbn13
    }

    override fun areContentsTheSame(oldItem: Book, newItem: Book): Boolean {
        return oldItem == newItem
    }
}

 

areItemsTheSame 은 두 아이템이 같은 것인지 확인한다. 아이템마다 고유의 id 가 있다면 두 아이템은 같은 것으로 볼 수 있다. 예제처럼 책을 리스트로 노출한다면 isbn이 동일할 때 같은 책인 것으로 볼 수 있다.

 

areContentsTheSame 은 같다고 알려진 두 아이템의 변경 유무를 확인 한다. return 값이 true면 동일한 것이고 false면 변경이 일어난 경우다. 같은 id 를 가졌더라도 클래스 내부의 값이 달라졌다면 변경이 된 것이기 때문에 다른 것으로 본다. 코드상에서처럼 두 객체를 비교해도 되고 성능을 올리려면 변경유무를 판단할 때 사용하는 속성값만 넣어도 된다. 책의 경우에는 책 제목이나 가격 속성을 이용해도 좋을 것 같다.

 

최종적으로 areContentsTheSame 이 false 인 item에 대해서만 onBindVieholder 함수가 호출 된다. Bind 함수 내에 많은 작업을 처리하는 경우 성능 개선에 도움이 될 것 같다.

 

주의사항

 

https://stackoverflow.com/a/50031492

 

ListAdapter not updating item in RecyclerView

I'm using the new support library ListAdapter. Here's my code for the adapter class ArtistsAdapter : ListAdapter<artist, artistsadapter.viewholder="">(ArtistsDiff()) { override fun</artist,>

stackoverflow.com

 

submitList로 리스트를 업데이트 할 때는 리스트 주소값도 바뀌어야 한다. ListAdapter에서 DiffUtil로 사용하는 AsyncListDiffer 클래스는 새로운 리스트가 기존 리스트와 같은 객체인 경우에는 값을 업데이트하지 않는다. 이는 곧 내부에 데이터를 아무리 바꿔도 리스트의 주소값이 동일하면 변경된 값을 화면에 노출시키지 않는다는 의미다. 이럴때는 깊은 복사(list deep copy)를 사용해 완전히 새로운 객체를 만드는 수밖에 없는데, 리스트 내 객체를 빼거나 추가하는 경우가 아니면 리스트 내부 객체까지 깊은 복사를 해야 리스트의 깊은 복사가 된다. 

 

public class AsyncListDiffer<T> {
    private final ListUpdateCallback mUpdateCallback;
    ...
    @SuppressWarnings("WeakerAccess") /* synthetic access */
    public void submitList(@Nullable final List<T> newList,    
            @Nullable final Runnable commitCallback) {
        // incrementing generation means any currently-running diffs are discarded when they finish
        final int runGeneration = ++mMaxScheduledGeneration;

        if (newList == mList) {
            // nothing to do (Note - still had to inc generation, since may have ongoing work)
            if (commitCallback != null) {
                commitCallback.run();
            }
            return;
        }

 

성능을 위한 선택이었겠지만 내부 데이터 변경도 볼 수 없는 어댑터는 사용성이 크게 떨어지는 것 같다.

728x90

'개발 > 안드로이드' 카테고리의 다른 글

RxJava - Disposable Deep Dive!  (0) 2021.09.17
RxJava dispose()  (0) 2021.09.16
ListAdapter, DiffUtil  (0) 2021.08.20
Coroutine + Retrofit | Coroutine + Room  (0) 2021.07.22
suspend fun  (0) 2021.07.22
Single, Maybe, Completable  (0) 2021.07.04

오브젝트 리뷰 - 6

기술/아키텍처 2021. 8. 9. 20:00 Posted by 아는 개발자

유연한 설계

 

개방-폐쇄 원칙 

 

개방-폐쇄 원칙은 런타임 의존성과 컴파일타임 의존성에 관한 이야기다. 개방-폐쇄 원칙을 수용하는 코드는 컴파일타임 의존성을 수정하지 않고도 런타임 의존성을 쉽게 변경할 수 있다. 개방-폐쇄 원칙의 핵심은 추상화에 의존하는 것이다. 올바른 추상화를 설계하고 추상화에 대해서만 의존하도록 관계를 제한함으로써 설계를 유연하게 확장할 수 있다.

 

생성과 사용의 분리

 

유연하고 재사용 가능한 설계를 원한다면 객체와 관련된 두 가지 책임을 서로 다른 객체로 분리해야 한다. 하나는 객체를 생성하는 것이고, 다른 하나는 객체를 사용하는 것이다. 한 마디로 말해서 객체에 대한 생성과 사용을 분리(seprating use from creation)해야 한다.

 

경우에 따라 객체 생성과 관련된 책임만 전담하는 별도의 객체를 추가하고 Client는 이 객체를 사용하도록 만들 수 있다. 이처럼 생성과 사용을 분리하기 위해 객체 생성에 특화된 객체를 FACTORY라고 부른다.

 

의존성 주입 

 

객체가 아닌 외부의 독립적인 객체가 인스턴스를 생성한 후 이를 전달해서 의존성을 해결하는 방법을 의존성 주입이라고 부른다. 의존성 주입은 의존성을 해결하기 위해 의존성을 객체의 퍼블릭 인터페이스에 명시적으로 드러내서 외부에서 필요한 런타임 의존성을 전달할 수 있도록 만드는 방법을 포괄하는 명칭이다. 

 

의존성 주입은 필요한 의존성을 클래스 퍼블릭 인터페이스에 명시적으로 드래너기 때문에 의존성을 이해하기 위해 코드 내부를 읽을 필요가 없어 객체의 캡슐을 단단하게 보호한다. 가급적 의존성을 객체의 퍼블릭 인터페이스에 노출하라. 의존성을 구현 내부에 숨기면 숨길수록 코드를 이해하기도, 수정하기도 어려워진다.

 

상속과 코드 재사용 

 

상속과 중복 코드 

 

중복코드가 가지는 가장 큰 문제는 코드를 수정하는 데 필요한 노력을 몇 배로 증가시킨다는 것이다. 중복 여부를 판단하는 기준은 변경이다. 요구사항이 변경됐을 때 두 코드를 함께 수정해야 한다면 이 코드는 중복이다. 

 

상속은 객체지향 프로그래밍에서 중복을 제거하기 위한 대표적인 방법이다. 상속을 이용해 코드를 재사용하기 위해서는 부모 클래스의 개발자가 세웠던 가정이나 추론 과정을 정확하게 이해해야한다. 이것은 자식 클래스의 작성자가 부모 클래스의 구현 방법에 대한 정확한 지식을 가져야 한다는 것을 의미한다. 따라서 상속은 결합도를 높인다. 그리고 부모 클래스와 자식 클래스 사이의 강한 결합이 코드를 수정하기 어렵게 만든다.

 

취약한 기반 클래스 문제 

 

부모클래스의 변경에 의해 자식 클래스가 영향을 받는 현상을 취약한 기반 클래스 문제라고 부른다. 취약한 기반 클래스 문제는 캡슐화를 약화시키고 결합도를 높인다. 상속은 자식 클래스가 부모 클래스의 구현 세부사항에 의존하도록 만들기 때문에 캡슐화를 약화시킨다. 객체지향의 기반은 캡슐화를 통한 변경의 통제인데 상속은 코드 재사용을 위해 캡슐화의 장점을 희석시키고 구현에 대한 결합도를 높임으로써 객체지향이 가진 강력함을 반감시킨다.

 

 

 

 

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 6  (0) 2021.08.09
오브젝트 리뷰 - 5  (0) 2021.07.27
오브젝트 리뷰 - 4  (0) 2021.07.25
오브젝트 리뷰 - 3  (0) 2021.07.21
오브젝트 리뷰 - 2  (0) 2021.07.12
오브젝트 리뷰 - 1  (0) 2021.07.11

오브젝트 리뷰 - 5

기술/아키텍처 2021. 7. 27. 20:00 Posted by 아는 개발자

https://book.naver.com/bookdb/book_detail.nhn?bid=15007773

 

오브젝트

역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라!객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를

book.naver.com

 

의존성 관리하기 

 

의존성 이해하기 

 

어떤 객체가 예정된 작업을 정상적으로 수행하기 위해 다른 객체를 필요로 하는 경우 두 객체 사이에 의존성이 존재한다고 말한다. 의존성은 방향성을 가지며 항상 단방향이다 (p254)

 

의존성은 전이될 수 있기 때문에 의존성의 종류를 직접 의존성(direct dependency)간접 의존성(indirect dependency)로 나누기도 한다. 직접 의존성이란 한 요소가 다른 요소에 직접 의존하는 경우를 가리킨다. 간접 의존성이란 직접적인 관계는 존재하지 않지만 의존성 전이에 의해 영향이 전파되는 경우를 뜻한다. (p257)

 

런타임 의존성은 실행 시점에 객체 간의 의존성을 뜻한다. 컴파일 타임은 코드 상에서 클래스 간의 의존성을 뜻한다. 런타임 의존성과 컴파일타임 의존성이 다를 수 있다. 유연하고 재사용 가능한 코드를 설계하기 위해서는 두 종류의 의존성을 서로 다르게 만들어야 한다. 런타임 의존성과 컴파일 타임 의존성 사이의 거리가 멀면 멀수록 설계가 유연해진다. (p258)

 

클래스가 사용될 특정한 문맥에 대해 최소한의 가정만으로 이뤄져 있다면 다른 문맥에서 재사용하기가 더 수월해진다. 이를 컨텍스트 독립성이라고 부른다. 설계가 유연해지기 위해서는 가능한 자신이 실행될 컨텍스트에 대한 구체적인 정보를 최대한 적게 알아야한다. (p260)

 

유연한 설계 

 

바람직한 의존성은 재사용성과 관련이 있다. 어떤 의존성이 다양한 환경에서 클래스를 재사용할 수 없도록 제한한다면 그 의존성은 바람직하지 못한 것이다. 컨텍스트에 독립된 의존성은 다양한 환경에서 재사용 될 수 있는 가능성을 열어 놓는다(p265, 266)

 

바람직한 의존성을 가질 때 두 객체는 느슨한 결합도(loose coupling) 또는 약한 결합도를(weak coupling) 가진다고 말한다. 반대로 바람직하지 못한 의존성을 가질 때 두 객체는 단단한 결합도(tight coupling) 또는 강한 결합도(strong coupling)을 가진다고 말한다. (p266)

 

결합도의 정도는 한 요소가 자신이 의존하고 있는 다른 요소에 대해 알고 있는 정보의 양으로 결정된다. 한 요소가 다른 요소에 대해 더 많은 정보를 알고 있을 수록 두 요소는 강하게 결합된다. 반대로 더 적은 정보를 알고 있을 수록 두 요소는 약하게 결합된다. 더 많이 알수록 더 많이 결합된다. 더 많이 알고 있다는 것은 더 적은 컨텍스트에서 재사용 가능하다는 것을 의미한다. 결합도를 느슨하게 만들기 위해선 협력하는 대상에 대해 필요한 정보 외에는 최대한 감추는 것이 중요하다(p267)

 

추상화란 어떤 양상, 세부사항, 구조를 좀더 명확하게 이해하기 위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로써 복잡도를 극복하는 방법이다. 구체 클래스에 비해 추상 클래스는 클라이언트가 알아야하는 지식의 양이 더 적기 때문에 구체 클래스보다 추상 클래스에 의존하는 것이 결합도가 더 낮다. 인터페이스에 의존하면 추상 클래스의 상속 계층을 모르더라도 협력이 가능해진다. 인터페이스 의존성은 협력하는 객체가 어떤 메시지를 수신할 수 있는지에 대한 지식만을 남기기 때문에 추상 클래스보다 결합도가 낮다. 의존하는 대상이 추상적일수록 결합도는 더 낮아진다는 것이 핵심이다. (p268)

 

의존성이 퍼블릭 인터페이스에 노출되는 경우 명시적 의존성이라고 한다. 반대로 퍼블릭 인터페이스에 노출되지 않는 경우 숨겨진 의존성이라고 한다. 의존성이 명시적이지 않으면 클래스를 다른 컨텍스트에서 재사용하기 위해 내부 구현을 직접 변경해야 할 수 있다 (p270, 271)

 

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 6  (0) 2021.08.09
오브젝트 리뷰 - 5  (0) 2021.07.27
오브젝트 리뷰 - 4  (0) 2021.07.25
오브젝트 리뷰 - 3  (0) 2021.07.21
오브젝트 리뷰 - 2  (0) 2021.07.12
오브젝트 리뷰 - 1  (0) 2021.07.11

오브젝트 리뷰 - 4

기술/아키텍처 2021. 7. 25. 15:56 Posted by 아는 개발자

https://book.naver.com/bookdb/book_detail.nhn?bid=15007773

 

오브젝트

역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라!객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를

book.naver.com

 

메시지와 인터페이스 

 

협력과 메시지

 

메시지는 객체 사이의 협력을 가능하게 하는 매개체다. 객체가 다른 객체에게 접근할 수 있는 유일한 방법은 메시지를 전송하는 것뿐이다. 전통적인 방법은 클라이언트-서버 모델이다. 메시지를 전송하는 객체를 클라이언트, 메시지를 수신하는 객체를 서버라 부르며 협력은 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용이다. (p176)

 

객체가 독립적으로 수행할 수 있는 것보다 더 큰 책임을 수행하기 위해서는 다른 객체와 협력해야 한다. 두 객체 사이의 협력을 가능하게 해주는 매개체가 바로 메시지다. (p177)

 

메시지는 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단이다. 한 객체가 다른 객체에게 도움을 요청하는 것을 메시지 전송 또는 메시지 패싱이라고 부른다. 이때 메시지를 전송하는 객체를 메시지 전송자라고 부르고 메시지를 수신하는 객체를 메시지 수신자라고 부른다. 메시지는 오퍼레이션명과 인자로 구성되며 메시지 전송은 여기에 메시지 수신자를 추가한 것이다. (p177)

 

메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저를 메서드라 부른다. 코드 상에서 동일한 이름의 변수에게 동일한 메시지를 전송하더라도 객체의 타입에 따라 실행되는 메서드가 달라질 수 있다. 객체는 메시지와 메서드라는 두 가지 서로 다른 개념을 실행 시점에 연결해야 하기 때문에 컴파일 시점과 실행 시점의 의미가 달라질 수 있다. 이런 메시지와 메서드의 구분은 전송자와 메시지 수신자가 느슨하게 결합될 수 있게 한다. (p178)

 

객체가 의사소통을 위해 외부에 공개하는 메시지의 집합을 퍼블릭 인터페이스라고 부른다. 프로그래밍 언어 관점에서 퍼블릭 인터페이스에 포함된 메시지를 오퍼레이션이라고 부른다. 그에 비해 메시지를 수신했을 때 실제로 실행되는 코드는 메서드라고 부른다. (p179)

 

오페레이션의 이름과 파라미터 목록을 합쳐 시그니처라고 부른다. 오퍼레이션은 실행 코드 없이 시그니처만을 정의한 것이고 메서드는 이 시그니처에 구현을 더한 것이다. (p180)

 

인터페이스와 설계 품질 

 

좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건을 만족해야한다 (p181)

 

디미터 법칙은 객체 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한한다. 오직 하나의 도트만 사용하라는 말로 요약되기도 한다. 디미터 법칙을 따르기 위해서는 클래스가 특정한 조건을 만족하는 대상에게만 메시지를 전송하도록 프로그래밍 해야한다. 디미터 법칙을 따르면 부끄럼타는 코드를 작성할 수 있다. 부끄럼타는 코드란 불필요한 어떤 것도 다른 객체에게 보여주지 않으며 다른 객체의 구현에 의존하지 않는 코드를 의미한다. (p183, 184, 185)

 

디미터 법칙을 만족하지 않은 경우 내부 구조에 대해 물어보고 반환받은 요소에 대해 연쇄적으로 메세지를 전송하는 경우가 생기는데 이런 경우를 기차 충돌(train wreck)이라 한다. 기차 충돌은 클래스의 내부 구현이 외부로 노출됐을 때 나타나는 전형적인 형태다. (p186)

 

훌륭한 메시지는 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야한다. 묻지 말고 시켜라는 이런 스타일의 메시지 작성을 장려하는 원칙이다. 객체의 정보를 이용하는 행동을 객체의 외부가 아닌 내부에 위치시키기 때문에 자연스럽게 정보와 행동을 동일한 클래스 안에 두게 되고 자연스럽게 정보 전문가에게 책임을 할당하게 되고 높은 응집도를 가진 클래스를 얻게 된다 (p186, 187)

 

메서드 이름을 짓는 두번째 방법은 '어떻게'가 아니라 '무엇'을 하는지를 드러내는 것이다. 무엇을 하는지를 드러내는 이름은 코드를 이해하기 쉽고 유연한 코드를 낳는 지름길이다. 무엇을 하는지 드러내도록 메서드의 이름을 짓기 위해서는 객체가 협력 안에서 수행해야 하는 책임에 관해 고민해야한다. 이처럼 무엇을 하느냐에 따라 메서드의 이름을 짓는 패턴을 의도를 드러내는 선택자라고 부른다. (p188, 189, 190)

 

명령 - 쿼리 분리 원칙 

 

어떤 절차를 묶어 호출하도록 이름을 부여한 기능 모듈을 루틴이라 부른다. 루틴은 프로시저와 함수로 구분 되는데 프로시저는 정해진 절차에 따라 내부 상태를 변경하는 루틴이며 함수는 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 종류이다. 명령은 객체의 인터페이스 측면에서 프로시저에 해당하고, 쿼리는 함수에 해당한다. (p202)

 

명령-쿼리 분리 원칙의 요지는 오퍼레이션은 부수효과를 발생시키는 명령이거나 부수효과를 발생시키지 않는 쿼리 중 하나여야 한다는 것이다. 어떤 오퍼레이션도 명령인 동시에 쿼리여서는 안된다. 명령은 상태를 변경할 수 있지만 상태를 반환해서는 안되며 쿼리는 객체의 상태를 반환할 수 있지만 상태를 변경해서는 안된다. (p203)

 

명령-쿼리 분리 원칙은 부수효과를 가지는 명령으로부터 부수효과를 가지지 않는 쿼리를 명백하게 분리함으로써 제한적이나마 참조 투명성의 혜택을 누릴 수 있게 해준다 (p213)

 

객체 분해

 

프로시저 추상화와 데이터 추상화 

 

현대적인 프로그래밍 언어를 특징 짓는 중요한 두 가지 추상화 메커니즘은 프로시저 추상화와 데이터 추상화다. 프로시저 추상화는 소프트웨어가 무엇을 해야하는지를 추상화하고 테이터 추상화는 소프트웨어가 무엇을 알아야 하는지를 추상화한다. (p218)

 

프로시저 추상화를 중심으로 시스템을 분해하기로 결정했다면 기능분해(functional decomposition)의 길로 들어서는 것이다. 기능 분해는 알고리즘 분해라고 부르기도 한다. 데이터 추상화를 중심으로 시스템을 분해하기로 결정했다면 데이터를 중심으로 타입을 추상화(type abstraction)하는 방향과 데이터를 중심으로 프로시저를 추상화 하는 방법(procedure abstraction)중 하나를 선택한다 (p218)

 

프로시저 추상화와 기능 분해

 

전통적인 기능 분해 방법은 하향식 접근법을 따른다. 하향식 접근법이란 시스템을 구성하는 가장 최상위 기능을 정의하고 좀 더 작은 단계의 하위 기능으로 분해해가는 방법을 말한다. (p219)

 

하향식 접근법과 기능분해는 근본적으로 변경에 취약한 설계를 갖는다. 메인 함수를 유일한 정상으로 간주하는 하향식 기능 분해의 경우에는 새로운 기능을 추가할 때마다 매번 메인 함수를 수정해야 한다. (p226, 227)

 

하향식 접근법은 비즈니스 로직을 설계하는 초기 단계부터 입력방법과 출력 양식을 함께 고민하도록 강요한다. 그러나 사용자 인터페이스는 시스템 내에서 가장 많은 변경이 발생하는 부분이므로 수정이 발생하면 상대적으로 변경이 적은 비즈니스 로직까지 영향을 미치게 된다. 근본적으로 변경에 불안정한 아키텍처가 만들어진다. (p229)

 

하향식 접근법의 경우 처음부터 구현을 염두에두기 때문에 자연스럽게 함수들의 실행 순서를 정의하는 시간 제약을 강조한다. 분해를 진행할 수 없어 기능 분해 방식은 중앙집중 제어스타일의 형태를 띨 수 밖에 없다. 이를 해결하기 위해선 시간 제약에 대한 미련을 버리고 좀 더 안정적인 논리적 제약을 설계 기준으로 삼아야 한다. 객체 지향은 삼수 간의 호출 순서가 아니라 객체 사이의 논리적인 관계를 중심으로 설계를 이끌어간다. (p230)

 

모듈 

 

시스템을 모듈 단위로 분해하기 위한 기본 원리로 시스템에서 자주 변경되는 부분을 상대적으로 덜 변경되는 안정적인 인터페이스 뒤로 감춰야 한다는 것이 핵심이다. 모듈 분해는 감춰야 하는 비밀을 선택하고 비밀 주변에 안정적인 보호막을 설치하는 보존의 과정이다. 비밀을 결정하고 모듈을 분해한 후에는 기능 분해를 이용해 모듈에 필요한 퍼블릭 인터페이스를 구현할 수 있다. 모듈은 복잡성과 변경 가능성을 감춰야한다. (p235, 236)

 

모듈은 기능이 아니라 변경의 정도에 따라 시스템을 분해한다. 각 모듈은 외부에 감춰야 하는 비밀과 관련성 높은 데이터와 함수의 집합이다. 따라서 모듈 내부는 높은 응집도를 유지한다. 또한 퍼블릭 인터페이스를 통해서만 통신해야 하므로 낮은 결합도를 유지한다. 모듈에게 있어 핵심은 데이터다. (p239)

 

클래스 

 

명확한 의미에서 클래스는 추상 데이터 타입과는 다르다. 핵심적인 차이는 클래스는 상속과 다형성을 지원하는데 비해 추상 데이터 타입은 지원하지 못한다는 것이다.  타입 추상화를 기반으로 하는 대표적인 기법이 바로 추상 데이터 타입이다. 추상 데이터 타입은 오퍼레이션을 기준으로 여러가지 타입을 나타낼 수 있다. 반면 객체 지향은 타입을 기준으로 오퍼레이션을 묵는다. (p245, 246)

 

실제 내부에서 수행되는 절차는 다르지만 클래스를 이용한 다형성은 절차에 대한 차이점을 감춘다. 다시 말해 객체 지향은 절차 추상화다.

 

 

 

 

 

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 6  (0) 2021.08.09
오브젝트 리뷰 - 5  (0) 2021.07.27
오브젝트 리뷰 - 4  (0) 2021.07.25
오브젝트 리뷰 - 3  (0) 2021.07.21
오브젝트 리뷰 - 2  (0) 2021.07.12
오브젝트 리뷰 - 1  (0) 2021.07.11

Coroutine + Retrofit | Coroutine + Room

개발/안드로이드 2021. 7. 22. 21:00 Posted by 아는 개발자

Coroutine + Retrofit

 

Retrofit 2.6.0 버전부터 suspend 함수로 api를 작성할 수 있게 됐다. 다른 Retrofit 인터페이스처럼 어노테이션을 추가하고 suspend 함수를 추가하면 빌드 될 때 Retrofit 에서 전처리한다. 

 

interface LibraryApi {
    @GET("/1.0/new")
    suspend fun getNew() : BookListResp
}

 

suspend로 쓰였기 때문에, api 를 호출하는 부분에서도 suspend 함수를 받아서 처리할 수 있다. 예로 Repository 인 경우 suspend 함수를 이용해서 아래 코드로 표현이 가능하다. withContext를 받아서 I/O 쓰레드에서 실행하도록 변경해 Main 쓰레드 안전성이 보장됐다.

 

class LibraryRepository(
    private val apiProvider: ApiProvider
) {

    private val libraryApi by lazy { apiProvider.createApi(LibraryApi::class.java) }

    suspend fun loadNew(): BookListResp = withContext(Dispatchers.IO) {
        return@withContext libraryApi.getNew()
    }

 

Coroutine + Room 

 

Room에서 데이터 변화에 따라 UI를 바꾸거나 특정 로직을 실행해야할 때가 있다. Room 에서는 LiveData와 Flow를 이용하는 두가지 방법을 제공하는데, 이 포스트에서는 Flow를 활용한 버전만 다룬다. 

 

@Dao
interface BookSearchDao {
    @Query("select * from BookSearch order by BookSearch.createdAt desc")
    fun selectBookSearchList(): Flow<List<BookSearch>?>
    
class LibraryRepository(
    private val bookSearchDao: BookSearchDao
) {
    suspend fun loadBookSearchHistory(): Flow<List<BookSearch>?> = withContext(Dispatchers.IO) {
        return@withContext bookSearchDao.selectBookSearchList()
    }

 

Dao의 리턴타입을 Flow로 싸고 Repository 에서는 suspend 함수를 이용해 IO 쓰레드에서 실행하도록 변경하고 리턴했다. Flow는 RxJava의 Flowable과 같아서 내부 DB에 변경사항이 생기면 스트림을 따라서 알림을 준다. 

 

class SearchViewModel @Inject constructor(
    private val libraryRepository: LibraryRepository
): ViewModel() {
    fun loadHistory() {
        viewModelScope.launch {
            libraryRepository.loadBookSearchHistory()
                .distinctUntilChanged()
                .collect { list ->
                    searchHistory.value = list ?: listOf()
                }
        }
    }

 

ViewModel에선 loadBookSearchHistory() 함수의 리턴값인 Flow를 viewModelScope 내에서 subscribe 한다. 변화가 있을 때마다 collect 내부의 바디 코드가 실행된다. viewModelScop 으로 실행했기 때문에 ViewModel이 종료되면 subscribe도 자동으로 종료된다.

728x90

'개발 > 안드로이드' 카테고리의 다른 글

RxJava dispose()  (0) 2021.09.16
ListAdapter, DiffUtil  (0) 2021.08.20
Coroutine + Retrofit | Coroutine + Room  (0) 2021.07.22
suspend fun  (0) 2021.07.22
Single, Maybe, Completable  (0) 2021.07.04
Serializable 과 Parcelable  (0) 2021.06.19

suspend fun

개발/안드로이드 2021. 7. 22. 20:00 Posted by 아는 개발자

코틀린에서 추가된 suspend 함수는 Coroutine 내에서만 실행 가능한 함수다. 블로그 글마다 suspend 함수에 대해서 각각 정의가 다른데 나는 suspend 함수를 Coroutine Context를 갖고 있는 함수 정도로 정의하고 싶다.

 

간단한 사용법 

 

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        CoroutineScope(Dispatchers.Main).launch {
            val sum = suspendSum(1, 2) // no compile error  
            Log.d("suspend sum", sum.toString())
        }
        
        suspendSum(1, 2) // compile error
    }

    private suspend fun suspendSum(a: Int, b: Int) : Int {
        return a + b
    }
}

29210-29210/com.kwony.mylib D/suspend sum: 3

 

suspend 함수는 Coroutine Job 내에서 일반 함수처럼 호출이 가능하다. 그런데 외부에서는 부모의 Coroutine Context를 받지 않기 때문에 일반 함수처럼 호출이 안된다. Couroutine Context를 가지고 있는 점을 이용해서 아래 코드처럼 바꿀 수 있다. 

 

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        CoroutineScope(Dispatchers.Main).launch {
            val sum = suspendSum(1, 2)
            Log.d("mainactivity coroutine", Thread.currentThread().name)
            Log.d("mainactivity coroutine", sum.toString())
        }
    }

    private suspend fun suspendSum(a: Int, b: Int) : Int = withContext(Dispatchers.IO) {
        Log.d("mainactivity suspend", Thread.currentThread().name)
        return@withContext a + b
    }
    
    
mainactivity suspend: DefaultDispatcher-worker-2
mainactivity coroutine: main
mainactivity coroutine: 3

 

위 코드를 보면 suspend 함수 body가 withContext로 싸여져 있는 것을 볼 수 있다. 아래 코드를 실행 할 때는 withContext 함수를 이용해 쓰레드를 바꿔서 실행할 수 있다. suspend + withContext를 활용하면 특정 함수에 대해서 실행 쓰레드를 정해 Main 함수를 건드리지 않고 안전하게 실행할 수 있게 된다.

 

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        CoroutineScope(Dispatchers.Main).launch {
            val sum = suspendSum(1, 2)
            Log.d("mainsuspendsum", sum.toString())
        }
    }

    private suspend fun suspendSum(a: Int, b: Int) : Int = withContext(Dispatchers.IO) {
        val deferredSum = async { a + b }
        val deferredZero = async { 0}
        return@withContext deferredSum.await() + deferredZero.await()
    }

 

상황에 따라서 내부에 async 로 새로운 job을 생성해서 실행이 가능하다. suspend 함수는 내부가 Coroutine과 완전히 동일하다고 봐도 된다. 코드를 좀더 간결하게 쓸 수 있는 도구가 될 것 같다.

728x90

'개발 > 안드로이드' 카테고리의 다른 글

ListAdapter, DiffUtil  (0) 2021.08.20
Coroutine + Retrofit | Coroutine + Room  (0) 2021.07.22
suspend fun  (0) 2021.07.22
Single, Maybe, Completable  (0) 2021.07.04
Serializable 과 Parcelable  (0) 2021.06.19
kotlin lateinit, lazy by  (0) 2021.06.05

오브젝트 리뷰 - 3

기술/아키텍처 2021. 7. 21. 19:00 Posted by 아는 개발자

https://book.naver.com/bookdb/book_detail.nhn?bid=15007773

 

오브젝트

역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라!객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를

book.naver.com

Chapter 5 리뷰 

 

책임 주도 설계를 향해 

 

데이터보다 행동을 먼저 결정하라. 객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다. 클라이언트 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 

 

협력이라는 문맥 안에서 책임을 결정하라. 객체에게 할당된 책임의 품질은 협력에 적합한 정도로 결정된다. 객체에게 할당된 책임이 협력에 어울리지 않는다면 그 책임은 나쁜 것이다. 협력에 적합한 책임을 수확하기 위해선 객체를 결정한 후에 메시지를 선택하는 것이 아니라 메시지를 결정한 후에 객체를 선택해야 한다.

 

올바른 객체지향 설계는 클라이언트가 전송할 메시지를 결정한 후에 비로소 객체의 상태를 저장하는 데 필요한 내부 데이터에 관해 고민하기 시작한다. 결록적으로 협력이라는 문맥 안에서 객체가 수행할 책임에 초점을 맞춘다. 

 

책임 할당을 위한 GRASP 패턴 

 

INFORMATION EXPERT

 

객체에게 책임을 할당하는 첫 번째 원칙은 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것이다. GRASP에서는 이를 INFORMATION EXPERT(정보 전문가) 패턴이라고 부른다. 정보 전문가 패턴은 객체가 자신이 소유하고 있는 정보와 관련된 작업을 수행한다는 일반적인 직관을 표현하는 것이며 여기서 말하는 정보는 데이터와는 다르다. 정보를 알고 있다고 해서 정보를 저장하고 있을 필요는 없다.

 

LOW COUPLING, HIGH COHESION

 

책임을 할당할 수 있는 다양한 대안들이 존재한다면 응집도와 결합도의 측면에서 더 나은 대안을 선택하는 것이 좋다. 다시 말해 두 협력 패턴 중에서 높은 응집도와 낮은 결합도를 얻을 수 있는 설계가 있다면 그 설계를 선택해야 한다는 것이다. GRASP에서는 이를 LOW COUPLING(낮은 결합도) HIGH COHESION(높은 응집도) 패턴이라고 부른다. 설계를 진행하면서 책임과 협력의 품질을 검토하는 데 사용할 수 있는 중요한 평가 기준이다.

 

응집도가 낮다는 것은 연관성이 없는 기능이나 데이터가 하나의 클래스 안에 뭉쳐있다는 것을 의미한다. 문제를 해결하기 위해선 변경의 이유에 따라서 클래스를 분리해야한다. 먼저 변경의 이유가 하나 이상인 클래스를 찾는 것으로부터 시작하는 것이 좋다. 변경의 이유를 파악할 수 있는 첫번째 방법은 인스턴스 변수가 초기화되는 시점을 살펴보는 것이다. 응집도가 높은 클래스는 인스턴스를 생성할 때 모든 속성을 함께 초기화 한다. 반면 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화하고 일부는 초기화되지 않은 상태로 남겨져 있다. 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다. 

 

두번째 방법은 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것이다. 모든 메서드가 객체의 모든 속성을 사용하면 응집도가 높다고 볼 수 있으나 속성에따라 그룹별로 나뉜다면 클래스의 응집도가 낮다고 볼 수 있다. 응집도를 높이기 위해서는 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 한다.

 

POLYMORPHISM, PROTECTED VARIATION 

 

변화가 예상되는 불안정한 지점을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라. PROTECTED VARIATION(변경 보호) 패턴은 책임 할당의 관점에서 캡슐화를 설명한 것이다. 클래스를 변경에 따라 분리하고 임터페이스를 이용해 변경을 캡슐화 하는 것은 설계의 결합도와 응집도를 향상시키는 매우 강력한 방법이다. 하나의 클래스가 여러 타입의 행동을 구현하고 있는 것처럼 보인다면 클래스를 분해하고 POLYMORPHISM 패턴에 따라 책임을 분산시켜라. 예측 가능한 변경으로 인해 여러 클래스들이 불안정해진다면 PROTECTED VARIATION 패턴에 따라 안정적인 인터페이스 뒤로 변경을 캡슐화하라. 

 

책임 주도 설계의 대안 

 

최대한 빠르게 목적한 기능을 수행하는 코드를 작성하고 리팩토링 한다.

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 5  (0) 2021.07.27
오브젝트 리뷰 - 4  (0) 2021.07.25
오브젝트 리뷰 - 3  (0) 2021.07.21
오브젝트 리뷰 - 2  (0) 2021.07.12
오브젝트 리뷰 - 1  (0) 2021.07.11
응집도(Cohesion)와 결합도(Coupling)  (0) 2021.07.10

오브젝트 리뷰 - 2

기술/아키텍처 2021. 7. 12. 20:05 Posted by 아는 개발자

https://book.naver.com/bookdb/book_detail.nhn?bid=15007773

 

오브젝트

역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라!객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를

book.naver.com

지난번 글에 이어 리뷰를 추가한다. 

 

협력, 책임, 역할 

 

객체지향 패러다임의 관점에서 핵심은 역할(role), 책임(responsibility), 협력(collaboration) 이다. 객체지향의 본질은 협력하는 객체들의 공동체를 창조하는 것이다. 협력을 구성하기위해 적절한 객체를 적절한 책임을 할당하는 과정이 필요하다 (p73)

 

협력 

 

- 협력이란 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 말한다. (p74)  

- 두 객체 사이의 협력은 하나의 객체가 다른 객체에게 도움을 요청할 때 시작되며 메시지 전송(message sending) 커뮤니케이션으로 이뤄진다. 메시지를 수신한 객체는 메서드를 실행해 요청에 응답한다. (p75)

- 객체는 자신에게 할당된 책임을 수행하던 중에 필요한 정보를 알지 못하거나 외부의 도움이 필요한 경우 적절한 객체에게 메시지를 전송해서 협력을 요청한다. (p76) 

- 객체가 참여하고있는 협력이 객체의 행동을 결정한다. 객체의 상태를 결정하는 것은 객체의 행동이다. 객체의 상태는 그 객체가 행동을 수행하는 데 필요한 정보가 무엇인지로 결정된다. 따라서 객체가 참여하는 협력이 객체를 구성하는 행동과 상태를 모두 결정한다. 협력은 객체를 설계하는데 필요한 일종의 문맥(context)를 제공한다 (p77)

 

책임 

 

- 협력에 참여하기 위해 객체가 수행하는 행동을 책임이라고 부른다. (p78)

- 협력을 설계하는 출발점은 시스템이 사용자에게 제공하는 기능을 시스템이 담당할 하나의 책임으로 보는 것이다. 객체지향 설계는 협력에 필요한 메시지를 찾고 메시지에 적절한 객체를 선택하는 반복적인 과정을 통해 이뤄진다 (p83)

- 객체에게 책임을 할당하는데 필요한 메시지를 먼저 식별하고 메시지를 처리할 객체를 나중에 선택하는것이 중요하다. 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 한다. (p84) 

- 객체를 객체답게 만드는 것은 객체의 상태가 아니라 객체가 다른 객체에게 제공하는 행동이다. (p85) * 여기서 말하는 객체의 상태는 객체가 갖고있는 데이터를 의미하는 것 같다. 

- 책임을 찾고 책임을 담당할 객체를 찾아 책임을 할당하는 방식으로 협력을 설계하는 방식을 RDD(Responsibility DrivenDesign) 이라 부른다 (p83)

 

역할 

 

- 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다. 역할이 중요한 이유는 역할을 통해 유연하고 재사용 가능한 협력을 얻을 수 있기 때문이다. (p86, 87)

- 협력을 구체적인 객체가 아니라 추상적인 역할의 관점에서 설계하면 협력이 유연하고 재사용 가능해진다. 역할의 가장 큰 장점은 설계의 구성요소를 추상화할 수 있다는 것이다. (p92)

- 추상화의 첫번째 장점은 세부사항에 억눌리지 않고도 상위 수준의 정책을 쉽고 간단하게 표현할 수 있다는 것이고 두번째 장점은 설계를 유연하게 만들 수 있다는 것이다. 협력 안에서 역할이라는 추상화를 이용하면 기존코드를 수정하지 않고도 새로운 행동을 추가할 수 있다 (p94)

 

 

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 4  (0) 2021.07.25
오브젝트 리뷰 - 3  (0) 2021.07.21
오브젝트 리뷰 - 2  (0) 2021.07.12
오브젝트 리뷰 - 1  (0) 2021.07.11
응집도(Cohesion)와 결합도(Coupling)  (0) 2021.07.10
클린 아키텍처  (0) 2021.05.20

오브젝트 리뷰 - 1

기술/아키텍처 2021. 7. 11. 15:53 Posted by 아는 개발자

https://book.naver.com/bookdb/book_detail.nhn?bid=15007773

 

오브젝트

역할, 책임, 협력을 향해 객체지향적으로 프로그래밍하라!객체지향으로 향하는 첫걸음은 클래스가 아니라 객체를 바라보는 것에서부터 시작한다. 객체지향으로 향하는 두번째 걸음은 객체를

book.naver.com

 

객체지향 프로그래밍을 다룬 오브젝트를 읽으며 나의 잘못된 과거의 코딩이 생각나던 구절, 나도 모르게 밑줄을 치게 되던 주옥같은 문장, 기억해야할 용어를 정리해본다. 이 책의 모든 내용을 한 포스트에 정리하긴 어려울 것 같고 공부한 날짜별로 메모하고 싶은 내용만 담아본다. 기본적으로 책의 내용을 참조 했지만 공부한 내용을 요약해서 정리하고자 몇몇 문장과 단어를 추가하고 수정했다. 그리고 페이지 별로 주요 문장을 뽑아냈기 때문에 목차별로 전달하고자 하는 핵심 메시지가 누락돼 저자의 의도가 제대로 전달되지 않을 수 있다. 추상적이거나 애매해보이는 보이는 표현은 책을 통해서 확인 바란다.

 

캡슐화의 개념과 목적

 

- 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것. 목적은 변경하기 쉬운 객체로 만드는 것이며, 캡슐화를 통해 객체 내부 접근을 제한하면 객체와 객체 사이의 결합도를 낮아지기 때문에 변경하기 쉬운 객체로 만드는게 가능하다. (p20)

 

응집도가 높은 객체란

 

- 밀접하게 연관된 작업만을 수행하고, 연관성 없는 작업은 다른 객체에게 위임하는 객체. 스스로 자신의 데이터에 책임을 지는 객체가 응집도가 높다고 말할 수 있다. (p26)

 

절차지향 프로그래밍과 객체지향 프로그래밍

 

- 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming)이라 부르며 반대로 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식을 객체지향 프로그래밍(Object-Oriented Programming)이라 한다. (p26) 여기서 프로세스는 처리하는 작업을 담당하는 메서드에 해당하고 데이터는 작업을 처리할 때 필요한 정보를 말한다. 

 

- 절차지향 프로그래밍에서는 별도의 모듈에 프로세스와 데이터가 있기 때문에 의존관계가 높아진다. 반명 객체지향 프로그래밍에서는 연관관계가 있는 프로세스와 데이터가 하나의 모듈에 있기 대문에 의존관계가 낮아진다.

 

훌륭한 객체 지향 설계를 위한 원칙

 

- 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮춘다 (p27)

- 객체지향 설계에서는 독재자가 존재하지 않고 각 객체에 책임이 적절하게 분배된다. 따라서 각 객체는 자신을 스스로 책임진다. (p28)

- 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계 (p34)

- 변경이 쉬우며 협력하는 객체 사이의 의존성을 적절하게 관리 (p36)

 

도메인 

 

- 문제를 해결하기 위해 사용자가 프로그램을 사용하는 분야를 도메인이라 부른다 (p41)

 

- 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체들이 필요한지를 고민한다. 어떤 객체들이 어떤 상태와 행동을 가지는지 우선 결정한다. 그리고 객체를 독립적인 존재가 아니라 기능을 구현하기 위해 협력하는 공동체의 일원으로 봐야한다. (p41) 

 

자율적인 객체 

 

- 객체는 상태와 행동을 가지는 복합적인 존재이며 스스로 판단하고 행동하는 자율적인 존재.  (p44)

- 객체 내부에 대한 접근을 통제해 객체를 자율적인 존재로 만든다. 자율적으로 만드는 것은 외부의 의존성으로부터 자유로워지는 것을 의미한다. (p44) 

- 외부에서 접근가능한 부분을 퍼블릭 인터페이스(public interface)라고 하며 내부에서만 접근 가능한 부분을 구현(implementation)이라 부른다. (p44)

 

객체 간의 협력 

 

- 다른 객체의 인터페이스에 공개된 행동을 수행하도록 요청(Request) 할 수 있고 요청 받은 객체는 자율적인 방법에 따라 응답(Response)한다. (p49)

- 객체끼리 상호작용할 수 있는 유일한 방법은 메시지를 전송하는 것 뿐이다. 다른 객체에게 요청이 도착할 때 해당 객체가 메시지를 수신했다고 이야기한다. 수신된 메시지를 처리하기 위한 자신만의 방법을 메서드라고 한다 (p49)

 

상속과 다형성 

 

- 상속과 인터페이스를 사용하면 컴파일타임 의존성과 실행 시점의 의존성이 다를 수 있다. 클래스 사이의 의존성과 객체사이의 의존성이 동일하지 않을 수 있다. (p59)

- 상속과 인터페이스를 사용하면 코드가 유연해진다. 그러나 유연해진만큼 코드를 이해하고 디버깅하는 것은 어려워진다. 반대로 유연성을 억제하면 재사용과 확장가능성은 낮아진다 (p59) 

- 동일한 메시지를 전송하지만 실행되는 메서드는 수신되는 객체에 따라서 달라진다. 이를 다형성이라 부른다. 다형성은 컴파일 시간 의존성과 실행시간 의존성을 다를수 있는 사실을 기반으로 하며 동일한 메시지를 수신했을 때 객체의 타입에 따라 다르게 응답하는 능력을 말한다. (p 63)

 

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 3  (0) 2021.07.21
오브젝트 리뷰 - 2  (0) 2021.07.12
오브젝트 리뷰 - 1  (0) 2021.07.11
응집도(Cohesion)와 결합도(Coupling)  (0) 2021.07.10
클린 아키텍처  (0) 2021.05.20
DIP(Dependency Inversion Principle)  (0) 2021.05.09

응집도(Cohesion)와 결합도(Coupling)

기술/아키텍처 2021. 7. 10. 12:16 Posted by 아는 개발자

모듈

 

응집도와 결합도를 설명하기 위해선 모듈이라는 단어를 사용해야하는데 모듈은 문맥에 따라서 의미가 달라지는 경우가 많아서 이 글에서는 클래스나 패키지, 라이브러리 같은 프로그램을 이루는 임의의 요소로 정의한다.

 

응집도 

 

모듈을 이루는 요소들의 연관성 척도다. 클래스내의 함수와 변수, 더 큰 범위에선 패키지 내의 개별 클래스가 하나의 목적으로 연관관계가 이뤄질 경우 응집도가 높고 그렇지 않은 경우에는 응집도가 낮은 것으로 판단한다. 응집도가 높을 수록 소프트웨어를 수정 할 경우 변경하게될 범위가 명확해지기 때문에 좋은 설계로 본다. 반대로 응집도가 낮을 수록 소프트웨어를 변경해야하는 이유가 많아지기 때문에 좋은 설계로 보기 어렵다.

 

결합도 

 

소프트웨어를 구성한 여러 모듈은 서로를 호출하는 관계를 가지게 되는데, 각각의 모듈이 서로를 의존하는 정도를 결합도라고 한다. 모듈간의 의존 관계가 생기면 하나의 모듈을 수정할 때 다른 모듈이 영향을 받게 된다. 결합도가 높을 수록 다른 모듈의 변경에 영향을 많이 받게 되고 반대로 낮을 수록 다른 모듈의 변경에 영향이 적게된다. 일반적으로 결합도가 낮을 수록 좋은 설계로 본다.

 

그림 1

 

위 그림에서 각 모듈간 의존 관계가 많다. 특히 모듈E는 A,B,C,D 모듈이 의존하고 있는 모듈이기 때문에 E가 변경된다면 A, B, C, D 모두 영향을 받게 되므로 결합도가 높은 좋지 못한 설계에 해당한다. 이런 경우 유지 보수가 어렵기 때문에 도메인 요구사항에 맞춰서 재설계 하는 편이 좋다.

 

그림 2

 

그림 2는 그림 1의 결합도 문제를 해결한 설계다. E에 의존했던 A,B 는 구조를 변경해 E를 참조하지 않아도 되게끔 수정했다. 또한 A와 D 간의 의존관계도 수정했다. 이전보다 의존 관계가 많이 줄었으므로 결합도가 낮아진 것으로 볼 수 있다. 

 

* 그림 2는 설명을 위한 예시다. 실제로 소프트웨어 상에서 결합도 문제를 해결하기 위한 과정은 이렇게 단순하지 않다.

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 2  (0) 2021.07.12
오브젝트 리뷰 - 1  (0) 2021.07.11
응집도(Cohesion)와 결합도(Coupling)  (0) 2021.07.10
클린 아키텍처  (0) 2021.05.20
DIP(Dependency Inversion Principle)  (0) 2021.05.09
ISP (Interface Segregation Principle)  (0) 2021.05.09

Single, Maybe, Completable

개발/안드로이드 2021. 7. 4. 17:59 Posted by 아는 개발자

RxJava2 들어오면서 Single, Maybe, Completable Observable이 추가됐다. 개발 할 때는 Single만 사용했었는데 이번 포스트에서 자주 쓰지 않은 Maybe, Completable에 대해서 배워보고 앞으로 용도에 맞춰서 사용해보려고 한다.

 

Single 

 

단일의 데이터 보내거나 에러를 내는 Observable이다. 주로 서버로부터 http 데이터를 받아올 때 사용한다. 아래 처럼 단일 데이터 객체인 Post를 받아오는 api를 사용한다면 Single로 Observable을 받고 doOnSuccess에서 받아온 데이터를 열어 볼 수 있다. 에러인 경우에는 doOnError를 실행한다

 

interface RxApi {
    @GET("api/v1/post")
    fun getPost(@Query("postId") postId: Long): Single<Post>
}

apiClient.getPost(postId)
    .doOnSuccess { post ->
        Log.d("rxtest", "post: ${post.postId}")
    }
    .doonError { }
    .subscribe()

 

Maybe 

 

Single처럼 단일의 데이터를 보내는데 빈 값을 보낼 수 있다는 점이 다르다. 서버에서 데이터를 읽는데 너무 오랜 시간이 걸리는 경우나 종종 빈 값을 내려줘야 하는 경우 요긴하게 쓸 수 있다. 빈 값이 내려오는 경우에는 doOnError 가 호출된다.

 

Maybe.empty<Int>()
    .doOnSuccess {
        Log.d("rxjava test", "printed: $it")
    }
    .doOnError { throwable ->
        Log.d("rxjava test", throwable.localizedMessage?: "")
    }
    .subscribe()

 

Completable 

 

함수의 리턴 값은 관심 없고 완료의 유무만 확인하고 싶을 때 사용하는 Observable이다. 서버에 객체를 업데이트하는 요청을 보낸 경우나 로깅용도로 사용하는 경우가 이런 경우에 적합하다.

 

interface RxApi {
    @POST("api/v1/log")
    fun logEvent(@Body param: String): Completable
}

apiClient.logEvent("this is blog post")
    .doOnComplete {
        Log.d("rxjava test", "finished time: ${System.currentTimeMillis()}")
    }
    .subscribe()
728x90

'개발 > 안드로이드' 카테고리의 다른 글

Coroutine + Retrofit | Coroutine + Room  (0) 2021.07.22
suspend fun  (0) 2021.07.22
Single, Maybe, Completable  (0) 2021.07.04
Serializable 과 Parcelable  (0) 2021.06.19
kotlin lateinit, lazy by  (0) 2021.06.05
Kotlin - Coroutine  (0) 2021.05.21

Serializable 과 Parcelable

개발/안드로이드 2021. 6. 19. 14:03 Posted by 아는 개발자

Serializable 

 

Serialization(직렬화)란 자바 시스템 내부에서 사용하는 객체를 외부의 자바 시스템에서도 사용할 수 있도록 byte형태로 데이터를 변환시키는 기술을 말하며 안드로이드 상에선 직렬화를 이용해 액티비티간 또는 서비스간 클래스 타입의 데이터를 주고 받는 용도로 주로 사용한다

 

아래 처럼 Student 클래스를 Serializable 선언 해준다면, 다른 액티비티에 클래스 형태 그대로 값을 전달 해줄 수 있다. Serializaable 선언 외에 추가하는 코드가 없어서 사용하기 정말 편리하다.

 

data class Student(val name: String, val age: Int) : Serializable

val intent = Intent().apply { this.putExtra("student", Student("kwony", 30)) }
startActivity(intent)

 

그러나 Serializable은 byte 형태로 변환된 데이터를 다시 객체의 형태로 변환시키는데 JVM 내부에서 임시 객체를 많이 만들게 되고 이 과정에서 garbage 가 생길 우려가 있다. 안드로이드의 경우에는 배터리 전력을 감소시키기도 한다는데 정확히 어느정도 영향이 있는지 수치가 나온것은 없다. 성능에 미치는 영향이 있다는 점은 기억해둘 필요가 있을 것 같다.

 

Parcelable 

 

자바 시스템 공용인 Serializable과 달리 Parcelable은 안드로이드 SDK에서 포함하는 인터페이스다. Serializable 이 갖고 있는 변환 과정에서의 성능 저하를 보완하기 위해 만들어졌는데 이 방법이 변환하는 부분을 개발자가 직접 하게끔(?) 하는 것이다. 그래서 Parcelable 인터페이스 상속 함수를 구현해야 하는데 아래 코드처럼 구현해야할 게 많아졌다.

 

data class Student(val name: String?, val age: Int) : Parcelable {
    constructor(parcel: Parcel) : this(
        parcel.readString(),
        parcel.readInt()
    )

    override fun describeContents(): Int {
        return 0
    }

    override fun writeToParcel(dest: Parcel?, flags: Int) {
        dest?.writeString(name)
        dest?.writeInt(age)
    }

    companion object CREATOR : Parcelable.Creator<Student> {
        override fun createFromParcel(parcel: Parcel): Student {
            return Student(parcel)
        }

        override fun newArray(size: Int): Array<Student?> {
            return arrayOfNulls(size)
        }
    }
}

 

코틀린을 사용한다면 @Parcelize 어노테이션을 사용하면 추가 함수 구현 없이 사용 가능하다. 몇몇 클래스에서는 어노테이션이 동작하지 않는 경우도 있는데 그럴때만 빼면 쓸만하다.

 

@Parcelize
data class Student(val name: String?, val age: Int) : Parcelable {}

 

Performance

디바이스별로 Serializable과 Parcelable을 사용한 경우를 각각 비교한 그래프다. 그래프만 봐선 Parcelable의 성능이 확실히 뛰어난 것 같다. Real World에선 어떤 차이가 있을지 나온 자료는 아니지만 기억해두면 좋을 그래프 일 것 같다.

728x90

'개발 > 안드로이드' 카테고리의 다른 글

suspend fun  (0) 2021.07.22
Single, Maybe, Completable  (0) 2021.07.04
Serializable 과 Parcelable  (0) 2021.06.19
kotlin lateinit, lazy by  (0) 2021.06.05
Kotlin - Coroutine  (0) 2021.05.21
Android 10 스토리지 정책 대처하기  (0) 2021.05.18

kotlin lateinit, lazy by

개발/안드로이드 2021. 6. 5. 14:59 Posted by 아는 개발자

자바에서 흔히 보게 되는 NullPointerException 문제를 예방하고자 코틀린에서는 변수 선언에서부터 Nullable 변수의 선언부터 엄격하게 관리한다. 변수를 선언 할 때도 Nullable인지 아닌지를 구분해야하고 Nullable인 경우에는 변수를 호출하는 코드에서 Nullsafe 지시자를 표시해야하며 그렇지 않으면 컴파일 단계에서 에러를 발생시킨다.

 

var name: String? = null 
name = "abcd"
name?.length() // name이 여전히 null 일 가능성이 존재하므로, null safe 접근만 허용된다

var name2: String = "abcd"
name2 = null // name2가 nullable하지 않으므로 이 코드는 컴파일 오류가 발생한다

 

 

그런데 코드 상에서는 null이 될 수도 있지만 실제 동작 중에는 null이 될 소지가 없는 경우가 있다. 아래 코드처럼 전역 변수인데 실행과 동시에 초기화를 시키는 경우가 이렇다. 논리적으로는 안전한 코드임에도 불구하고 값에 접근 할 때 null safe 지시자를 표시해야하는 불편함이 생긴다. 

 

class TestActivity: Activity() {
    var name: String? = null
    override fun onCreate() {
        name = "abcd"
        print("${name?.length}")
    }
}

 

lateinit 

 

lateinit을 사용하면 변수의 값을 지정하는 작업을 뒤로 미룰 수 있다. Nullable 하지 않은 변수를 선언하면서 Assign 하는 작업을 뒤로 미루고 싶을때는 lateinit 키워드를 사용하면 가능하면 된다. 아래 코드는 name 변수 앞에 lateinit 키워드를 두고 onCreate 콜백에서 값을 바로 지정했다. 선언 당시 Non-Null String으로 선언했기 때문에 호출할 때 

 

class TestActivity: Activity() {
    lateinit var name: String
    override fun onCreate() {
        name = "abcd"
        print("${name.length}")
    }
}

 

lateinit은 mutable 변수만 가능하기 때문에 var 키워드를 가진 변수에서만 사용이 가능하다. 실행 중에 값을 변경할 필요가 있는 경우 유용하다. 그리고 만약 값을 assign하지 않고 변수 값을 호출하는 경우에는 Kotlin 언어 상에서 에러를 발생시킨다.

 

by lazy 

 

by lazy 키워드는 lateinit과 비슷하게 값을 지정하는 작업을 미루는 작업인데 assign 되는 시점이 변수를 호출하는 시점이다. 아래 코드를 보면 name 변수 선언에 by lazy 키워드가 붙고 내부 브래킷에 "abcd" 코드가 있다. name변수가 호출되는 시점에 "abcd"로 assign 하겠다는 의미다. 실제 코드를 동작시켜보면 name 호출 시점에 by lazy 내부 로그가 먼저 호출되는 것을 볼 수 있다.

 

class Test {
    val name : String by lazy {
        println("this is name by lazy")
        "abcd"
    }

    init {
        println("I am here")
        println(name)
    }
}

// 실행 결과
I am here
this is name by lazy
abcd

 

by lazy는 immutable 변수에서만 적용이 가능해, val 키워드 변수에만 적용이 가능하다. 변수 값을 최초에만 설정하고 변경할 필요가 없는 경우 사용하면 유용하다. 변수 선언시에 값을 assign할 순 없지만 다른 변수들을 조합해 값을 설정하고 싶을 때 사용하면 유용하다.

728x90

'개발 > 안드로이드' 카테고리의 다른 글

Single, Maybe, Completable  (0) 2021.07.04
Serializable 과 Parcelable  (0) 2021.06.19
kotlin lateinit, lazy by  (0) 2021.06.05
Kotlin - Coroutine  (0) 2021.05.21
Android 10 스토리지 정책 대처하기  (0) 2021.05.18
다음 페이지가 살짝 보이는 ViewPager2 만들기  (0) 2021.05.13

멀티쓰레드 동시성

기술/컴퓨터사이언스 2021. 6. 5. 14:06 Posted by 아는 개발자

멀티 쓰레드 환경은 하나의 프로세스 내에 여러 개의 쓰레드가 동작할 수 있는 환경을 말한다. 쓰레드는 고유의 작업을 하면서 쓰레드 내에서 할당된 변수 뿐만 아니라 프로세스 내에 있는 변수에도 접근 할 수 있는데 이때 여러 개의 쓰레드가 같은 데이터에 접근하는 경우 경우에 따라 동시성 문제가 발생할 수 있다. 

 

 

위 그림은 스레드A, B가 프로세스 내에 상주한 정수형 변수 a에 접근하는 경우다. 둘다 read 명령으로 접근 하기 때문에 변수의 값이 변할 염려가 없다. 쓰레드 A, B 모두 변수의 값을 3으로 읽어오기 때문에 예상하지 못한 값을 읽어오게 되는 경우는 없다. 이 경우에는 동시성 문제가 발생하지 않는다.

 

 

그런데 위 그림에선 쓰레드 A가 a의 값을 1만큼 더해주는 작업을 하는데 이때는 접근 순서에 따라서 쓰레드 B가 읽어오게 되는 값이 달라질 소지가 생긴다. 쓰레드 B 가 접근하기 전에 쓰레드 A가 2번 접근했었다면 쓰레드 B는 3이 아닌 5를 값으로 읽어오게 되기도 하고 동시에 접근을 한다면 쓰레드 A가 값을 업데이트 하는 도중 쓰레드 B가 읽어서 변화된 값을 읽지 못하게 되는 우려도 생긴다. 위처럼 여러 개의 쓰레드가 공유된 자원에 접근 할 때 데이터의 신뢰성을 보장받을 수 없는 경우 쓰레드 동시성(Concurrency) 문제라한다.

 

728x90

'기술 > 컴퓨터사이언스' 카테고리의 다른 글

멀티쓰레드 동시성  (0) 2021.06.05
프로스세와 스레드  (0) 2021.06.05
스핀락, 뮤텍스, 세마포어  (0) 2018.11.07
RCU (Read-Copy Update)  (0) 2018.10.30
Cgroup (Control Group)  (0) 2018.09.15
CPU pinning과 taskset  (0) 2018.08.27

프로스세와 스레드

기술/컴퓨터사이언스 2021. 6. 5. 13:42 Posted by 아는 개발자

 

프로세스 (Process)

 

프로세스는 운영체제에서 프로그램을 구성하는 기본 단위다. 현재 글을 쓰고 있는 크롬 웹브라우저, 스마트폰에서 사용중인 넷플릭스, 카카오 앱도 모두 운영체제내에선 프로세스 단위로 이뤄진다. 특정 프로그램의 경우 두개 이상의 프로세스로 이뤄지는 경우도 있으나 하나의 프로세스로 이뤄진 경우가 일반적이다.

 

프로세스는 운영체제 고유 스케줄링에 관리를 받는다. 우리가 스마트폰에서 구글 뮤직 앱으로 음악을 들으면서 카톡을 할 수 있는 것도 구글 뮤직 앱 프로세스와 카톡 프로세스가 운영체제 스케줄링에 의해 관리되기 때문이다. 프로그램이 프로세스의 형태로 이뤄진 것도 어찌보면 운영체제 내에서 동작을 관리하기 위함으로 생각할 수도 있다.

 

쓰레드 (Thread)

 

프로세스내에서 실행되는 작업 단위다. 프로세스의 데이터에 접근 할 수 있고 특정한 작업을 맡길 때 사용한다. 안드로이드의 경우를 예로 들면 대표적으로 화면을 담당하는 UI 쓰레드와 네트워크나 디스크 작업에 쓰이는 I/O 쓰레드가 있다. 각 쓰레드 모두 하나의 프로세스내에서 실행되며 서로 데이터를 공유 할 수 있다.

 

하나의 프로세스에 여러개의 스레드를 두는 경우 멀티 스레드 환경이라고 부르며 동시에 이뤄져야 하는 작업이 있는 경우 이 방식으로 소프트웨어를 구성한다. 예로들면 화면을 업데이트 하면서 파일을 다운받는 경우 하나의 스레드에서 작업한다면 둘 중 하나가 끝나야 다음 작업이 가능한데 각각 별도의 쓰레드를 둔다면 동시에 작업이 가능하다. 그래서 대부분의 프로그램이 멀티 쓰레드 방식으로 구현된다.

 

728x90

'기술 > 컴퓨터사이언스' 카테고리의 다른 글

멀티쓰레드 동시성  (0) 2021.06.05
프로스세와 스레드  (0) 2021.06.05
스핀락, 뮤텍스, 세마포어  (0) 2018.11.07
RCU (Read-Copy Update)  (0) 2018.10.30
Cgroup (Control Group)  (0) 2018.09.15
CPU pinning과 taskset  (0) 2018.08.27

메뉴 리뉴얼

알고리즘/프로그래머스 2021. 5. 29. 18:09 Posted by 아는 개발자

문제 푸는 키 포인트는 두개다.

 

1. 손님들마다 주문한 단품 메뉴 목록에서 가능한 조합을 목록으로 만든다.

 

손님이 최대 주문 할 수 있는 단품 메뉴의 개수가 10개다. 그러면 10개로 만들 수 있는 조합의 개수는 2^10 - 1개. 알고리즘 시험 문제에서 풀 수 있을 만큼의 범위다. 단품의 개수가 2개 이상인 조합만 고려대상이지만 이건 일단 무시하도록 하자.  코딩으로 조합 목록을 만드는 방법은 다양하게 있을텐데 내 경우에는 비트마스크를 사용했다. 만약 손님이 5개를 주문 했다면 총 31가지 조합이 만들어지므로, 1 ~ 31 까지 For 루프를 돌고 각 회차별로 비트를 확인 해서 단품 목록을 포함 시킬 것인지 말 것인지를 결정한다. 

 

for (int i = 0; i < orders.size(); i++) {

    int totalCombnation = (1 << (orders[i].length())) - 1;
    for (int bit = 1; bit <= totalCombnation; bit++) {
        vector<char> orderSet;
        string combi = "";
    
        for (int position = 0; (1 << position) <= bit; position++) {
            if (bit & (1 << position)) {
                orderSet.push_back((char) orders[i][position]);
            }
        }

        sort(orderSet.begin(), orderSet.end());

        for (int i = 0; i < orderSet.size(); i++) {
            combi += orderSet[i];
        }

 

totalCombination은 현재 주문에서 가능한 조합이 가능한 총 개수다. bit는 1에서부터 totalCombination 까지 순회하면서 단품 목록에서 조합이 가능한 쌍의 집합을 의미한다. 조합에 포함할지 말지는 position 변수가 있는 For 문에서 결정한다. 포함 유무는 orderSet 에 담고 오름차순으로 정리하고 문자열로 조합을 만들었다. 

 

2. 주문 조합 별로 노출 횟수 관리하기

 

모든 주문들의 조합을 순회하면서 노출된 횟수를 저장해야한다. 간단한 방법은 모든 주문 조합 별로 인덱싱이 가능한 int 배열을 만든 다음에 각각을 순회하면서 노출 횟수를 카운트 하는 것이다. 그런데 주문개수가 10개인 경우 알파벳 형태로 가능한 조합의 총 개수는 (26)*(25)*...(17) 이므로 배열에 둘 수 있는 구조가 아니다. 이럴때는 해시 자료구조를 쓴다. 문제에서 주어진 조건으로 가능한 모든 주문의 조합은 10 * 1024개이므로 해시 구조의 최적화를 이용한다면 메모리 범위 내에서 모든 자료구조를 담을 수 있다. 

 

map<string, int> combinations;
map<string, int>::iterator it = combinations.find(combi);

if (it == combinations.end()) {
    combinations.insert(make_pair(combi, 1));
} else {
    it->second++;
}

key와 value가 string, int인 해시 함수를 이용해서 주문 조합의 노출 횟수를 관리했다. 현재 주문 조합이 해시함수에 없으면 새로운 조합을 추가했고 있다면 노출 횟수를 +1 시켜주는 함수다. 이렇게 관리한 자료구조로 노출이 가장 많은 주문 조합을 고를 수 있다.

 

https://github.com/kwony/algorithm/blob/main/Programmers/72411.cpp

728x90

'알고리즘 > 프로그래머스' 카테고리의 다른 글

메뉴 리뉴얼  (0) 2021.05.29

Kotlin - Coroutine

개발/안드로이드 2021. 5. 21. 20:00 Posted by 아는 개발자

Coroutine을 공부할 때 당장 실행되는 코드를 짜려고 launch, async 함수부터 먼저 써보게 되는데(과거의 나) 이것보단 Coroutine을 이루는 구조가 무엇인지를 먼저 공부하고 유틸리티 함수를 사용하면 훨씬 이해하기가 쉽다.  Coroutine을 이루는 구조는 크게 CoroutineScope과 CoroutineContext다. 아래 그림으로 보면 CoroutineScope이 CoroutineContext를 포함하는 관계다.

 

 

1. CoroutineScope

 

CoroutineScope은 Coroutine이 활동할 수 있는 범위를 말한다. 예를 들어 Coroutine이 ViewModel의 생성주기 내에서만 동작하게 할 수 있고 Activity Lifecyle 생명주기를 따라서 동작하게 할 수 있는데 CoroutineScope은 Coroutine의 활동범위를 말한다. 이 속성을 잘 이용하면 Component의 생성주기에 맞춰 Coroutine 작업을 자동으로 취소할 수 있어서 유용하다. Kotlin에서는 안드로이드에서 사용할 수 있도록 몇가지 CoroutineScope을 미리 만들어뒀다. 

 

  • GlobalScope: 앱 프로세스의 생명주기를 따라감. 
  • MainScope: UI 관련 작업을 처리하는 용도.
  • ViewmodelScope: ViewModel의 생성주기를 따라감.
  • LifecycleScope: Activity, Fragment의 생명주기를 따라감. 생명주기별로 콜백이 다르다.
MainScope().launch {}

GlobalScope.launch {}

 

CoroutineScope 인터페이스를 구현해서 커스텀한 CoroutineScope을 만들수도 있긴 한데 공식 문서에서 이 방법은 추천하진 않고 있다.

 

2. CoroutineContext 

 

CoroutineContext는 Coroutine을 이루는 정보다. Coroutine 이름, Job, Dispatcher, ExceptionHandler 가 이에 해당한다. Dispatcher는 Coroutine이 실행될 쓰레드 풀을 의미한다. 대표적으로 Main, IO 쓰레드 풀이 있어서 UI 작업의 경우에는 Main, 디스크 작업에는 IO 쓰레드를 사용하도록 지정 할 수 있다. Executors 라이브러리를 이용해 커스텀으로 만든 쓰레드 풀에도 지정이 가능하다. 아래 코드는 우선순위가 높은 쓰레드 풀에서 동작하는 CoroutineScope을 만든 예다.

 

val customExecutor: Executor = Executors.newCachedThreadPool { r ->
    Thread(r, "CustomThread").apply {
        priority = Thread.MIN_PRIORITY
    }
}
val customDispatcher = object : CoroutineDispatcher() {
    override fun dispatch(context: CoroutineContext, block: Runnable) {
        customExecutor.execute(block)
    }
}

CoroutineScope(customDispatcher).launch {

}

 

ExceptionHandler는 Coroutine 내의 코드 실행중 발생하는 Exception을 처리할 수 있는 Handler다. 현재 Scope 별로 Exception Handler를 다르게 둘 수 있기 때문에 이것도 잘 써먹으면 유용하다. 

 

val handler = CoroutineExceptionHandler { context, th->
    println("$context ${th.toString()} ")
}

GlobalScope.launch(handler) {
    val async1 = async(){ 1 }
}

 

3. Utility 함수 

 

3.1 launch

 

launch 함수는 CoroutineScope내에서 실행되며, 현재 쓰레드를 막지 않고(blocking) 동작할 수 있는 새로운 Coroutine Job을 생성한다. 병렬로 수행되기 때문에 여러가지 작업을 동시에 수행할 때 쓰면 좋다. 아래 코드는 GlobalScope 내에서 두개의 Coroutine Job을 생성한 코드다. 앞에 코드에 300ms 의 딜레이를 줬다. 그 결과 scope2가 먼저 프린트 되고, scope1은 그 이후에 프린트 된다.

 

GlobalScope.launch {
    launch {
        delay(300)
        println("scope1")
    }
    launch {
        println("scope2")
    }
}

2021-05-21 16:14:17.677 I/System.out: scope2
2021-05-21 16:14:17.978 I/System.out: scope1

 

Job 내부 함수인 join() 은 동시성을 제어할 수 있는 함수다. 현재 Coroutine의 실행이 종료되지 않을 때까지 다음 코드를 실행하지 않는다. 순서를 관리할 때는 이 함수를 쓰면 된다. 그리고 cancel() 처럼 취소할 수 있는 함수도 있다. 이건 실제로 사용하다 보면 어떻게 써야하는지 감이 온다.

 

3.2 async 

 

async 함수는 launch 와 거의 동일하고 결과 값을 받을 수 있다는 점이 추가 됐다. 아래 코드의 두 async Job은 각각 1, 2를 리턴하는 CoroutineScope이다. async 내부 await() 함수는 여기서 실행된 결과 값을 받아오게 된다. 여기서 주의깊게 볼 부분은 각각에 delay를 300ms, 100ms 씩 줬는데도 start 로그로부터 결과 값까지 걸린 시간은 둘의 합인 400ms가 아니라 가장 긴 delay인 300ms라는 점이다. 두 Job을 병렬로 처리했기 때문에 가장 delay를 오래 잡는 Job의 시간만큼 소요된다.

 

GlobalScope.launch {
    println("start")
    val a = async {
        delay(300)
        1
    }
    val b = async {
        delay(100)
        2
    }

    println("a + b = ${a.await() + b.await()}")
}

2021-05-21 16:22:19.885 I/System.out: start
2021-05-21 16:22:20.190 I/System.out: a + b = 3

 

3.3 withContext 

 

동일한 CoroutineScope 내에서도 종종 Coroutine Context를 바꿔야 할 일이 생긴다. 예를 들면 I/O 작업을 수행 중에도 중간중간 화면 UI를 업데이트 해야하는 경우 Dispatcher를 바꿔 코드에 적용하는 쓰레드를 변경해야한다. 이럴때 쓰면 유용한 함수가 withContext다. 아래 코드는 I/O 스레드 풀에서 "abc", "def"라는 문자열을 받아오고 두 문자를 합해서 text라는 변수를 만들었다. UI 에 적용하려면 withContext를 이용해 임시로 Main함수로 바꿔주어 UI 컴포넌트에 접근 할 수 있다. 참고로 withContext는 내부적으로 async{}.await()로 구현돼 있어 내부 코드가 모두 실행된 다음에 다음 코드로 넘어가게된다. 

 

CoroutineScope(Dispatchers.IO).launch {
    val a = async {
        "abc"
    }
    val b = async {
        "def"
    }
    
    val text = a.await() + b.await()
    
    withContext(Dispatchers.Main) {
        textView.text = text
    }
}
728x90

'개발 > 안드로이드' 카테고리의 다른 글

Serializable 과 Parcelable  (0) 2021.06.19
kotlin lateinit, lazy by  (0) 2021.06.05
Kotlin - Coroutine  (0) 2021.05.21
Android 10 스토리지 정책 대처하기  (0) 2021.05.18
다음 페이지가 살짝 보이는 ViewPager2 만들기  (0) 2021.05.13
움직이는 TextView  (0) 2021.05.11

클린 아키텍처

기술/아키텍처 2021. 5. 20. 19:51 Posted by 아는 개발자

 

로버트 마틴의 클린 코드에선 코드를 깔끔하게 잘 짜는 방법을 배웠다면 클린 아키텍처에서는 소프트웨어를 더 잘 만드는 방법을 배운 것 같다. 책의 표현을 빌리자면 클린 코드에서는 좋은 벽돌을 구분하는 방법을 배웠다면 클린 아키텍처에서는 좋은 벽돌로 건물을 짓는 방법을 배운 느낌이랄까. 책에선 저자가 경험한 내용을 바탕으로 전달하려는 교훈이 많다. 저수준, 고수준, 프레임워크는 세부사항일 뿐이다 등등.. 그런데 나의 소프트웨어 깊이가 부족해 공감하기 어려운 부분도 있었고 이해되지 않던 부분도 있어서 모두 소화하진 못했다. 그래도 연차가 늘어나고 더 큰 규모의 소프트웨어를 경험하다보면 이 책에서 내가 캐치하지 못했던 새로운 면이 보일 것 같아 기대된다. 2-3년 후에 다시 이 책을 읽어봐야 겠다.

 

많은 전달 내용 중 내 머릿속을 관통하는 소프트웨어 원칙은 이 그림으로 표현 할 수 있다.

 

 

다이어그램 상에선 컴포넌트A 가 컴포넌트B를 가리키고 있는 그림인데 소프트웨어상에선 컴포넌트A 가 컴포넌트B 에 의존한다는 의미의 그림이다. 이 의존 관계는 소프트웨어 상에서 생길 수 있는 가장 중요한 관계고 이 관계를 어떻게 정의하느냐에 따라서 소프트웨어의 아키텍처가 결정된다. 컴포넌트A는 저수준으로, 컴포넌트B는 고수준으로 둬야한다고 그림상에선 표현 했는데 여기서 말하는 수준은 어떤 컴포넌트가 우월한지를 결정하는 기준이 아니라 얼마만큼 변동성이 크냐를 기준으로 결정한다.

 

위 그림처럼 의존관계가 성립되려면 고수준인 컴포넌트B는 수정할 일이 적어야 한다. 그래야 컴포넌트A에 미치는 영향을 최소화 할 수 있기 때문이다. 위 그림처럼 결정되는 대표적인 예가 애플리케이션에서 String, Math 같은 자바 고유 라이브러리 클래스를 사용하는 경우다. 자바 버전에 따라서 클래스가 변경될 소지가 있지만 그래도 우리가 개발하는 클래스보다 변경될 소지는 적다. 이런 경우 의존 관계는 적절한 것으로 볼 수 있다.

 

그래도 가끔은 이런 의존 관계를 성립하기 힘든 경우도 있다. 둘다 변경의 소지가 크지만 두 클래스를 연결해야할 때가 있다. 이럴때 사용하는 방식이 의존성 역전원칙이다. 좀더 고수준으로 보이는 클래스에 특정 인터페이스를 만들고 이것과 상속 관계로 만든다. 그리고 저수준 클래스를 인터페이스에 의존하는 관계로 만든다. 인터페이스는 변경될 소지가 적기 때문에 이 의존 관계도 적절한 관계로 볼 수 있다.

 

 

물론 매번 이렇게 코딩할 수는 없다. 개발하다보면 새로운 함수도 추가해야돼 인터페이스도 손될 일이 많아지니까. 모든 원칙을 지키다 보면 오버 엔지니어링이돼 개발 프로세스가 느려지는 부작용도 생길 수 있다. 항상 모든 원칙을 지키기는 어려울 것 같다. 하지만 원칙을 알고 생략하는 것과 모르고 넘어가는 것은 차이가 크다. 앞으로 일하면서 어떤 원칙을 넘기면서 개발하고 있는지 되새겨봐야 할 것 같다.

728x90

'기술 > 아키텍처' 카테고리의 다른 글

오브젝트 리뷰 - 1  (0) 2021.07.11
응집도(Cohesion)와 결합도(Coupling)  (0) 2021.07.10
클린 아키텍처  (0) 2021.05.20
DIP(Dependency Inversion Principle)  (0) 2021.05.09
ISP (Interface Segregation Principle)  (0) 2021.05.09
LSP (Liskov Substitution Principle)  (0) 2021.05.09

Android 10 스토리지 정책 대처하기

개발/안드로이드 2021. 5. 18. 20:40 Posted by 아는 개발자

targetSdkVersion 을 30으로 올리면 파일 절대 경로를 사용해서 접근 할 수 없기 때문에 개발자들은 지금부터 슬슬 절대 경로를 사용해서 접근하는 코드를 변경해야한다. 이번 포스트에서는 안드로이드 새로운 스토리지 정책을 적용한 과정을 다뤄본다.

 

1. 절대 경로 대신 Uri 를 사용하도록 변경

 

기존에는 ContentResolver 클래스를 이용해 파일을 읽어올 때 DATA 칼럼을 이용해서 파일의 절대 경로를 읽어올 수 있었다. 그런데 DATA 컬럼은 Android 10부터 Deprecated가 됐고, targetSdkVersion 30으로 올리면 DATA 칼럼으로 얻을 수 있는 절대 경로로 파일이 접근이 되지 않는다. 

 

private suspend fun loadVideoContent(): Cursor? = coroutineScope {
    val where = MediaStore.Video.VideoColumns.SIZE + " > " + 0
    val sortOrder = MediaStore.Files.FileColumns.DATE_ADDED + " DESC"
    val projections = listOf(
        MediaStore.Video.Media._ID,
        MediaStore.Video.Media.DATA, // Deprecated됨
        MediaStore.Video.Media.DISPLAY_NAME
    ).toTypedArray()

    return@coroutineScope requireActivity().contentResolver.query(MediaStore.Video.Media.EXTERNAL_CONTENT_URI, projections, where, null, sortOrder)
}

 

 

이제는 우리에게 익숙한 절대 경로 대신 Uri를 이용한 상대 경로를 사용해야한다. Uri는 content:// 로 시작하는 문자열인데, _ID 칼럼에서 얻어온 값과 ContentUri 클래스를 이용해서 얻어올 수 있다. 이 값도 파일을 찾는 경로로 사용되며 현재 Glide, MediaMetadataRetriever, Exoplayer처럼 유명한 안드로이드 라이브러리들은 Uri를 통해서도 파일을 불러올 수 있게끔 업데이트가 된 상태라 호환성은 크게 걱정하지 않아도 된다. 절대경로와 다른점은 실제 파일의 경로를 보여주지 않아 플랫폼 보안적인 요소가 강화된다. 반대로 개발자의 피로도는 악화되고.

 

val uriCol = cursor.getColumnIndex(MediaStore.Video.Media._ID)

do {
    mediaItems.add(
        MediaItem(
            ContentUris.withAppendedId(
                MediaStore.Video.Media.EXTERNAL_CONTENT_URI,
                cursor.getLong(uriCol)
            ),

 

2. File 클래스를 선언해야하는 경우 

 

문제는 File 클래스를 선언해야하는 경우다. 오래된 오픈소스거나 Uri를 고려하지 않은 모듈인 경우엔 절대 경로가 필요한 File 클래스를 사용해야하는 경우가 종종 있다. 그런데 앞서 언급했듯이 Uri는 상대 경로다. Uri를 통해 File 클래스로 바꿀수 있긴 한데 이건 file 스키마를 가진 Uri인 경우에만 그렇다. Uri 클래스에 Kotlin에 확장 코드로 toFile() 함수가 있긴 한데 ContentUris로 얻어온 Uri 클래스에 쓰면 요런 에러가 뜬다.

 

 

이럴 때는 절대 경로를 읽을 수 있는 형태로 꼼수가 필요하다. Android 10부터 스토리지를 절대 경로로 접근하는 것은 안되지만 앱 전용 캐시 영역은 여전히 절대 경로로 접근 할 수 있다. 스토리지에 있는 파일을 캐시로 복사하면 복사한 파일의 절대 경로로 파일 클래스를 선언해줄 수 있다. copy 작업이 딜레이도 있고 불필요하게 캐시영역 써야해 완벽한 방법은 아니다. 하지만 라이브러리에서 Uri를 지원하기 전까지는 써먹을 수 있을 것 같다. 더 좋은 방법이 있다면 공유해주시면 좋겠다. 나는 이것 말고는 딱히 방법을 못찾겠다...

 

val dir = File(context.cacheDir.path + File.separator + effectFolderName)
val filePath = context.cacheDir.path + File.separator + effectFolderName + File.separator + filename
val file = File(filePath)
val inputStream = getApplication<App>().contentResolver.openInputStream(uri)

try {
    FileUtils.copyToFile(inputStream, it) // org.apache.commons.io 를 사용
} catch (e: IOException ) {
    e.printStackTrace()
}

 

3. 미디어 파일을 추가하는 경우

 

앱에서 이미지나 동영상을 다운받는 경우 예전에는 Environment.getExternalStorageDirectory().path 코드를 이용해서 직접 원하는 경로에 파일을 생성해서 추가할 수 있었으나 Android 10 부터는 ContentResolver를 이용해 Uri로 파일을 추가해야한다. 아래 코드는 이미지 파일을 저장소에 추가하는 코드다. ContentValues 값을 설정해 임의의 이미지 파일을 만든 후 insert 함수에서 생성된 Uri 변수로 FileOutputStream을 만들고 I/O 라이브러리를 이용해 기존 파일과 복사하는 작업이다. 관계형 데이터베이스에 새로운 행을 추가하고 값을 업데이트한다고 보면 쉬울 것 같다. 실제로 ContentResolver는 관계형 데이터베이스 쿼리랑 상당부분 흡사하다.

 

val collection = MediaStore.Video.Media.getContentUri(MediaStore.VOLUME_EXTERNAL_PRIMARY)

val contentvalues = ContentValues().also {
    it.put(MediaStore.MediaColumns.RELATIVE_PATH, "Images")
    it.put(MediaStore.MediaColumns.DISPLAY_NAME, name)
    it.put(MediaStore.MediaColumns.IS_PENDING, true)
}

val uri = context.contentResolver.insert(collection, contentvalues)
val fos = context.contentResolver.openOutputStream(uri!!, "w")

try {
    FileUtils.copyFile(sourceFile, fos)
} catch (e: IOException) {
    return false
}
values.put(MediaStore.MediaColumns.IS_PENDING, false)
context.contentResolver.update(uri, values, null, null)

 

728x90

아래 그림처럼 ViewPager 형태인데 다음 페이지가 살짝 보이는 UI를 만드는 경우가 종종 있다. 이번 포스트에서는 ViewPager2를 이용해 이 화면을 만드는 방법을 다뤄보려고 한다.

 

val currentVisibleItemPx = DimensionUtils.dp2px(requireContext(), 40f).toInt()

margin_pager.addItemDecoration(object: RecyclerView.ItemDecoration() {
    override fun getItemOffsets(outRect: Rect, view: View, parent: RecyclerView, state: RecyclerView.State) {
        outRect.right = currentVisibleItemPx
        outRect.left = currentVisibleItemPx
    }
})

ViewPager에서 inflate 된 페이지는 부모의 width를 따라가게 되므로 우선 각 페이지가 전체 영역을 잡지 않게 여백을 만들어둔다. 현재 보여진 위치로부터 양 옆에 margin을 추가한다. 그러면 아래 그림과 같은 상태가 된다.

 

 

val nextVisibleItemPx = DimensionUtils.dp2px(requireContext(), 20f).toInt()
val pageTranslationX = nextVisibleItemPx + currentVisibleItemPx

margin_pager.offscreenPageLimit = 1

margin_pager.setPageTransformer { page, position ->
    page.translationX = -pageTranslationX * ( position)
}

 

다음은 이전 페이지와 다음 페이지에 이동 효과를 줘야한다. 먼저 첫번째는 offscreenPageLimit 값을 설정는데 이 속성은 ViewPager2가 스크린에 현재 페이지로부터 얼만큼 떨어져 있는 페이지를 미리 생성 할 것인지 설정하는 함수다. offscreenPageLimit 값이 1이고, 5번 페이지가 현재 위치라면 ViewPager2는 4, 6번 페이지도 미리 생성 해둔다.

 

그 다음은 setPageTransformer 함수를 사용하는 것이다. 이 콜백은 현재 포커싱된 page 뷰 객체를 받을 수 있고 각 page 별로 포커싱 된 페이지로부터 얼마만큼 떨어져 있는지 비율 정보를 position으로 받을 수 있다. 아래 그림에선 현재 페이지가 1번에 포커싱돼 있어서 이전 페이지인 0번 페이지는 -1f만큼 떨어져 있게 되고, 다음 페이지인 2번 페이지는 1f만큼 떨어져 있게 된다. 

 

 

이 정보 값을 이용하면 0번과 2번 페이지를 필요한 만큼 이동시킬 수 있다. translationX 값을 변경하면 0번과 2번 페이지가 움직여서 미리보기 형태로 볼 수 있게 된다.

 

728x90

움직이는 TextView

개발/안드로이드 2021. 5. 11. 19:57 Posted by 아는 개발자

종종 화면내에서 움직이는 TextView를 만들어야 할 때가 있다.

 

이렇게 직선형태로 움직이는 애니메이션의 경우 TranslateAnimation 클래스를 이용해서 쉽게 구현이 가능하다. 아래 코드는 새로운 TextView를 만들고 layout에 추가한 다음 애니메이션을 실행한 코드다. 주목할 부분은 TranslateAnimation 코드다.

 

CoroutineScope(Dispatchers.Main).launch {
            val movingText = TextView(requireContext()).apply {
                this.text = "움직이는 텍스트"
                this.layoutParams = LinearLayout.LayoutParams(ViewGroup.LayoutParams.WRAP_CONTENT, ViewGroup.LayoutParams.WRAP_CONTENT).apply {}
                this.visibility = View.INVISIBLE
                this.setTextColor(0xff141414.toInt())
            }

            danmu_layout.addView(movingText)

            movingText.post {
                val animation = TranslateAnimation(requireView().width.toFloat(), -(movingText.width.toFloat()), 0f, 0f)
                animation.duration = 3000
                animation.repeatCount = Animation.INFINITE
                animation.setAnimationListener(object: Animation.AnimationListener {
                    override fun onAnimationStart(animation: Animation?) {
                        movingText.visibility = View.VISIBLE
                    }

                    override fun onAnimationEnd(animation: Animation?) {}
                    override fun onAnimationRepeat(animation: Animation?) {}
                })
                movingText.startAnimation(animation)
            }
        }

 

TranslateAnimation 생성자 인자에서 받는 값은 fromXDelta, toXDelta, fromYDelta, toYDelta다. xml 파일로 애니메이션을 작성할 때는 퍼센테이지 값을 넣을 수 있는데, TranslateAnimation 클래스를 사용하면 픽셀 값으로 입력해야한다. 각각이 의미하는 바를 보자. 

 

public TranslateAnimation(float fromXDelta, float toXDelta, float fromYDelta, float toYDelta) {

 

fromXDelta는 현재 위치로부터 Delta만큼 x축 방향으로 이동한 지점에서 애니메이션을 시작한다. 현재 위치부터 시작하고 싶다면 0을, 다른 위치로 변경하고 싶다면 특정 값을 설정하면 된다. + 값은 오른쪽으로 이동하고 - 값은 왼쪽으로 이동한다. 같은 원리로 toXDelta는 현 위치에서 x축 방향으로 이동한 지점에서 애니메이션을 종료한다. 왼쪽으로 이동한 지점에서 종료하고 싶다면 - 값을, 오른쪽으로 이동한 값에서 종료하고 싶으면 + 값을 넣으면 된다. 앞서 소개한 코드에선 fromXDelta에선 부모 뷰의 width만큼 움직여서 화면 밖에서 시작하고, toXDelta는 현재위치에서 텍스트의 width만큼 왼쪽으로 움직이므로 화면 밖으로 사라지는 애니메이션을 만들 수 있었다. 절대적인 좌표가 아니라 아니라 현 위치로부터 상대적인 거리로 값을 입력해야 한다는 점을 주의하자. y축에서도 동일한 원리를 적용할 수 있다.

 

728x90

DIP(Dependency Inversion Principle)

기술/아키텍처 2021. 5. 9. 08:57 Posted by 아는 개발자

좋은 아키텍처는 변동성이 큰 모듈에 의존하지 않는 것이다. 그런데 개발하다 보면 예상치 못한 버그도 종종 생기기 마련이기 때문에 어떤 클래스는 릴리즈마다 계속 수정을 할 수 밖에 없다. 그런데 이때마다 새로운 함수를 추가하고 새로운 변수가 등장한다면 이 클래스를 의존하는 다른 모듈에도 영향이 미친다. 이런 형태면 하나의 클래스를 수정하는데도 다른 클래스까지 영향을 주게 된다.

 

그림 1

위 그림에선 사용자가 버그가 많은 결제 시스템 클래스를 의존하고 있다. 지금까지 pay 함수에 버그가 많아서 3개의 레거시 함수가 있다. 이런 형태는 새로운 함수가 추가될 때 마다 사용자의 코드에 영향을 주게 되는 사례다.

 

해법은 인터페이스를 이용하는 것이다. 모듈은 안정화된 인터페이스에 의존하고 변동성이 큰 실제 구현체는 인터페이스를 바꾸지 않는 선에서 수정한다. 인터페이스가 바뀌지 않는것이 보장됐기 때문에 원래 실제 구현체에 의존하는 클래스는 수정이 있어도 코드를 수정하지 않아도 된다. 이런 철학으로 만든 원칙이 DIP(Dependency Inversion Principle) 의존성 역전 원칙이다.

 

그림 2

그림 2는 그림 1에서 DIP를 적용한 버전이다. 사용자는 안정화된 결제시스템 Interface를 참조하고 있기 때문에 수정할 일이 없다. 버그가 많은 결제시스템만 수정해도 소프트웨어의 안정성은 보장된다. 요즘에는 프레임워크 차원에서 이렇게 구현할 수 있도록 지원하고 있다. 안드로이드의 Hilt, Dagger가 DIP를 지원하는 대표적인 라이브러리니 아직 사용해보지 않은 분들은 한번 써보는게 좋을 것 같다.

728x90

'기술 > 아키텍처' 카테고리의 다른 글

응집도(Cohesion)와 결합도(Coupling)  (0) 2021.07.10
클린 아키텍처  (0) 2021.05.20
DIP(Dependency Inversion Principle)  (0) 2021.05.09
ISP (Interface Segregation Principle)  (0) 2021.05.09
LSP (Liskov Substitution Principle)  (0) 2021.05.09
OCP (Open Closed Principle)  (0) 2021.05.04

ISP (Interface Segregation Principle)

기술/아키텍처 2021. 5. 9. 08:28 Posted by 아는 개발자

ISP는 필요 이상 많은 것을 포함하는 모듈에 의존하지 말자는 원칙에서 유래됐다. 이것도 사례를 먼저 보자.

 

위 그림을 보면 결제관리, 환불관리, 포인트 관리 객체가 시스템 클래스를 참조하고 있다. 그런데 결제관리 객체는 pay 함수만 호출 할 것이고, 환불 관리는 refund, 포인트관리는 addPoint함수만 사용할 것이다. 각 객체의 입장에서는 필요 이상으로 시스템 클래스에 의존하고 있는 형태다. 만약 객체에서 불필요하게 다른 함수를 호출한다면 에러가 발생할 위험도 있다.

 

이런 경우에는 시스템을 각각 쪼개주는 방법이 있다. 결제시스템, 환불시스템, 포인트 시스템을 각각 인터페이스로 만들어고 시스템 클래스가 인터페이스의 하위타입으로 구현한다. 그리고 각각의 객체는 관계가 있는 인터페이스에만 의존하도록 만들면 의존하는 모듈에 불필요하게 포함된 함수들을 제거할 수 있다.

728x90

'기술 > 아키텍처' 카테고리의 다른 글

클린 아키텍처  (0) 2021.05.20
DIP(Dependency Inversion Principle)  (0) 2021.05.09
ISP (Interface Segregation Principle)  (0) 2021.05.09
LSP (Liskov Substitution Principle)  (0) 2021.05.09
OCP (Open Closed Principle)  (0) 2021.05.04
SRP (Single Responsibility Principle)  (0) 2021.05.04