오브젝트 리뷰 - 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