> For the complete documentation index, see [llms.txt](https://jinwon-yoon.gitbook.io/jinonys-blog/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jinwon-yoon.gitbook.io/jinonys-blog/daily-log/2022.08.16.md). # 2022.08.16 일일 회고 6일차 ## 할일 및 한일 * [x] 디자인 패턴 7장(어댑터 패턴과 퍼사드 패턴) 복습 * [x] 디자인 패턴 세미나 참석 ## 경험 및 배움 ### 디자인 패턴 7장(어댑터 패턴과 퍼사드 패턴) 오늘은 저번에 정리하였던 디자인 패턴 7장(어댑터 패턴과 퍼사드 패턴)을 복습하고, 세미나 참석을 위해 준비하였다. 어댑터 패턴, 그리고 퍼사드 패턴에 대해 알아보았다. {% embed url="" %} 디자인 패턴 7장 정 {% endembed %} {% hint style="info" %} ***어댑터 패턴*** 특정 클래스 인터페이스를 클라이언트에서 요구하는 다른 인터페이스로 변환한다. 인터페이스가 호환되지 않아 같이 쓸 수 없었던 클래스를 사용할 수 있게 도와준다. {% endhint %} 어댑터 패턴을 쓰면 몇 가지 **장점**들이 있다. * **호환되지 않는 인터페이스를 사용하는 클라이언트를 그대로 활용**할 수 있다. * **클라이언트와 구현된 인터페이스를 분리**할 수 있다. * 변경 내역이 어댑터에 **캡슐화** 되기 때문에 인터페이스가 바뀌더라도 클라이언트를 바꿀 필요가 없다. 어댑터 패턴은 **'객체 어댑터'**와 **'클래스 어댑터'**가 있다. 하지만 Java에서는 다중 상속을 지원하지 않기 때문에 클래스 어댑터는 사용할 수 없다. 자바에서의 다중 상속 문제, 일명 **다이아몬드 문제**라고 불리는 문제는 시간이 나면 다시 자세하게 알아볼 생각이다. 객체 어댑터는 구성을 활용하고, 클래스 어댑터는 상속을 활용하는 등 여러 차이가 있다. 자세한 내용이나 코드 예시은 노션 정리 링크에서 볼 수 있다. 다음은 퍼사드 패턴의 정의이다. {% hint style="info" %} ***퍼사드 패턴*** 서브시스템에 있는 일련의 인터페이스를 통합 인터페이스로 묶어 준다. 또한 고수준 인터페이스도 정의하므로 서브시스템을 더 편리하게 사용할 수 있다. {% endhint %} 쉽게 이야기 하면 퍼사드 패턴은 **일련의 객체를 감싸서 단순하게 하는 용도**로 쓰인다. 여기서 하나 더 중요한 원칙이 등장하는데, 그것이 데메테르 원칙이라고도 불리는 **최소 지식 원(Principle of Least Knowledge)**이다. 최소 지식 원칙 시스템을 디자인할 때 어떤 객체든 그 객체와 상호작용을 하는 클래스의 개수와 상호작용 방식에 주의를 기울여야 하는데, 그것 **최대한 줄여서 시스템의 한 부분을 고쳤을 때, 줄줄이 얽혀 있는 코드들을 다 고치지 않도록 느슨하게 결합을 해야한다는** 원칙이다. 예를 들면 다음과 같은 코드를, ```java public float getTemp() { Thermometer thermometer = station.getThermometer(); return thermometer.getTemperature(); ``` 이런 식으로 최소 지식 원칙을 지켜서 수정할 수 있다. ```java public float getTemp() { return station.getTemperature(); ``` 자세한 내용과 예시는 깃허브, 노션 정리 링크에 첨부되어있다. ## 개선 및 목표 * 이번주 공부할 시간이 많이 없으니 미리 하자. * 복습을 철저히 하자. 빠르게 나간다고 해도 지나면 기억이 안나기 마련이다.