CHAPTER 7 구조 디자인 패턴 - 2

어댑터 패턴과 퍼사드 패턴 이 두 패턴의 차이점은?

목적과 사용법 및 구현 방식에 차이가 있다.

목적과 사용법

어댑터 패턴은 이미 존재하는 인터페이스와 새로운 시스템을 연결하기 위해 사용된다.
- 즉, 호환되지 않는 인터페이스 때문에 같이 사용할 수 없는 클래스들을 연결해주는 역할을 한다.
- 예를 들어, 새로운 시스템에서 기존 시스템의 메서드를 사용하고 싶지만, 인터페이스가 다른 경우에 어댑터 패턴을 사용하여 인터페이스를 호환 가능하게 만들 수 있다.
퍼사드 패턴은 하나의 통합된 인터페이스를 제공하여 여러 복잡한 시스템의 서브 시스템들을 더 쉽게 사용할 수 있도록 한다.
- 즉, 클라이언트에게 단순화된 인터페이스를 제공하는 역할을 하며, 내부적으로 여러 서브 시스템들의 복잡한 관계를 숨기게 된다.

구현 방식

어댑터 패턴은 기존 클래스의 인터페이스를 클라이언트에서 기대하는 다른 인터페이스로 변환한다.
- 이 패턴은 주로 클래스를 감싸는 형태로 구현되며, 상속 또는 구성을 통해 구현될 수 있다.
퍼사드 패턴은 복잡한 서브 시스템에 대해 단일 클래스가 통합된 인터페이스를 제공한다.
- 이 패턴은 클라이언트가 서브 시스템과 직접 통신하지 않도록 하며, 퍼사드를 통해 모든 통신이 이루어지게 한다.

// 기존 인터페이스
interface OldInterface {
    fun oldRequest()
}

// 새로운 인터페이스
interface NewInterface {
    fun newRequest()
}

// 기존 인터페이스를 구현하는 클래스
class OldInterfaceImpl : OldInterface {
    override fun oldRequest() {
        println("Old interface method called")
    }
}

// 어댑터 클래스
class Adapter(private val oldInterface: OldInterface) : NewInterface {
    override fun newRequest() {
        oldInterface.oldRequest()
    }
}

// 클라이언트 코드
fun main() {
    val oldInterface: OldInterface = OldInterfaceImpl()
    val adapter: NewInterface = Adapter(oldInterface)
    adapter.newRequest()
}

// 서브 시스템 1
class SubsystemOne {
    fun operationOne() {
        println("Subsystem One")
    }
}

// 서브 시스템 2
class SubsystemTwo {
    fun operationTwo() {
        println("Subsystem Two")
    }
}

// 서브 시스템 3
class SubsystemThree {
    fun operationThree() {
        println("Subsystem Three")
    }
}

// 퍼사드 클래스
class Facade {
    private val subsystemOne = SubsystemOne()
    private val subsystemTwo = SubsystemTwo()
    private val subsystemThree = SubsystemThree()

    fun operation() {
        subsystemOne.operationOne()
        subsystemTwo.operationTwo()
        subsystemThree.operationThree()
    }
}

// 클라이언트 코드
fun main() {
    val facade = Facade()
    facade.operation()  // 클라이언트는 퍼사드를 통해 간단하게 여러 서브 시스템과 상호작용할 수 있음
}

count관련 함수는 호출할때마다 매번 하위 트리 전체를 탐색하기 때문에 효율이 떨어지는데 효율성을 높일 수 있는 방법

countNodeOfFiles나 countSizeOfFiles를 add,remove 할때마다 미리 계산해두는 것이 아니라면 HashMap을 사용해서 add,remove 만이라도 좀 더 효율을 높일수 있을거 같다.

class FileSystemNode(
    private val path: String,
    private val isFile: Boolean
) {
    private val subNodes: MutableMap<String, FileSystemNode> = mutableMapOf()

    fun countNodeOfFiles(): Int {
        if (isFile) return 1
        return subNodes.values.sumOf { it.countNodeOfFiles() }
    }

    fun countSizeOfFiles(): Long {
        if (isFile) {
            val file = File(path)
            return if (file.exists()) file.length() else 0
        }
        return subNodes.values.sumOf { it.countSizeOfFiles() }
    }

    fun addSubNode(fileOrDir: FileSystemNode) {
        subNodes[fileOrDir.path] = fileOrDir
    }

    fun removeSubNode(fileOrDir: FileSystemNode) {
        subNodes.remove(fileOrDir.path)
    }
}

IntegerCache 클래스는 미리 지정된 정수 객체만 캐시할 수 있는데, 만약 이를 미리 캐싱하는대신 String 클래스와 동일한 방식으로 실행 과정에서 정수 객체가 사용되는 시점에 새로 객체를 생성한 후, 재사용을 위해 IntegerCache 클래스에 넣는 것이 가능할지?

object DynamicIntegerCache {
    private val cache = mutableMapOf<Int, Int>()

    @Synchronized
    fun valueOf(i: Int): Int {
        return cache.getOrPut(i) { i }
    }
}

어댑터 패턴과 퍼사드 패턴의 차이

어댑터 기존의 시스템과 새로운 시스템을 연결하기 위한 패턴
퍼사드 기존의 시스템을 더 편하게 사용할 수 있는 인터페이스를 만드는 패턴

내가 만들었던 UseCase 가 사실 파사드가 아니였을까 ...

countNumOfFiles와 countSizeOfFiles 의 효율성을 높이는 방법은 ?

7장 효율성

각 Directory 의 값을 계산한 NodeInfo 를 만들고 add, remove 에서 parent Directory 를 업데이트 해준다

IntegerCache 클래스는 미리 지정된 정수 객체만 캐시할 수 있는데, 만약 이를 미리 캐싱하는대신 String 클래스와 동일한 방식으로 실행 과정에서 정수 객체가 사용되는 시점에 새로 객체를 생성한 후, 재사용을 위해 IntegerCache 클래스에 넣는 것이 가능할지?

가능!

7.5.5 어댑터 패턴과 퍼사드 패턴의 차이 어댑터 패턴은 기존 인터페이스를 사용하는 곳에서 사용하기 용이하게끔 수정하고, 퍼사드 패턴은 여러개의 인터페이스를 하나로 묶는다. 어댑터는 마치 5핀에 꽂는 c타입 젠더, 퍼사드는 usb 허브

7.6.3 countNumOfFiles와 countSizeOfFiles 효율성 높이기 각 디렉토리마다 하위 디렉토리의 num과 size 정보를 캐싱해둔다. add나 remove가 발생할 때마다 캐싱한 값을 갱신한다. 한 디렉토리가 갱신되면 그 디렉토리부터 최상위 디렉토리까지의 캐싱된 값이 변경되어야 하지만 매번 최하위 디렉토리까지 탐색하는 것보다는 효율적일 것이다

7.7.6

styles를 List가 아닌 HashMap으로 바꾸고, "$font-$size-$colorRGB" 처럼 unique한 key를 만들어 사용한다
음.. 될거같은데 (저자가 물어보는데에는 뭔가 의미가 있지 않을까? 의심하게 되지만 뭐가 문제될 지는 짚이는게 없다)

5. 퍼사드 패턴

주로 인터페이스 설계에 사용
사용 편의성과 범용성의 균형을 맞추기 위함
여러개의 인터페이스를 묶어서 하나의 인터페이스로 만드는 것
- 인터페이스 사용에 드는 리소스를 절약하기 위함
좋은 예시 - 트랜잭션

생각해보기

어댑터는 여러 종류의 인터페이스를 번거롭게 사용하는 것을 막기 위해 사용하는 느낌 이라면, 퍼사드는 일련의 인터페이스를 사용하는 것을 간편하게 만들고 리소스를 줄이기 위해 만드는 느낌

6. 복합체 패턴

트리 구조의 데이터를 처리하는 데 사용
보통 파일 시스템 디렉토리 구조에서 사용됨

생각해보기

세그먼트 트리처럼 중간 노드들이 하위 노드들의 정보의 합계 같은 정보를 저장하고 있으면 될듯

7. 플라이웨이트 패턴

공유를 위해 사용되는 패턴
불변 객체를 재사용하여 메모리를 절약하는 것
대표 예시 - Java의 원시 형식과 래퍼 클래스에서 사용되는 캐시
싱글턴과의 차이
- 싱글턴은 객체가 하나, 플라이웨이트는 객체는 여러개

생각해보기

3차원 동적 배열…(?) 이 메모리가 더 들려나 그냥 그 값 자체를 키로 써서 바로 인스턴스를 얻을 수 있는게 가장 좋을 것 같은데, 값으로 정렬을 하기도 애매한 것 같고…
안될건 없을것같다.

BoostStudy / design-patterns