generated from muhandojeon/study-template
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
88 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,88 @@ | ||
## 구조 패턴 | ||
구조 패턴은 클래스와 객체의 구성을 다룬다 | ||
- 퍼사드 패턴 | ||
- 믹스인 패턴 | ||
- 데코레이터 패턴 | ||
- 플라이웨이트 패턴 | ||
|
||
## 퍼사드 패턴 | ||
> 퍼사드는 건물의 외관을 뜻함 | ||
퍼사드 패턴은 심층적인 복잡성을 숨기고, 사용하기 편리한 높은 수준의 인터페이스를 제공하는 패턴 | ||
|
||
퍼사드는 jQuery에서 흔히 볼 수 있는 구조 패턴 | ||
|
||
장점 : 사용하기 쉽다, 패턴 구현에 필요한 코드 양이 적다 | ||
단점은 안적혀 있음 ㄷ ㄷ | ||
|
||
> 복잡한 내부를 감추고 사용자에게 단순한 인터페이스를 제공한다는 점에서 선언적 프로그래밍 기조와 비슷하다고 느낌 | ||
|
||
## 믹스인 패턴 | ||
믹스인은 서브클래스가 쉽게 상속받아 기능을 재사용할 수 있도록 하는 클래스 | ||
|
||
> [!NOTE] | ||
> 서브클래스: 부모 클래스를 확장하는 자식 클래스 | ||
> 서브클래싱: 부모 클래스 객체에서 상속받아 새로운 객체 만드는 것 | ||
|
||
자바스크립트에서 클래스는 표현식 뿐만 아니라 문(statement) 으로도 사용할 수 있음 | ||
평가될 때마다 새로운 클래스 반환함 | ||
|
||
```js | ||
const MyMixins = superclass => | ||
class extends superclass { | ||
moveup() { | ||
... | ||
``` | ||
> react에서도 관성적으로 사용해왔던게 기억남. 이것도 문으로 사용한 예시 맞나요..? | ||
> ```js | ||
> const componentMap = { | ||
> A: ComponentA, | ||
> B: ComponentB, | ||
> }; | ||
> const SelectedComponent = componentMap[componentType]; | ||
> return <SelectedComponent /> | ||
> ``` | ||
### 믹스인 패턴의 장단점 | ||
장점: 함수의 중복을 줄이고 재사용성을 높인다 | ||
- 기능을 공유하여 중복을 피하고 고유 기능을 구현하는데 집중 가능 | ||
단점: 프로토타입 오염과 함수의 출처에 대한 불확실성 때문에 논쟁의 여지가 있긴하다 함 | ||
리액트에서도 es6 클래스 도입 이전에는 컴포넌트 기능 추가하기 위해 믹스인을 사용하곤 했는데, | ||
컴포넌트의 유지보수와 재사용을 복잡하게 만든다는 이유로 반대하고 HOC나 hooks 사용을 장려했다고 하네요 | ||
## 데코레이터 패턴 | ||
코드 재사용을 목표로 하는 구조 패턴 | ||
기본적으로 데코레이터는 기존 클래스에 동적으로 기능을 추가하기 위해 사용함 | ||
데코레이터 사용하면 기존 시스템의 내부 코드를 힘겹게 바꾸지 않고도 기능을 추가할 수 있게 됨 | ||
데코레이터 패턴을 사용하는 주된 이유는 애플리케이션의 기능이 다양한 타입의 객체를 필요로 할 수도 있기 때문이라고 함 | ||
예를 들어, hobbit, elf, orc 등 수백개의 생성자가 있고 캐릭터의 능력을 고려해 hobbitWithSword, hobbitWithWordAndRing 등등.. 조합에 따라 서브클래스를 엄청 만들어야 된다 | ||
객체의 생성을 신경 쓰지 않는 대신 기능의 확장에 좀 더 초점을 두는 것이다. | ||
이는 다시 말해, 서브 클래싱 대신 베이스 객체에 속성이나 메서드를 추가하여 간소화 하겠다는 아이디어다! | ||
장점: 유연하고 투명하게 사용될 수 있다! 베이스 객체가 변경될 걱정없이 사용 가능! | ||
단점: 잘 관리하지 않으면 애플리케이션 구조를 무척 복잡하게 만들 수도 있다 => 이건 충분한 문서화나 패턴에 대한 이해도를 높임으로써 해결 가능하다고 함 | ||
## 플라이웨이트 패턴 | ||
연관된 객체끼리 데이터를 공유하게 하면서 애플리케이션의 메모리를 최소화하는 패턴 | ||
> [!NOTE] | ||
> 경량급처럼 패턴의 목표가 메모리 공간의 경량화 이기 때문에 복싱 체급인 플라이급에서 이름을 따왔다고 한다 | ||
플라이웨이트의 데이터 공유 방식은 여러 비슷한 객체나 데이터 구조에서 공통적으로 사용하는 부분만 하나의 외부 객체로 내보내는 것으로 이루어진다 한다 | ||
> 이벤트 위임도 플라이웨이트 패턴 적용한 예시라고 함 | ||
> 솔직히 책 내용이 와닿지는 않아서 다른 아티클 보고 공부했다 | ||
> 플라이웨이트에 대해 잘 설명해주는 글 공유 하고 마무리 하겠습니다 | ||
> https://inpa.tistory.com/entry/GOF-%F0%9F%92%A0-Flyweight-%ED%8C%A8%ED%84%B4-%EC%A0%9C%EB%8C%80%EB%A1%9C-%EB%B0%B0%EC%9B%8C%EB%B3%B4%EC%9E%90 |