From 7ff3174ddceab27361f11f7add55f31df7fe1264 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Sun, 31 Mar 2024 21:17:12 +0900
Subject: [PATCH 01/43] Update README.md

Translation into Korean
---
 README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/README.md b/README.md
index 75b99c3..d3336af 100644
--- a/README.md
+++ b/README.md
@@ -3,6 +3,7 @@
 ## About
 
 PatternifyJS is a reference of the main design patterns in JavaScript. JS libraries are not covered, but the core scripting languages around JavaScript are there. Here is the list of all available languages:
+PatternifyJS는 JavaScript의 주요 디자인 패턴을 참조하는 것입니다. JS 라이브러리는 포함되어 있지 않지만 JavaScript 주변의 주요 스크립팅 언어가 있습니다. 모든 사용 가능한 언어 목록은 다음과 같습니다:
 
 * ECMAScript (Vanilla)
 	* ES5
@@ -11,6 +12,7 @@ PatternifyJS is a reference of the main design patterns in JavaScript. JS librar
 * TypeScript
 
 The Gang of Four (GoF) patterns are based on original synopses inspired from the real life and are available in two distinct flavors: "[classic](GoF/classic)" & "[idiomatic](GoF/idiomatic)".
+Gang of Four (GoF) 패턴은 실생활에서 영감을 받은 원본 개요를 기반으로 하며 두 가지 다른 스타일로 제공됩니다:"[classic](GoF/classic)" & "[idiomatic](GoF/idiomatic)".
 
 The classic style emulates the principles of traditional class-based object-oriented languages like Java. Therefore, this style makes heavy use of packages, abstraction, interfaces, classes, inheritance, composition, encapsulation and polymorphism. As a prototype-based language, JavaScript does not have all these functionalities natively (despite all the syntactic sugar introduced by ES6). But it is still possible to use and reproduce most of these concepts... For obvious reasons, constructor functions are the rule in the classic style and each design pattern of this category has its own UML class diagram.
 

From aa7504f18e85067c970d7ef0878e510f8b04ec7d Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Sun, 31 Mar 2024 21:17:29 +0900
Subject: [PATCH 02/43] Update README.md

---
 README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.md b/README.md
index d3336af..e63702f 100644
--- a/README.md
+++ b/README.md
@@ -3,6 +3,7 @@
 ## About
 
 PatternifyJS is a reference of the main design patterns in JavaScript. JS libraries are not covered, but the core scripting languages around JavaScript are there. Here is the list of all available languages:
+
 PatternifyJS는 JavaScript의 주요 디자인 패턴을 참조하는 것입니다. JS 라이브러리는 포함되어 있지 않지만 JavaScript 주변의 주요 스크립팅 언어가 있습니다. 모든 사용 가능한 언어 목록은 다음과 같습니다:
 
 * ECMAScript (Vanilla)

From 0cabc19cedbcefe505902026452cb3aa53f19931 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Sun, 31 Mar 2024 21:17:53 +0900
Subject: [PATCH 03/43] Update README.md

---
 README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/README.md b/README.md
index e63702f..e820661 100644
--- a/README.md
+++ b/README.md
@@ -13,6 +13,7 @@ PatternifyJS는 JavaScript의 주요 디자인 패턴을 참조하는 것입니
 * TypeScript
 
 The Gang of Four (GoF) patterns are based on original synopses inspired from the real life and are available in two distinct flavors: "[classic](GoF/classic)" & "[idiomatic](GoF/idiomatic)".
+
 Gang of Four (GoF) 패턴은 실생활에서 영감을 받은 원본 개요를 기반으로 하며 두 가지 다른 스타일로 제공됩니다:"[classic](GoF/classic)" & "[idiomatic](GoF/idiomatic)".
 
 The classic style emulates the principles of traditional class-based object-oriented languages like Java. Therefore, this style makes heavy use of packages, abstraction, interfaces, classes, inheritance, composition, encapsulation and polymorphism. As a prototype-based language, JavaScript does not have all these functionalities natively (despite all the syntactic sugar introduced by ES6). But it is still possible to use and reproduce most of these concepts... For obvious reasons, constructor functions are the rule in the classic style and each design pattern of this category has its own UML class diagram.

From 54ab98086da96f8169c7b2174d5dbaa144a3865a Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 09:29:11 +0900
Subject: [PATCH 04/43] Update README.md translate to korean

---
 README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/README.md b/README.md
index e820661..78d145b 100644
--- a/README.md
+++ b/README.md
@@ -16,7 +16,8 @@ The Gang of Four (GoF) patterns are based on original synopses inspired from the
 
 Gang of Four (GoF) 패턴은 실생활에서 영감을 받은 원본 개요를 기반으로 하며 두 가지 다른 스타일로 제공됩니다:"[classic](GoF/classic)" & "[idiomatic](GoF/idiomatic)".
 
-The classic style emulates the principles of traditional class-based object-oriented languages like Java. Therefore, this style makes heavy use of packages, abstraction, interfaces, classes, inheritance, composition, encapsulation and polymorphism. As a prototype-based language, JavaScript does not have all these functionalities natively (despite all the syntactic sugar introduced by ES6). But it is still possible to use and reproduce most of these concepts... For obvious reasons, constructor functions are the rule in the classic style and each design pattern of this category has its own UML class diagram.
+The classic style emulates the principles of traditional class-based object-oriented languages like Java. Therefore, this style makes heavy use of packages, abstraction, interfaces, classes, inheritance, composition, encapsulation and polymorphism. As a prototype-based language, JavaScript does not have all these functionalities natively (despite all the syntactic sugar introduced by ES6). But it is still possible to use and reproduce most of these concepts... For obvious reasons, constructor functions are the rule in the classic style and each design pattern of this category has its own UML class diagram.  
+클래식 스타일은 Java와 같은 전통적인 클래스 기반 객체지향 언어의 원칙을 모방합니다. 따라서 이 스타일은 패키지, 추상화, 인터페이스, 클래스, 상속, 구성, 캡슐화 및 다형성을 적극적으로 활용합니다. 프로토타입 기반 언어인 JavaScript는 이러한 기능을 네이티브로 갖고 있지 않습니다(ES6에 의해 도입된 모든 문법적 설탕에도 불구하고). 그러나 이러한 개념 대부분을 사용하고 재현하는 것은 여전히 가능합니다... 명백한 이유로 클래식 스타일에서는 생성자 함수가 규칙이며, 이 카테고리의 각 디자인 패턴에는 고유의 UML 클래스 다이어그램이 있습니다.
 
 The idiomatic style reveals the true nature of JavaScript. Constructor functions and classes are replaced by factory functions and object literals, there is no abstraction anymore, encapsulation is reduced to the minimum and flexibility raised to the maximum. With this style, the GoF patterns are a bit difficult to recognize because their overall structure is blurred. But here it is more reasonable to think about objects directly, not about classes. This is the reason why class diagrams have been replaced by UML object diagrams in the idiomatic style.
 

From c13ab08ebcccda81faf01ab1ae5503e262420454 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 09:38:39 +0900
Subject: [PATCH 05/43] Update README.md

translate to korean
---
 README.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 78d145b..17316e2 100644
--- a/README.md
+++ b/README.md
@@ -19,9 +19,11 @@ Gang of Four (GoF) 패턴은 실생활에서 영감을 받은 원본 개요를 
 The classic style emulates the principles of traditional class-based object-oriented languages like Java. Therefore, this style makes heavy use of packages, abstraction, interfaces, classes, inheritance, composition, encapsulation and polymorphism. As a prototype-based language, JavaScript does not have all these functionalities natively (despite all the syntactic sugar introduced by ES6). But it is still possible to use and reproduce most of these concepts... For obvious reasons, constructor functions are the rule in the classic style and each design pattern of this category has its own UML class diagram.  
 클래식 스타일은 Java와 같은 전통적인 클래스 기반 객체지향 언어의 원칙을 모방합니다. 따라서 이 스타일은 패키지, 추상화, 인터페이스, 클래스, 상속, 구성, 캡슐화 및 다형성을 적극적으로 활용합니다. 프로토타입 기반 언어인 JavaScript는 이러한 기능을 네이티브로 갖고 있지 않습니다(ES6에 의해 도입된 모든 문법적 설탕에도 불구하고). 그러나 이러한 개념 대부분을 사용하고 재현하는 것은 여전히 가능합니다... 명백한 이유로 클래식 스타일에서는 생성자 함수가 규칙이며, 이 카테고리의 각 디자인 패턴에는 고유의 UML 클래스 다이어그램이 있습니다.
 
-The idiomatic style reveals the true nature of JavaScript. Constructor functions and classes are replaced by factory functions and object literals, there is no abstraction anymore, encapsulation is reduced to the minimum and flexibility raised to the maximum. With this style, the GoF patterns are a bit difficult to recognize because their overall structure is blurred. But here it is more reasonable to think about objects directly, not about classes. This is the reason why class diagrams have been replaced by UML object diagrams in the idiomatic style.
+The idiomatic style reveals the true nature of JavaScript. Constructor functions and classes are replaced by factory functions and object literals, there is no abstraction anymore, encapsulation is reduced to the minimum and flexibility raised to the maximum. With this style, the GoF patterns are a bit difficult to recognize because their overall structure is blurred. But here it is more reasonable to think about objects directly, not about classes. This is the reason why class diagrams have been replaced by UML object diagrams in the idiomatic style.  
+관용적인 스타일은 JavaScript의 진정한 본질을 드러냅니다. 생성자 함수와 클래스는 팩토리 함수와 객체 리터럴로 대체되며, 더 이상 추상화가 없습니다. 캡슐화는 최소한으로 줄이고 유연성을 최대한 높입니다. 이 스타일에서는 GoF 패턴이 전반적인 구조가 흐릿해져 인식하기 약간 어렵지만, 여기서는 클래스가 아닌 객체에 직접 관심을 가지는 것이 더 합리적입니다. 이것이 관용적 스타일에서는 클래스 다이어그램이 UML 객체 다이어그램으로 대체된 이유입니다.
 
-Apart from the GoF patterns, there are also miscellaneous (functional and more) patterns in JavaScript that make life easier. They can be of a great help!
+Apart from the GoF patterns, there are also miscellaneous (functional and more) patterns in JavaScript that make life easier. They can be of a great help!  
+GoF 패턴 이외에도 JavaScript에는 더 다양한 (함수형 및 기타) 패턴이 있습니다. 이러한 패턴들은 삶을 더 쉽게 만들어 줄 수 있습니다!
 
 ## Gang of Four (GoF) patterns
 

From 0157e1d3433a6a8cd127ef77d0b555b0892ecd58 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 09:59:20 +0900
Subject: [PATCH 06/43] Update README.md

translated to korean
---
 misc/Module/README.md | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/misc/Module/README.md b/misc/Module/README.md
index 9d44bd9..d299b9c 100644
--- a/misc/Module/README.md
+++ b/misc/Module/README.md
@@ -1,9 +1,12 @@
 # Problem
 
-JavaScript is not very strict when it comes to encapsulation and each script tends to pollute the global namespace. This is because the language has been built with global variables in mind.
+JavaScript is not very strict when it comes to encapsulation and each script tends to pollute the global namespace. This is because the language has been built with global variables in mind.  
+JavaScript는 캡슐화에 대해 매우 엄격하지 않으며 각 스크립트는 전역 네임스페이스를 오염시키려고 합니다. 이는 언어가 전역 변수를 염두에 두고 구축되었기 때문입니다.
 
 # Solution
 
-The Module pattern is a great solution to encapsulate some code. The idea is to store in a variable the returned expression of an IIFE (Immediately-Invoked Function Expression), which can be for instance another function declared inside the module. Within the IIFE, the scope is private. We can then declare private variables and functions that will be invisible from the outside. Conceptually, a module is a bit like a class. 
+The Module pattern is a great solution to encapsulate some code. The idea is to store in a variable the returned expression of an IIFE (Immediately-Invoked Function Expression), which can be for instance another function declared inside the module. Within the IIFE, the scope is private. We can then declare private variables and functions that will be invisible from the outside. Conceptually, a module is a bit like a class.  
+모듈 패턴은 코드를 캡슐화하는 훌륭한 해결책입니다. 이 아이디어는 IIFE (즉시 호출 함수 표현식)의 반환 표현식을 변수에 저장하는 것입니다. 이 반환 표현식은 모듈 내에서 선언된 다른 함수일 수 있습니다. IIFE 내에서 스코프는 비공개입니다. 그러므로 모듈 내부에서 외부에서 보이지 않는 비공개 변수와 함수를 선언할 수 있습니다. 개념적으로 모듈은 클래스와 비슷합니다.
 
-N.B. In practice, this pattern is not often used anymore. CommonJS, AMD, or built-in ES6 modules are much better solutions nowadays...
+N.B. In practice, this pattern is not often used anymore. CommonJS, AMD, or built-in ES6 modules are much better solutions nowadays...  
+참고: 실제로 이 패턴은 더 이상 자주 사용되지 않습니다. 현재는 CommonJS, AMD 또는 내장된 ES6 모듈이 훨씬 더 나은 해결책입니다...

From 6b0ce0430ed543045da525da98c22a06ae49b4c7 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 11:38:42 +0900
Subject: [PATCH 07/43] Update README.md

translation (eng -> kor)
---
 GoF/idiomatic/Creational/AbstractFactory/README.md | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/GoF/idiomatic/Creational/AbstractFactory/README.md b/GoF/idiomatic/Creational/AbstractFactory/README.md
index d301e41..b79b733 100644
--- a/GoF/idiomatic/Creational/AbstractFactory/README.md
+++ b/GoF/idiomatic/Creational/AbstractFactory/README.md
@@ -1,16 +1,20 @@
 # Synopsis
 
-I am a sysadmin and I work for a company where each employee can choose its operating system. So I often need to install and run various operating systems based on GNU/Linux, Mac OS or Windows.
+I am a sysadmin and I work for a company where each employee can choose its operating system. So I often need to install and run various operating systems based on GNU/Linux, Mac OS or Windows.  
+저는 시스템 관리자로서 각 직원이 운영 체제를 선택할 수 있는 회사에서 일합니다. 그래서 저는 종종 GNU/Linux, Mac OS 또는 Windows 기반의 다양한 운영 체제를 설치하고 실행해야 합니다.
 
 # Problem
 
 There are several families of operating systems and there are many operating systems in each family.
-If we try to handle all the instantiation logic in the client code, it will most likely be a mess.
+If we try to handle all the instantiation logic in the client code, it will most likely be a mess.  
+운영 체제에는 여러 가족이 있으며 각 가족에는 많은 운영 체제가 있습니다. 모든 인스턴스화 로직을 클라이언트 코드에서 처리하려고 하면 대부분의 경우 혼란스러울 것입니다.
 
-As a system administrator, you only want to know how to get an instance of a specific OS in a given family. You do not need to know how Debian, Mac OS X or Windows XP have been programmed to make them available on some computers.
+As a system administrator, you only want to know how to get an instance of a specific OS in a given family. You do not need to know how Debian, Mac OS X or Windows XP have been programmed to make them available on some computers.  
+시스템 관리자로서, 특정 가족의 특정 운영 체제 인스턴스를 가져오는 방법만 알고 싶습니다. Debian, Mac OS X 또는 Windows XP가 어떻게 프로그래밍되어 일부 컴퓨터에서 사용 가능하게 되었는지 알 필요가 없습니다.
 
 # Solution
 
-AbstractFactory is a great solution here. We could consider it as a superset of the Factory pattern, but there is significantly more work to do. Indeed, we need a factory function for each OS family and of course a factory of factories that will be the entry point of the associated module.
+AbstractFactory is a great solution here. We could consider it as a superset of the Factory pattern, but there is significantly more work to do. Indeed, we need a factory function for each OS family and of course a factory of factories that will be the entry point of the associated module.  
+여기서 AbstractFactory는 훌륭한 해결책입니다. 이것은 Factory 패턴의 슈퍼셋으로 간주할 수 있지만, 수행해야 할 작업이 상당히 많습니다. 실제로 각 운영 체제 패밀리에 대한 팩토리 함수가 필요하며, 물론 해당 모듈의 진입점이 될 팩토리의 팩토리도 필요합니다.
 
 ![Abstract Factory (idiomatic)](AbstractFactory.png)

From 4f22bc8b22defcb5a22249eeca41d8959c591c56 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 11:43:29 +0900
Subject: [PATCH 08/43] Update client.js

translation eng to kr
---
 .../Creational/AbstractFactory/ECMAScript/ES5/client.js     | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Creational/AbstractFactory/ECMAScript/ES5/client.js b/GoF/idiomatic/Creational/AbstractFactory/ECMAScript/ES5/client.js
index aeb994b..028ef04 100644
--- a/GoF/idiomatic/Creational/AbstractFactory/ECMAScript/ES5/client.js
+++ b/GoF/idiomatic/Creational/AbstractFactory/ECMAScript/ES5/client.js
@@ -6,12 +6,14 @@ var getOSFactory = require('./API/factories');
 // CLIENT CODE 
 // ==============================
 
-// We can get concrete factories from the abstract factory
+// We can get concrete factories from the abstract factory  
+// 우리는 추상 팩토리로부터 구체적인 팩토리를 얻을 수 있습니다.
 var linuxFactory = getOSFactory('LINUX'),
     macFactory = getOSFactory('Mac'),
     windowsFactory = getOSFactory('windows');
 
-// Then we can get real objects from these concrete factories
+// Then we can get real objects from these concrete factories  
+// 그런 다음에 우리는 이러한 구체적인 팩토리로부터 실제 객체를 얻을 수 있습니다.
 var debian = linuxFactory('DEBIAN'),
     osx = macFactory('osX'),
     xp = windowsFactory('xp');

From ab18dca4dc9ddb581e28727ef4612b0087c1fd93 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 13:07:31 +0900
Subject: [PATCH 09/43] Update README.md

translation eng to kr
---
 GoF/idiomatic/Creational/Builder/README.md | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/GoF/idiomatic/Creational/Builder/README.md b/GoF/idiomatic/Creational/Builder/README.md
index 6e706e8..23a7add 100644
--- a/GoF/idiomatic/Creational/Builder/README.md
+++ b/GoF/idiomatic/Creational/Builder/README.md
@@ -1,21 +1,26 @@
 # Synopsis
 
-I have to buy a new PC, but not a standardized one. On the manufacturer's website, I chose every single component before validating my order. Now I am looking forward to using this new computer!
+I have to buy a new PC, but not a standardized one. On the manufacturer's website, I chose every single component before validating my order. Now I am looking forward to using this new computer!  
+새 컴퓨터를 사야 하는데, 표준화된 것이 아닌 사용자 정의 컴퓨터를 구매하려고 합니다. 제조사 웹사이트에서 주문을 확인하기 전에 각 구성 요소를 선택했습니다. 이제 이 새로운 컴퓨터를 사용하는 것을 기대하고 있습니다!
 
 # Problem
 
-A PC contains a lot of components that are dynamically assembled by a third-party workforce which is employed by a manufacturer. Due to the flexibility of JavaScript, it would be possible to have only one object (the PC) and manipulate its properties directly. But this is not ideal if we want to keep the basic structure of the problem that comes from a real-life situation.
+A PC contains a lot of components that are dynamically assembled by a third-party workforce which is employed by a manufacturer. Due to the flexibility of JavaScript, it would be possible to have only one object (the PC) and manipulate its properties directly. But this is not ideal if we want to keep the basic structure of the problem that comes from a real-life situation.  
+PC는 제조업체가 고용한 제3자 직원들에 의해 동적으로 조립되는 많은 구성 요소를 포함하고 있습니다. JavaScript의 유연성 덕분에 하나의 객체(컴퓨터)만 있어도 직접적으로 해당 속성을 조작할 수 있습니다. 그러나 이것은 실제 상황에서 유래한 문제의 기본 구조를 유지하고 싶을 때 이상적이지 않습니다.
 
 # Solution
 
-The Builder pattern allows us to build our PC step by step with only three objects (literals):
+The Builder pattern allows us to build our PC step by step with only three objects (literals):  
+빌더 패턴을 사용하면 세 개의 객체(리터럴)만 사용하여 단계별로 PC를 구축할 수 있습니다.
 
   * The PC
   * The workforce (e.g. a geek)
   * The manufacturer
 
-When the manufacturer will receive an order, it will ask its workforce to build the custom PC step by step through its "manufacture" method.
+When the manufacturer will receive an order, it will ask its workforce to build the custom PC step by step through its "manufacture" method.  
+제조업체가 주문을 받으면 해당 제조업체는 자신의 "제조" 메서드를 통해 직원에게 맞춤형 PC를 단계별로 구축하도록 요청할 것입니다.
 
 ![Builder (idiomatic)](Builder.png)
 
-N.B. Since we do not use constructor functions in the idiomatic style, this version of the Builder pattern is not a solution to the telescoping constructor problem. But you might be interested in the "Object Specifier" pattern...
+N.B. Since we do not use constructor functions in the idiomatic style, this version of the Builder pattern is not a solution to the telescoping constructor problem. But you might be interested in the "Object Specifier" pattern...  
+참고: 우리가 관용적인 스타일에서 생성자 함수를 사용하지 않기 때문에, 이 버전의 빌더 패턴은 맞춤형 생성자 문제의 해결책이 아닙니다. 그러나 "객체 지정자" 패턴에 관심이 있을 수도 있습니다...

From 75222b38d547fd812b23c9319759eb9d6e4e5747 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 13:17:47 +0900
Subject: [PATCH 10/43] Update README.md

translation ENG to KR
---
 misc/ObjectSpecifier/README.md | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/misc/ObjectSpecifier/README.md b/misc/ObjectSpecifier/README.md
index ff5aa35..2b6c949 100644
--- a/misc/ObjectSpecifier/README.md
+++ b/misc/ObjectSpecifier/README.md
@@ -1,10 +1,14 @@
 # Problem
 
-Functions may have a high arity, which means that they can accept a lot of arguments. This is not optimal for at least two reasons:
+Functions may have a high arity, which means that they can accept a lot of arguments. This is not optimal for at least two reasons:  
+함수는 높은 애리(arity)를 가질 수 있습니다. 이는 많은 인수를 받을 수 있다는 것을 의미합니다. 적어도 두 가지 이유로 이는 최적이 아닙니다:
 
   1. Keeping a nice-looking indentation is hard if the list of parameters is really long
-  2. It is difficult for the programmer to remember the order of many positional parameters 
+     매우 긴 매개변수 목록의 경우 보기 좋은 들여쓰기를 유지하는 것이 어렵습니다.
+  3. It is difficult for the programmer to remember the order of many positional parameters  
+     많은 위치 매개변수의 순서를 기억하는 것은 프로그래머에게 어려운 일입니다.  
 
 # Solution
 
-An object specifier (a.k.a. options object) is a simple object literal that is passed to a function instead of a long series of arguments. In other words, when a function has lots of formal parameters in its signature, it is generally a good idea to refactor it and give it only one parameter (that will be the object specifier). The good point with this pattern is that it allows named parameters instead of positional parameters, so that the order is not even a problem anymore.
+An object specifier (a.k.a. options object) is a simple object literal that is passed to a function instead of a long series of arguments. In other words, when a function has lots of formal parameters in its signature, it is generally a good idea to refactor it and give it only one parameter (that will be the object specifier). The good point with this pattern is that it allows named parameters instead of positional parameters, so that the order is not even a problem anymore.  
+객체 지정자(또는 옵션 객체)는 긴 인수 목록 대신 함수에 전달되는 간단한 객체 리터럴입니다. 다시 말해, 함수의 시그니처에 많은 형식 매개변수가 있는 경우, 일반적으로 해당 함수를 리팩터링하여 하나의 매개변수만 전달하는 것이 좋습니다(이것이 객체 지정자가 될 것입니다). 이 패턴의 장점은 위치 매개변수 대신에 이름있는 매개변수를 사용할 수 있으므로 순서가 더 이상 문제가 되지 않는다는 것입니다.

From 87a6b8b6d4a61590b1f226739f609d8883322988 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 13:30:33 +0900
Subject: [PATCH 11/43] Update README.md

translation
ENG to KR
---
 GoF/idiomatic/Creational/Factory/README.md | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/GoF/idiomatic/Creational/Factory/README.md b/GoF/idiomatic/Creational/Factory/README.md
index 8efac29..b110e10 100644
--- a/GoF/idiomatic/Creational/Factory/README.md
+++ b/GoF/idiomatic/Creational/Factory/README.md
@@ -1,6 +1,7 @@
 # Synopsis
 
-I am a fan of GNU/Linux distributions and I want to test the big names: Debian, RedHat, Slackware.
+I am a fan of GNU/Linux distributions and I want to test the big names: Debian, RedHat, Slackware.  
+저는 GNU/Linux 배포판의 팬이며, Debian, RedHat, Slackware와 같은 주요 배포판을 테스트하고 싶습니다.
 
 # Problem
 

From 7e3f4ea1db7418626a6eb059e418c3f619acc323 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 13:33:26 +0900
Subject: [PATCH 12/43] Update README.md

translation
ENG to KOR
---
 GoF/idiomatic/Creational/Factory/README.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/GoF/idiomatic/Creational/Factory/README.md b/GoF/idiomatic/Creational/Factory/README.md
index b110e10..2146d28 100644
--- a/GoF/idiomatic/Creational/Factory/README.md
+++ b/GoF/idiomatic/Creational/Factory/README.md
@@ -8,7 +8,11 @@ I am a fan of GNU/Linux distributions and I want to test the big names: Debian,
 Debian, RedHat and Slackware are all Linux distributions.
 We could create directly an object literal to represent each one, but this is not necessarily the best choice.
 We are not sure to use each instance in our code and we do not want to use memory for nothing.
-For the sake of clarity and performance, it may be nice to delegate the instantiation logic.
+For the sake of clarity and performance, it may be nice to delegate the instantiation logic.    
+Debian, RedHat 및 Slackware는 모두 Linux 배포판입니다.
+우리는 각각을 나타내는 객체 리터럴을 직접 생성할 수 있지만, 이것이 반드시 최선의 선택은 아닙니다.
+우리는 각 인스턴스를 코드에서 사용할지 확신하지 않으며, 아무것도 사용하지 않고 메모리를 사용하고 싶지 않습니다.
+명확성과 성능을 위해 인스턴스화 논리를 위임하는 것이 좋을 수 있습니다.
 
 # Solution
 

From e5ffcbe7282001232ba855f87a760aa7a67c3333 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 13:42:07 +0900
Subject: [PATCH 13/43] Update README.md

translation
ENG to KOR
---
 GoF/idiomatic/Creational/Factory/README.md | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Creational/Factory/README.md b/GoF/idiomatic/Creational/Factory/README.md
index 2146d28..5225d25 100644
--- a/GoF/idiomatic/Creational/Factory/README.md
+++ b/GoF/idiomatic/Creational/Factory/README.md
@@ -16,8 +16,10 @@ Debian, RedHat 및 Slackware는 모두 Linux 배포판입니다.
 
 # Solution
 
-Factory makes it possible to do so. To implement this design pattern, we only need to create a function that will return objects.
+Factory makes it possible to do so. To implement this design pattern, we only need to create a function that will return objects.  
+팩토리를 사용하면 이를 수행할 수 있습니다. 이 디자인 패턴을 구현하기 위해서는 객체를 반환할 함수를 생성하면 됩니다.
 
-In JavaScript, a function or method that returns objects is generally considered as a factory. It is a well-known idiomatic alternative to the use of the "new" keyword along with constructor functions.
+In JavaScript, a function or method that returns objects is generally considered as a factory. It is a well-known idiomatic alternative to the use of the "new" keyword along with constructor functions.  
+자바스크립트에서 객체를 반환하는 함수나 메서드는 일반적으로 팩토리로 간주됩니다. 이것은 "new" 키워드를 생성자 함수와 함께 사용하는 것에 대한 잘 알려진 관용적 대안입니다.
 
 ![Factory (idiomatic)](Factory.png)

From 0d34d7b1832cc6deb49e9fe0755dcbc5164c43e4 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 13:50:12 +0900
Subject: [PATCH 14/43] Update README.md

---
 README.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/README.md b/README.md
index 17316e2..2b99ec8 100644
--- a/README.md
+++ b/README.md
@@ -17,12 +17,15 @@ The Gang of Four (GoF) patterns are based on original synopses inspired from the
 Gang of Four (GoF) 패턴은 실생활에서 영감을 받은 원본 개요를 기반으로 하며 두 가지 다른 스타일로 제공됩니다:"[classic](GoF/classic)" & "[idiomatic](GoF/idiomatic)".
 
 The classic style emulates the principles of traditional class-based object-oriented languages like Java. Therefore, this style makes heavy use of packages, abstraction, interfaces, classes, inheritance, composition, encapsulation and polymorphism. As a prototype-based language, JavaScript does not have all these functionalities natively (despite all the syntactic sugar introduced by ES6). But it is still possible to use and reproduce most of these concepts... For obvious reasons, constructor functions are the rule in the classic style and each design pattern of this category has its own UML class diagram.  
+
 클래식 스타일은 Java와 같은 전통적인 클래스 기반 객체지향 언어의 원칙을 모방합니다. 따라서 이 스타일은 패키지, 추상화, 인터페이스, 클래스, 상속, 구성, 캡슐화 및 다형성을 적극적으로 활용합니다. 프로토타입 기반 언어인 JavaScript는 이러한 기능을 네이티브로 갖고 있지 않습니다(ES6에 의해 도입된 모든 문법적 설탕에도 불구하고). 그러나 이러한 개념 대부분을 사용하고 재현하는 것은 여전히 가능합니다... 명백한 이유로 클래식 스타일에서는 생성자 함수가 규칙이며, 이 카테고리의 각 디자인 패턴에는 고유의 UML 클래스 다이어그램이 있습니다.
 
 The idiomatic style reveals the true nature of JavaScript. Constructor functions and classes are replaced by factory functions and object literals, there is no abstraction anymore, encapsulation is reduced to the minimum and flexibility raised to the maximum. With this style, the GoF patterns are a bit difficult to recognize because their overall structure is blurred. But here it is more reasonable to think about objects directly, not about classes. This is the reason why class diagrams have been replaced by UML object diagrams in the idiomatic style.  
+
 관용적인 스타일은 JavaScript의 진정한 본질을 드러냅니다. 생성자 함수와 클래스는 팩토리 함수와 객체 리터럴로 대체되며, 더 이상 추상화가 없습니다. 캡슐화는 최소한으로 줄이고 유연성을 최대한 높입니다. 이 스타일에서는 GoF 패턴이 전반적인 구조가 흐릿해져 인식하기 약간 어렵지만, 여기서는 클래스가 아닌 객체에 직접 관심을 가지는 것이 더 합리적입니다. 이것이 관용적 스타일에서는 클래스 다이어그램이 UML 객체 다이어그램으로 대체된 이유입니다.
 
 Apart from the GoF patterns, there are also miscellaneous (functional and more) patterns in JavaScript that make life easier. They can be of a great help!  
+
 GoF 패턴 이외에도 JavaScript에는 더 다양한 (함수형 및 기타) 패턴이 있습니다. 이러한 패턴들은 삶을 더 쉽게 만들어 줄 수 있습니다!
 
 ## Gang of Four (GoF) patterns

From ceb6dede7f19d753d23f87361b61893a3bb366b2 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 13:52:36 +0900
Subject: [PATCH 15/43] Update README.md

---
 misc/RevealingModule/README.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/misc/RevealingModule/README.md b/misc/RevealingModule/README.md
index 90eeac3..91741c8 100644
--- a/misc/RevealingModule/README.md
+++ b/misc/RevealingModule/README.md
@@ -2,12 +2,18 @@
 
 JavaScript is not very strict when it comes to encapsulation and each script tends to pollute the global namespace. This is because the language has been built with global variables in mind.
 
+JavaScript는 캡슐화에 대해 엄격하지 않으며 각 스크립트는 전역 네임스페이스를 오염시키는 경향이 있습니다. 이는 언어가 전역 변수를 염두에 두고 만들어졌기 때문입니다.
+
 # Solution
 
 The Revealing Module pattern is a great solution to encapsulate some code. The idea is to store in a variable the returned expression of an IIFE (Immediately-Invoked Function Expression), which is generally an object literal that exposes all public members of the module. Within the IIFE, the scope is private. We can then declare private variables and functions that will be invisible from the outside. Conceptually, a module is a bit like a class. 
 
+Revealing Module 패턴은 일부 코드를 캡슐화하는 훌륭한 해결책입니다. 이 아이디어는 IIFE(즉시 호출되는 함수 표현식)의 반환 표현식을 변수에 저장하는 것입니다. 이 반환 표현식은 일반적으로 모듈의 모든 공개 멤버를 노출하는 객체 리터럴입니다. IIFE 내에서 범위는 비공개입니다. 따라서 외부에서는 보이지 않는 비공개 변수와 함수를 선언할 수 있습니다. 개념적으로 모듈은 클래스와 약간 비슷합니다.
+
 N.B. In practice, this pattern is not often used anymore. CommonJS, AMD, or built-in ES6 modules are much better solutions nowadays... However, the legacy of this pattern is still visible in ES5 code, especially in CommonJS modules where module.exports exposes public members using an object literal.
 
+참고: 실제로 이 패턴은 더 이상 자주 사용되지 않습니다. 현재는 CommonJS, AMD 또는 내장 ES6 모듈이 훨씬 더 좋은 해결책입니다. 그러나 이 패턴의 유산은 여전히 ES5 코드에서 볼 수 있으며, 특히 module.exports를 사용하여 객체 리터럴을 이용해 공개 멤버를 노출하는 CommonJS 모듈에서는 이 패턴의 영향을 여전히 확인할 수 있습니다.
+
 ```javascript
 // CommonJS (Revealing) Module exports
 module.exports = {

From fe92de76ac5e269b1e212a48893378d2f842d28f Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:07:50 +0900
Subject: [PATCH 16/43] Update README.md

---
 misc/MethodChaining/README.md | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/misc/MethodChaining/README.md b/misc/MethodChaining/README.md
index 3d57074..c59e6ec 100644
--- a/misc/MethodChaining/README.md
+++ b/misc/MethodChaining/README.md
@@ -1,7 +1,11 @@
 # Problem
 
-In a program, we may have a lot of function calls on the same object. This often leads to repetition because it is necessary to write the reference again and again.
+In a program, we may have a lot of function calls on the same object. This often leads to repetition because it is necessary to write the reference again and again. 
+
+프로그램에서 동일한 객체에 대해 많은 함수 호출이 발생할 수 있습니다. 이로 인해 동일한 참조를 반복적으로 작성해야 하므로 반복이 발생할 수 있습니다.
 
 # Solution
 
 Method Chaining allows us to make multiple calls on the same object without repeating ourselves. This pattern is very easy to use because the only thing to do is to return the current object ("this") in all methods that are supposed to be "chainable".
+
+메소드 체이닝을 사용하면 동일한 객체에서 여러 호출을 반복하지 않고도 여러 호출을 수행할 수 있습니다. 이 패턴은 매우 쉽게 사용할 수 있으며, "체인 가능한" 메소드에서는 모두 현재 객체("this")를 반환하기만 하면 됩니다.

From c46ea322a59a023276931785a1cec1f0b90f835f Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:22:36 +0900
Subject: [PATCH 17/43] Update README.md

---
 README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.md b/README.md
index 2b99ec8..0e4abbe 100644
--- a/README.md
+++ b/README.md
@@ -59,7 +59,7 @@ GoF 패턴 이외에도 JavaScript에는 더 다양한 (함수형 및 기타) 
 	* Template ([classic](GoF/classic/Behavioral/Template) | [idiomatic](GoF/idiomatic/Behavioral/Template))
 	* Visitor ([classic](GoF/classic/Behavioral/Visitor) | [idiomatic](GoF/idiomatic/Behavioral/Visitor))
 
-## Miscellaneous patterns
+## Miscellaneous patterns 여러 가지 패턴
 
 * [Currying](misc/Currying)
 * [Method Chaining](misc/MethodChaining)

From 5f2d3de817e0c9316a65ad9bbd02b3e6b0ea0312 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:25:29 +0900
Subject: [PATCH 18/43] Update README.md

---
 misc/Currying/README.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/misc/Currying/README.md b/misc/Currying/README.md
index 2ac905d..5734db5 100644
--- a/misc/Currying/README.md
+++ b/misc/Currying/README.md
@@ -2,8 +2,12 @@
 
 Functions may have a high arity, which means that they can accept a lot of arguments. This is not optimal for at least two reasons:
 
-  1. Keeping a nice-looking indentation is hard if the list of parameters is really long
-  2. It is difficult for the programmer to remember the order of many positional parameters 
+함수는 높은 아리티(arity)를 가질 수 있습니다. 이는 많은 인수를 받을 수 있다는 것을 의미합니다. 적어도 두 가지 이유로 이는 최적이 아닙니다:
+
+  1. Keeping a nice-looking indentation is hard if the list of parameters is really long  
+     매우 긴 매개변수 목록의 경우 보기 좋은 들여쓰기를 유지하는 것이 어렵습니다.
+  2. It is difficult for the programmer to remember the order of many positional parameters  
+     많은 위치 매개변수의 순서를 기억하는 것은 프로그래머에게 어려운 일입니다.
 
 # Solution
 

From 9d73c4d5c4d526c6eab7929dc67ee4509bcaa3ab Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:27:16 +0900
Subject: [PATCH 19/43] Update README.md

---
 misc/Currying/README.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/misc/Currying/README.md b/misc/Currying/README.md
index 5734db5..b76a9c5 100644
--- a/misc/Currying/README.md
+++ b/misc/Currying/README.md
@@ -12,4 +12,6 @@ Functions may have a high arity, which means that they can accept a lot of argum
 # Solution
 
 We can use currying to reduce the arity of a function. The aim of this pattern is to transform a function with many parameters into multiple functions with only one parameter.
-Since JavaScript is an extremely flexible language, the only thing to do is to create a sort of "return chain" where each function returns another function (with only one parameter) until the number of parameters is exhausted.
+Since JavaScript is an extremely flexible language, the only thing to do is to create a sort of "return chain" where each function returns another function (with only one parameter) until the number of parameters is exhausted.  
+커링을 사용하여 함수의 아리티(arity)를 줄일 수 있습니다. 이 패턴의 목표는 많은 매개변수를 가진 함수를 하나의 매개변수만 가진 여러 함수로 변환하는 것입니다. JavaScript는 매우 유연한 언어이기 때문에, 각 함수가 다음 함수(하나의 매개변수만 있는 함수)를 반환하는 일종의 "반환 체인"을 생성하면 됩니다. 이를 통해 매개변수의 개수가 소진될 때까지 함수를 연속적으로 호출할 수 있습니다.
+

From ece03756638c049eb918d3130cad896701bd7b77 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:27:28 +0900
Subject: [PATCH 20/43] Update README.md

---
 misc/Currying/README.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/misc/Currying/README.md b/misc/Currying/README.md
index b76a9c5..4a6edd2 100644
--- a/misc/Currying/README.md
+++ b/misc/Currying/README.md
@@ -13,5 +13,6 @@ Functions may have a high arity, which means that they can accept a lot of argum
 
 We can use currying to reduce the arity of a function. The aim of this pattern is to transform a function with many parameters into multiple functions with only one parameter.
 Since JavaScript is an extremely flexible language, the only thing to do is to create a sort of "return chain" where each function returns another function (with only one parameter) until the number of parameters is exhausted.  
+
 커링을 사용하여 함수의 아리티(arity)를 줄일 수 있습니다. 이 패턴의 목표는 많은 매개변수를 가진 함수를 하나의 매개변수만 가진 여러 함수로 변환하는 것입니다. JavaScript는 매우 유연한 언어이기 때문에, 각 함수가 다음 함수(하나의 매개변수만 있는 함수)를 반환하는 일종의 "반환 체인"을 생성하면 됩니다. 이를 통해 매개변수의 개수가 소진될 때까지 함수를 연속적으로 호출할 수 있습니다.
 

From d9efef19277170f542e31bcb90aadc66fcac5795 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:35:59 +0900
Subject: [PATCH 21/43] Update README.md

---
 GoF/idiomatic/Creational/Prototype/README.md | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/GoF/idiomatic/Creational/Prototype/README.md b/GoF/idiomatic/Creational/Prototype/README.md
index 3fc2fd5..364bf89 100644
--- a/GoF/idiomatic/Creational/Prototype/README.md
+++ b/GoF/idiomatic/Creational/Prototype/README.md
@@ -4,6 +4,8 @@ When I order something, I sometimes like to have a paper invoice.
 But when the order is important, I do not want to lose the document.
 Therefore, I want to be able to make photocopies.
 
+뭔가를 주문할 때 종종 종이 송장을 받는 것을 좋아합니다. 그러나 주문이 중요할 때에는 문서를 잃고 싶지 않습니다. 그래서 사본을 만들 수 있었으면 좋겠습니다.
+
 # Problem
 
 Creating a new object with "new" is not the same thing as cloning an existing object.
@@ -14,13 +16,20 @@ The parameter of this method (the original object) is used as the prototype of t
 This means the new object will not have own properties like the original object.
 These properties would be available in the new object, but in its prototype.
 
+"new"를 사용하여 새 객체를 생성하는 것은 기존 객체를 복제하는 것과 같지 않습니다. 자바스크립트의 장점은 언어가 프로토타입 기반임입니다. 내장된 Object.create() 메서드는 이미 어떤 형태의 복제를 수행합니다. 그러나 Object.create()만 사용하면 제대로 복제할 수 없습니다. 이 메서드의 매개변수(원본 객체)는 새 객체의 프로토타입으로 사용됩니다. 이는 새 객체가 원본 객체와 같은 속성을 가지지 않을 것을 의미합니다. 이러한 속성은 새 객체에서 사용할 수 있지만 그것의 프로토타입에 있을 것입니다.
+
 # Solution
 
-We need only two things in this situation:
+We need only two things in this situation:  
+이 상황에서 우리는 두 가지만 필요합니다:
 
   * An object (literal) that we want to clone (e.g. invoice)
+    우리가 복제하고자 하는 객체(리터럴) (예: 송장)
   * A custom cloning function that will take the object to clone as a parameter
+    복제할 객체를 매개변수로 받는 사용자 정의 복제 함수
 
 ![Prototype (idiomatic)](Prototype.png)
 
 N.B. Most of the time, it is not even useful to have an exact copy of an object in JavaScript. The important thing is often to be able to use the same properties on several objects, and for that purpose, a simple Object.create() is generally good enough.
+
+참고: 대부분의 경우에는 JavaScript에서 객체의 정확한 복사본을 가지는 것이 실제로 유용하지 않습니다. 중요한 것은 종종 여러 객체에서 동일한 속성을 사용할 수 있는 것입니다. 이를 위해 간단한 Object.create()를 사용하는 것이 일반적으로 충분합니다.

From 60a09c49df73cd31b20dafa36edd425657b27dbe Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:37:53 +0900
Subject: [PATCH 22/43] Update README.md

---
 GoF/idiomatic/Creational/Prototype/README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Creational/Prototype/README.md b/GoF/idiomatic/Creational/Prototype/README.md
index 364bf89..417d28c 100644
--- a/GoF/idiomatic/Creational/Prototype/README.md
+++ b/GoF/idiomatic/Creational/Prototype/README.md
@@ -23,9 +23,9 @@ These properties would be available in the new object, but in its prototype.
 We need only two things in this situation:  
 이 상황에서 우리는 두 가지만 필요합니다:
 
-  * An object (literal) that we want to clone (e.g. invoice)
+  * An object (literal) that we want to clone (e.g. invoice)  
     우리가 복제하고자 하는 객체(리터럴) (예: 송장)
-  * A custom cloning function that will take the object to clone as a parameter
+  * A custom cloning function that will take the object to clone as a parameter  
     복제할 객체를 매개변수로 받는 사용자 정의 복제 함수
 
 ![Prototype (idiomatic)](Prototype.png)

From f9dc3b0bfbd9e7640ce952909a85a7a62b2f0232 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 14:43:33 +0900
Subject: [PATCH 23/43] Update photocopy.js

---
 .../Creational/Prototype/ECMAScript/ES5/API/photocopy.js        | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/GoF/idiomatic/Creational/Prototype/ECMAScript/ES5/API/photocopy.js b/GoF/idiomatic/Creational/Prototype/ECMAScript/ES5/API/photocopy.js
index 6f472ad..126cc26 100644
--- a/GoF/idiomatic/Creational/Prototype/ECMAScript/ES5/API/photocopy.js
+++ b/GoF/idiomatic/Creational/Prototype/ECMAScript/ES5/API/photocopy.js
@@ -7,6 +7,8 @@
 module.exports = function (invoice) {
     // Here we suppose invoice properties are always enumerable, writable and configurable.
     // If not, we should use Object.defineProperty() along with Object.getOwnPropertyDescriptor().
+    // 여기서는 속성이 항상 enumerable, writable 및 configurable로 가정합니다.
+    // 그렇지 않은 경우에는 Object.defineProperty()와 Object.getOwnPropertyDescriptor()를 함께 사용해야 합니다.
     var clone = Object.create(Object.getPrototypeOf(invoice));
     for (var prop in invoice) {
         if (invoice.hasOwnProperty(prop)) {

From c8726505fa3abe0da64a6b3b2acb174a5e0c104a Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 16:07:53 +0900
Subject: [PATCH 24/43] Update README.md

---
 GoF/idiomatic/Creational/Singleton/README.md | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/GoF/idiomatic/Creational/Singleton/README.md b/GoF/idiomatic/Creational/Singleton/README.md
index 1b31416..51cecdd 100644
--- a/GoF/idiomatic/Creational/Singleton/README.md
+++ b/GoF/idiomatic/Creational/Singleton/README.md
@@ -1,21 +1,31 @@
 # Synopsis
 
-As a person, I am unique. No one has exactly my DNA.
+As a person, I am unique. No one has exactly my DNA.  
+
+나로서, 나는 독특합니다. 나와 똑같은 DNA를 가진 사람은 아무도 없습니다.
 
 # Problem
 
-In JavaScript, we can create several instances of everything using:
+In JavaScript, we can create several instances of everything using:  
+자바스크립트에서는 "모든 것"의 여러 인스턴스를 생성할 수 있습니다.
 
   * An object literal: e.g. {}
+    객체 리터럴: 예를 들면 {}
   * The static method "create" of "Object": e.g. Object.create(Object.prototype)
+    "Object"의 정적 메서드 "create": 예를 들면 Object.create(Object.prototype)
   * The "new" operator on a constructor function: e.g. new Object()
+    생성자 함수에 대한 "new" 연산자: 예를 들면 new Object()
 
-Therefore, I cannot be sure that there will not be other instances of myself in the code!
+Therefore, I cannot be sure that there will not be other instances of myself in the code!  
+따라서 코드 내에 나와 동일한 다른 인스턴스가 없을 것을 확신할 수 없습니다!
 
 # Solution
 
-Singleton is the key!
+Singleton is the key!  
+싱글톤이 해답입니다!
 
 But due to the nature of JavaScript, an object literal is already a sort of Singleton. Each object literal is unique and is built from the prototype of Object. In a way, we could see an object literal as a an anonymous class whose instance is delivered immediately. However, we could also argue that an object literal is nothing more than an instance of Object, which is actually true. With this in mind, it is quite obvious that an object literal is not a pure Singleton, but if flexibility matters, it is quite reasonable to consider it as a Singleton.
 
+그러나 JavaScript의 특성 때문에 객체 리터럴은 이미 일종의 싱글톤입니다. 각각의 객체 리터럴은 고유하며 Object의 프로토타입에서 만들어집니다. 어느 정도로는, 객체 리터럴은 즉시 전달되는 익명 클래스의 인스턴스로 볼 수 있습니다. 그러나 객체 리터럴은 사실 Object의 인스턴스에 불과하다는 것을 주장할 수도 있습니다. 이를 염두에 두면, 객체 리터럴이 순수한 싱글톤이 아닌 것은 분명하지만, 유연성이 중요한 경우에는 싱글톤으로 고려하는 것이 매우 합리적입니다.
+
 ![Singleton (idiomatic)](Singleton.png)

From 8047aa88339afed02727ca80ac4f9a27bb4f6f20 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 16:09:43 +0900
Subject: [PATCH 25/43] Update client.js

---
 GoF/idiomatic/Creational/Singleton/ECMAScript/ES5/client.js | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/GoF/idiomatic/Creational/Singleton/ECMAScript/ES5/client.js b/GoF/idiomatic/Creational/Singleton/ECMAScript/ES5/client.js
index 623ce7a..789a2ef 100644
--- a/GoF/idiomatic/Creational/Singleton/ECMAScript/ES5/client.js
+++ b/GoF/idiomatic/Creational/Singleton/ECMAScript/ES5/client.js
@@ -9,6 +9,9 @@ var me = require('./API/me'),
 
 // It will display 'OK' since 'me' and 'meAgain' are references to the same object.
 // Only one instance exists in the code. This is what we expect from a Singleton. :)
+// 'me'와 'meAgain'이 동일한 객체를 참조하기 때문에 'OK'가 표시됩니다.
+// 코드에는 하나의 인스턴스만 존재합니다. 이것이 싱글톤으로 기대하는 바입니다. :)
+
 if (me === meAgain) {
     console.log("OK");
 } else {

From 9d3745a0ddc734700c18a1c28c4759e95cd12183 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 16:17:37 +0900
Subject: [PATCH 26/43] Update README.md

---
 GoF/idiomatic/Structural/Adapter/README.md | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Structural/Adapter/README.md b/GoF/idiomatic/Structural/Adapter/README.md
index c3b6c21..61ee415 100644
--- a/GoF/idiomatic/Structural/Adapter/README.md
+++ b/GoF/idiomatic/Structural/Adapter/README.md
@@ -2,17 +2,26 @@
 
 I have some amazing photos on my computer that I would like to display using my old projector. But my PC uses HDMI and my projector uses VGA.
 
+내 컴퓨터에는 HDMI를 사용하고 프로젝터에는 VGA를 사용하는데, 컴퓨터에 저장된 멋진 사진을 옛날 프로젝터로 보여주고 싶어요.
+
 # Problem
 
 HDMI and VGA are not compatible interfaces. HDMI can handle images and sound through a digital signal whereas VGA can only handle images through an analog signal.
 
+HDMI와 VGA는 호환되지 않는 인터페이스입니다. HDMI는 디지털 신호를 통해 이미지와 소리를 처리할 수 있지만, VGA는 아날로그 신호를 통해 이미지만 처리할 수 있습니다.
+
 # Solution
 
-Adapter is a well-known solution in this kind of situation. Here we need very few things:
+Adapter is a well-known solution in this kind of situation. Here we need very few things:  
+이러한 상황에서 어댑터는 잘 알려진 해결책입니다. 여기서는 매우 적은 것이 필요합니다:
 
-  * An object (literal) that represents the VGA connection
+  * An object (literal) that represents the VGA connection  
+    VGA 연결을 나타내는 객체(리터럴)
   * An object (literal) that represents the HDMI to VGA adapter
+    HDMI에서 VGA로의 어댑터를 나타내는 객체(리터럴)
 
 The latter must have a reference to the first one and must be the entry point of the module. Then the main method of the adapter will delegate some work to the main method of the VGA connection.
 
+후자는 전자에 대한 참조를 가져야 하며 모듈의 진입점이어야 합니다. 그런 다음 어댑터의 주 메서드는 VGA 연결의 주 메서드로 일부 작업을 위임해야 합니다.
+
 ![Adapter (idiomatic)](Adapter.png)

From f51c327cc0841a86d8ceccf38846f483bc99c33c Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 16:20:57 +0900
Subject: [PATCH 27/43] Update connections.js

---
 .../Structural/Adapter/ECMAScript/ES5/API/connections.js       | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/GoF/idiomatic/Structural/Adapter/ECMAScript/ES5/API/connections.js b/GoF/idiomatic/Structural/Adapter/ECMAScript/ES5/API/connections.js
index f8f7930..c9b79e1 100644
--- a/GoF/idiomatic/Structural/Adapter/ECMAScript/ES5/API/connections.js
+++ b/GoF/idiomatic/Structural/Adapter/ECMAScript/ES5/API/connections.js
@@ -5,6 +5,7 @@
 // ==============================
 
 // VGA has its own interface which handles images only through an analog signal
+// VGA는 아날로그 신호를 통해 이미지만 처리하는 고유한 인터페이스를 갖고 있습니다.
 var vga = {
     name: "VGA",
     data: "images",
@@ -16,6 +17,8 @@ var vga = {
 
 // But your computer uses HDMI as output and your projector uses VGA as input...
 // Here you need an adapter if you want to display images.
+// 그러나 컴퓨터는 출력으로 HDMI를 사용하고 프로젝터는 입력으로 VGA를 사용합니다...
+// 여기서 이미지를 표시하려면 어댑터가 필요합니다.
 module.exports = {
     vga: vga,
     handleDigitalSignal: function () {

From 724b4bffa8ead11df2c39763fea64e605b6afe64 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 16:43:38 +0900
Subject: [PATCH 28/43] Update README.md

---
 GoF/idiomatic/Structural/Proxy/README.md | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/GoF/idiomatic/Structural/Proxy/README.md b/GoF/idiomatic/Structural/Proxy/README.md
index a04f89c..2aadf06 100644
--- a/GoF/idiomatic/Structural/Proxy/README.md
+++ b/GoF/idiomatic/Structural/Proxy/README.md
@@ -2,19 +2,32 @@
 
 I need some cash, so I have to find an ATM (Automated Teller Machine).
 
+돈이 필요해서 ATM(자동화된 입출금기)를 찾아야 합니다.
+
 # Problem
 
-Money withdrawal is under control. Everyone has a personal bank account which is only accessible with a specific credit card and a related code.
+Money withdrawal is under control. Everyone has a personal bank account which is only accessible with a specific credit card and a related code. 
+
+돈을 인출하는 것은 통제되고 있습니다. 각각의 사람은 특정 신용카드와 관련 코드로만 접근 가능한 개인 은행 계좌를 가지고 있습니다.
 
 For this reason, we cannot interact directly with the "real" object (our bank account). We must interact with another object that will be responsible for the communication with the real object.
 
+이러한 이유로 우리는 "실제" 객체(우리의 은행 계좌)와 직접 상호 작용할 수 없습니다. 대신 실제 객체와 통신을 담당할 다른 객체와 상호 작용해야 합니다.
+
+
 # Solution
 
 We could consider an ATM as a Proxy whose aim is to verify access to a bank account. Implementing this is not really hard because we just need:
 
+우리는 ATM을 은행 계좌 접근을 확인하는 목적의 프록시로 간주할 수 있습니다. 이를 구현하는 것은 그리 어렵지 않습니다. 필요한 것은 다음과 같습니다:
+
   * A simple object (literal) to represent the bank account
+    은행 계좌를 나타내는 간단한 객체(리터럴)
   * A more complex object (literal) to represent the ATM that we use as a proxy
+    프록시로 사용하는 ATM을 나타내는 좀 더 복잡한 객체(리터럴)
 
 The bank account should be invisible from the outside of its module, contrary to the ATM that will have to handle cash withdrawal directly. The process is simple: we start with code verification, then the ATM delegates the operation to the real bank account if the code is correct. If it is not, an exception is thrown and the bank account cannot be reached. 
 
+은행 계좌는 모듈 외부에서는 보이지 않아야 하지만, ATM은 현금 인출을 직접 처리해야 합니다. 프로세스는 간단합니다: 코드 검증부터 시작하여, ATM은 코드가 올바른 경우에만 실제 은행 계좌로 작업을 위임합니다. 그렇지 않은 경우 예외가 발생하고 은행 계좌에 접근할 수 없게 됩니다.
+
 ![Proxy (idiomatic)](Proxy.png)

From 4658fd370fcaf0e8e872a9a59aea94a422167941 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 16:51:22 +0900
Subject: [PATCH 29/43] Update README.md

---
 GoF/idiomatic/Structural/Bridge/README.md | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Structural/Bridge/README.md b/GoF/idiomatic/Structural/Bridge/README.md
index 30bf222..d8f75f8 100644
--- a/GoF/idiomatic/Structural/Bridge/README.md
+++ b/GoF/idiomatic/Structural/Bridge/README.md
@@ -2,19 +2,31 @@
 
 I do not know what to eat for dinner. In my kitchen, I think I have pasta and rice with some sauces, especially pesto and carbonara.
 
+저녁으로 무엇을 먹을지 모르겠어요. 제 부엌에는 파스타와 밥, 특히 페스토와 카르보나라 소스가 있을 것 같습니다.
+
 # Problem
 
 Even in this very simple situation, they are already four recipes that could be great. I can eat pasta with pesto, pasta with carbonara, risotto with pesto, or risotto with carbonara.
 
+이 매우 간단한 상황에서도 좋은 네 가지 레시피가 이미 있습니다. 페스토 파스타, 카르보나라 파스타, 페스토 리조또, 또는 카르보나라 리조또를 먹을 수 있겠네요.
+
 To represent that with code, we might be tempted to create an object (literal) for each possible recipe (pastaWithPesto, pastaWithCarbonara, risottoWithPesto, risottoWithCarbonara). But imagine that, a couple of minutes later, you also find potatoes and a tomato sauce in the kitcken. Do you really want to create new objects such as potatoesWithCarbonara, pastaWithTomato and so on?
 
+이를 코드로 나타내기 위해 가능한 각 레시피에 대한 객체(리터럴)를 만들어야 할지도 모릅니다(pastaWithPesto, pastaWithCarbonara, risottoWithPesto, risottoWithCarbonara). 그러나 몇 분 후에 부엌에서 감자와 토마토 소스도 발견한다고 상상해 보세요. 정말로 감자카르보나라, 토마토소스 파스타 등과 같은 새로운 객체를 계속해서 만들고 싶을까요?
+
 # Solution
 
 The best solution is to use a "Bridge" between a simple recipe and a sauce. This means that we will be able to select the sauce independently. To do so, we may have:
 
-  * Factory methods to create different kinds of recipes with given sauces (a sauce is a parameter) 
-  * Object (literals) to describe available sauces
+최선의 해결책은 간단한 레시피와 소스 사이에 "브릿지"를 사용하는 것입니다. 이는 우리가 소스를 독립적으로 선택할 수 있게 해줍니다. 이를 위해 우리는 다음과 같은 방법을 사용할 수 있습니다:
+
+  * Factory methods to create different kinds of recipes with given sauces (a sauce is a parameter)  
+    주어진 소스와 함께 다양한 종류의 레시피를 생성하기 위한 팩토리 메서드들  
+  * Object (literals) to describe available sauces  
+    사용 가능한 소스를 설명하는 객체(리터럴)
 
 In the client code, the instance of sauce passed to the recipe function will give us the final meal.
 
+클라이언트 코드에서 레시피 함수에 전달된 소스 인스턴스는 최종 음식을 결정할 것입니다.
+
 ![Bridge (idiomatic)](Bridge.png)

From e461e6c48be59f23508663d91e5b03a178ce5c65 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 17:10:52 +0900
Subject: [PATCH 30/43] Update README.md

---
 GoF/idiomatic/Structural/Composite/README.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/GoF/idiomatic/Structural/Composite/README.md b/GoF/idiomatic/Structural/Composite/README.md
index aa07f4d..28a9913 100644
--- a/GoF/idiomatic/Structural/Composite/README.md
+++ b/GoF/idiomatic/Structural/Composite/README.md
@@ -2,14 +2,22 @@
 
 My little brother's room is generally a big mess, but recently my mother bought him some funny toy boxes of different sizes (like a 3D puzzle) so he can put his toys in it.
 
+내 작은 동생의 방은 일반적으로 큰 난장이인데, 최근에 어머니가 그에게 재미있는 다양한 크기의 장난감 상자(3D 퍼즐처럼)를 샀어요. 그래서 그가 장난감을 넣을 수 있게 되었어요.
+
 # Problem
 
 Here a toy box is, to some extent, a toy in itself that can contain other toys. These toys can be simple ones like, for instance, balls. But they can be complex ones too, like smaller toy boxes which also may contain other balls and/or even smaller toy boxes, etc. This situation is not easy to describe through code...
 
+여기서 장난감 상자는 어느 정도로 스스로 장난감이며, 다른 장난감을 포함할 수 있는 것으로 생각됩니다. 이 장난감은 간단한 것으로는 공 등이 있을 수 있습니다. 그러나 더 복잡한 경우에는 더 작은 장난감 상자도 있을 수 있으며, 이 안에는 또 다른 공이나 심지어 더 작은 장난감 상자가 들어 있을 수도 있습니다. 이러한 상황을 코드로 설명하는 것은 쉽지 않습니다...
+
 # Solution
 
 A good idea is to consider a group of toys like a simple toy. So a toy box full of toys is just a toy after all!
 
+한 가지 좋은 아이디어는 장난감들의 그룹을 하나의 단순한 장난감으로 간주하는 것입니다. 따라서 장난감들로 가득 찬 장난감 상자는 결국에는 그냥 하나의 장난감이 됩니다!
+
 The Composite design pattern is useful in this kind of situation. To implement this one, we only need two factory functions. The first one will be responsible for the creation of simple toys (balls), whereas the second one will be responsible for the creation of composite toys (toy boxes). In the object returned by the more complex factory function, we should have at least a collection of toys (an array is fine) and a method that makes it possible to iterate through it. But since the collection can also contain another toy box (that contain itself a collection of toys), this method must be able to iterate deeper.
 
+복합 디자인 패턴은 이러한 종류의 상황에서 유용합니다. 이를 구현하기 위해서는 두 개의 팩토리 함수만 필요합니다. 첫 번째 함수는 간단한 장난감(공)을 생성하는 역할을 담당하고, 두 번째 함수는 복합 장난감(장난감 상자)을 생성하는 역할을 담당합니다. 더 복잡한 팩토리 함수가 반환하는 객체에는 최소한 장난감의 모음(배열로 구현 가능)과 이를 반복할 수 있는 메서드가 있어야 합니다. 그러나 이 모음에는 다른 장난감 상자(그 자체에 장난감의 모음을 포함하는)가 포함될 수도 있으므로 이 메서드는 더 깊은 곳까지 반복할 수 있어야 합니다.
+
 ![Composite (idiomatic)](Composite.png)

From a91e51f57bd6caae05c9c0177740d30cd7e05380 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 17:25:38 +0900
Subject: [PATCH 31/43] Update toys.js

---
 GoF/idiomatic/Structural/Composite/ECMAScript/ES5/API/toys.js | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/API/toys.js b/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/API/toys.js
index 55d2a77..7b24e86 100644
--- a/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/API/toys.js
+++ b/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/API/toys.js
@@ -5,6 +5,7 @@
 // ==============================
 
 // A ball does not contain anything
+// 공은 아무 것도 포함하지 않습니다.
 var createBall = function () { 
     return {
         description: function () {
@@ -18,6 +19,7 @@ var createBall = function () {
 // ==============================
 
 // A toy box is a toy entity which contains toys, including smaller toy boxes
+// 장난감 상자는 장난감을 포함하는 장난감 엔티티이며, 그 안에는 더 작은 장난감 상자를 포함하여 장난감이 들어 있습니다.
 var createToyBox = function () {
     return {
         toys: [],

From 39945d0b91140cd7041bad38dec3a39cb563bd9c Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 17:26:08 +0900
Subject: [PATCH 32/43] Update client.js

---
 GoF/idiomatic/Structural/Composite/ECMAScript/ES5/client.js | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/client.js b/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/client.js
index 1b32174..8f48b1c 100644
--- a/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/client.js
+++ b/GoF/idiomatic/Structural/Composite/ECMAScript/ES5/client.js
@@ -7,6 +7,7 @@ var toys = require('./API/toys');
 // ==============================
 
 // Here we organize our toys in an optimal way
+// 여기서 우리는 장난감을 최적의 방식으로 조직합니다.
 var ball1 = toys.ball(),
     ball2 = toys.ball(),
     ball3 = toys.ball(),
@@ -19,4 +20,5 @@ bigToyBox.add(ball3);
 bigToyBox.add(smallToyBox);
 
 // Now we open our big toy box...
+// 이제 우리는 큰 장난감 상자를 엽니다...
 console.log(bigToyBox.inventory());

From 0d0d72f5609b44a9676fbf2314fc5c3492bc6726 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Mon, 1 Apr 2024 17:51:52 +0900
Subject: [PATCH 33/43] Update README.md

---
 GoF/idiomatic/Structural/Decorator/README.md | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Structural/Decorator/README.md b/GoF/idiomatic/Structural/Decorator/README.md
index d0b0606..fe602e6 100644
--- a/GoF/idiomatic/Structural/Decorator/README.md
+++ b/GoF/idiomatic/Structural/Decorator/README.md
@@ -2,18 +2,29 @@
 
 I am hungry and I want to eat pizza. I take my car and go to the nearest pizzeria. After a couple of minutes looking at the menu, I do not find what I want. So I finally ask for a custom pizza that will be prepared on the fly. I am not quite sure of the ingredients I want, but let's try to make a tasty pizza!
 
+저는 배가 고파서 피자를 먹고 싶습니다. 차를 타고 가장 가까운 피자 가게로 갑니다. 메뉴를 몇 분 동안 살펴보지만 원하는 것을 찾을 수 없습니다. 그래서 마침내 내가 원하는 대로 커스텀 피자를 주문합니다. 원하는 재료가 정확하게 뭔지는 확신하지 않지만 맛있는 피자를 만들어 보겠습니다!
+
 # Problem
 
 A custom pizza could be anything. Ingredients will be added one by one to produce something unique, depending on my choices.
 Here a pizza is an object that is built at runtime, which means that we cannot have an exhaustive constructor with all possible ingredients as parameters. 
 
+커스텀 피자는 어떤 것이든 될 수 있습니다. 재료는 내 선택에 따라 하나씩 추가되어 유일한 것을 만듭니다.
+여기서 피자는 런타임에 구축되는 객체입니다. 즉, 모든 가능한 재료를 매개변수로 가진 다양한 생성자를 가질 수 없습니다.
+
 # Solution
 
 The idea is to "augment" a basic product (such as a Margherita) with some extras (bacon, peppers, ...) using the Decorator design pattern. To make this working, we need:
 
-  * An object literal to represent a basic pizza (Margherita)
-  * Two factory functions that take a (basic or already decorated) pizza as parameter and return a new decorated pizza (with bacon or peppers)
+아이디어는 Margherita와 같은 기본 제품에 일부 추가 항목 (베이컨, 피망 등)을 추가하여 Decorator 디자인 패턴을 사용하여 제품을 "확장"하는 것입니다. 이를 작동시키려면 다음이 필요합니다:
+
+  * An object literal to represent a basic pizza (Margherita)  
+    기본 피자 (Margherita)를 나타내는 객체 리터럴
+  * Two factory functions that take a (basic or already decorated) pizza as parameter and return a new decorated pizza (with bacon or peppers)  
+    기본 피자 또는 이미 장식된 피자를 매개변수로 사용하고 베이컨이나 피망과 같은 새로운 장식된 피자를 반환하는 두 개의 팩토리 함수
 
 ![Decorator (idiomatic)](Decorator.png)
 
 N.B. In JavaScript, there are many ways to add new functionalities to an object. This implementation of the Decorator pattern is only one solution among an infinity of possibilities. Moreover, this pattern should not be confused with function decorators which are a bit different and serve another purpose.
+
+참고: JavaScript에서 객체에 새로운 기능을 추가하는 방법은 많습니다. 이 Decorator 패턴의 구현은 무한한 가능성 중 하나에 불과합니다. 또한 이 패턴은 조금 다르며 다른 목적을 위해 사용되는 함수 데코레이터와 혼동되어서는 안 됩니다.

From c2a528b5a07c202a9d5cd28d476b1297916466dd Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 11:17:11 +0900
Subject: [PATCH 34/43] Update README.md

---
 GoF/idiomatic/Structural/Facade/README.md | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Structural/Facade/README.md b/GoF/idiomatic/Structural/Facade/README.md
index 742e122..06ed16d 100644
--- a/GoF/idiomatic/Structural/Facade/README.md
+++ b/GoF/idiomatic/Structural/Facade/README.md
@@ -2,17 +2,27 @@
 
 I love my pets but, due to Alzheimer's disease, I often forget how to feed them. Any help would be appreciated. 
 
+내 애완동물을 사랑하지만, 알츠하이머병으로 인해 종종 어떻게 먹이를 주어야 하는지 잊어버립니다. 도와주시면 감사하겠습니다.
+
 # Problem
 
 The more pets you have, the more difficult it will be to remember the menu for each animal. Complexity can grow quite fast, which is not ideal in terms of code (re)usability. We should keep it simple, stupid (KISS).
 
+애완동물이 많을수록 각 동물마다의 메뉴를 기억하는 것이 더 어려워집니다. 복잡성은 매우 빠르게 증가할 수 있으며, 이는 코드의 (재)사용성 측면에서 이상적이지 않습니다. 우리는 간단하게 유지해야 합니다.
+
 # Solution
 
 Facade is often used to hide the underlying complexity of a system. To implement this design pattern, we can:
 
-  * Create an object (literal) to represent each animal
-  * Create a facade that has a reference to each animal
+파사드는 종종 시스템의 근본적인 복잡성을 숨기는 데 사용됩니다. 이 디자인 패턴을 구현하기 위해 우리는 다음을 할 수 있습니다:
+
+  * Create an object (literal) to represent each animal  
+    각 동물을 나타내는 객체(리터럴)를 생성하세요.
+  * Create a facade that has a reference to each animal  
+    각 동물에 대한 참조를 가진 파사드를 생성하세요.  
 
 Here the client will use the facade only, especially the main method that returns the favorite meal of each animal. No additional effort is required.
 
+여기서 클라이언트는 주로 파사드를 사용할 것입니다, 특히 각 동물의 즐겨먹는 식사를 반환하는 주요 메서드를 사용할 것입니다. 추가적인 노력은 필요하지 않습니다.
+
 ![Facade (idiomatic)](Facade.png)

From 4d2d27b66d729f6a84bc261cbc06b24f492cf2eb Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 11:54:21 +0900
Subject: [PATCH 35/43] Update README.md

---
 GoF/idiomatic/Structural/Flyweight/README.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/GoF/idiomatic/Structural/Flyweight/README.md b/GoF/idiomatic/Structural/Flyweight/README.md
index faf8523..3d4a3e9 100644
--- a/GoF/idiomatic/Structural/Flyweight/README.md
+++ b/GoF/idiomatic/Structural/Flyweight/README.md
@@ -2,10 +2,14 @@
 
 I am a fan of GNU/Linux distributions and I want to test the big names: Debian, RedHat, Slackware. However, I am too busy to test all versions available. The latest version of each distro would be just fine.
 
+저는 GNU/Linux 배포판의 팬이며 Debian, RedHat, Slackware와 같은 대표적인 배포판을 테스트하고 싶습니다. 그러나 모든 가능한 버전을 테스트하기에는 너무 바쁩니다. 각 배포판의 최신 버전만 테스트해도 충분할 것입니다.
+
 # Problem
 
 Everytime we use an object literal, we create a new object in JavaScript. But if we know the instance we need will always be the same (e.g. a very specific version of Debian), this is not optimal to create multiple instances that represent the same thing. Each instantiation operation has a cost in terms of performance and memory which should be minimized as much as possible.
 
+JavaScript에서 객체 리터럴을 사용할 때마다 새로운 객체가 생성됩니다. 그러나 특정 인스턴스가 항상 동일할 것으로 알고 있는 경우(예: 매우 특정한 버전의 Debian), 동일한 것을 나타내는 여러 인스턴스를 생성하는 것은 최적이 아닙니다. 각 인스턴스화 작업은 성능 및 메모리 측면에서 비용이 발생하므로 가능한 한 최소화해야 합니다.
+
 # Solution
 
 We can use Flyweight here, which is actually tied to Factory. A Factory handles flyweights when it reuses instances instead of constantly creating new ones. To do so, we generally use a Map or an object without prototype in the factory function. The first instance of a specific type created by the factory is always saved in this data structure and then reused in all subsequent calls.

From 1f1a435dc82fb476e9ac7ca43c4b1e5c430b9eae Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 13:07:31 +0900
Subject: [PATCH 36/43] Update README.md

---
 GoF/idiomatic/Structural/Flyweight/README.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/GoF/idiomatic/Structural/Flyweight/README.md b/GoF/idiomatic/Structural/Flyweight/README.md
index 3d4a3e9..96647ce 100644
--- a/GoF/idiomatic/Structural/Flyweight/README.md
+++ b/GoF/idiomatic/Structural/Flyweight/README.md
@@ -14,4 +14,6 @@ JavaScript에서 객체 리터럴을 사용할 때마다 새로운 객체가 생
 
 We can use Flyweight here, which is actually tied to Factory. A Factory handles flyweights when it reuses instances instead of constantly creating new ones. To do so, we generally use a Map or an object without prototype in the factory function. The first instance of a specific type created by the factory is always saved in this data structure and then reused in all subsequent calls.
 
+여기서는 Flyweight를 사용할 수 있습니다. 실제로 Flyweight는 Factory와 관련이 있습니다. Factory는 새로운 인스턴스를 계속 생성하는 대신에 인스턴스를 재사용할 때 Flyweight를 처리합니다. 이를 위해 일반적으로 Factory 함수 내에서 Map이나 프로토타입이 없는 객체를 사용합니다. Factory에 의해 생성된 특정 유형의 첫 번째 인스턴스는 항상 이러한 데이터 구조에 저장되고, 그 후의 모든 호출에서 재사용됩니다.
+
 ![Flyweight (idiomatic)](Flyweight.png)

From 271b9043ca898cf1cf4313f20adcddbca3161ffa Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 13:26:14 +0900
Subject: [PATCH 37/43] Update client.js

---
 GoF/idiomatic/Structural/Flyweight/ECMAScript/ES5/client.js | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/GoF/idiomatic/Structural/Flyweight/ECMAScript/ES5/client.js b/GoF/idiomatic/Structural/Flyweight/ECMAScript/ES5/client.js
index 40cc808..5500faf 100644
--- a/GoF/idiomatic/Structural/Flyweight/ECMAScript/ES5/client.js
+++ b/GoF/idiomatic/Structural/Flyweight/ECMAScript/ES5/client.js
@@ -7,9 +7,10 @@ var getLinuxDistro = require('./API/flyweight');
 // ==============================
 
 // Creation of our objects through the factory
+// 팩토리를 통한 객체 생성
 var debian = getLinuxDistro("DEBIAN"),
     debianAgain = getLinuxDistro("debian");
 
 console.log(debian.boot()); // Debian is booting...
 console.log(debianAgain.boot()); // Debian is booting...
-console.log(debian === debianAgain); // true (the same object has been reused)
+console.log(debian === debianAgain); // true (the same object has been reused; 동일한 객체가 재사용되었습니다.)

From ee563327b25306687294bf9c7d4e930eeab04902 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 13:38:10 +0900
Subject: [PATCH 38/43] Update README.md

---
 GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md b/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md
index 714a475..6548117 100644
--- a/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md
+++ b/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md
@@ -2,12 +2,18 @@
 
 Imagine a long relay race with athletes from different sports. This race could involve several teams composed each time of a racewalker, a runner and a swimmer.
 
+다양한 종목의 선수들이 참여하는 긴 릴레이 경기를 상상해보세요. 이 경기는 매번 걷기 선수, 달리기 선수 및 수영 선수로 구성된 여러 팀들이 참여할 수 있습니다.
+
 # Problem
 
 Each sport has its own rules and each athlete will participate differently. So we cannot just evaluate the role of each athlete in the same way, even though the objective is the same for everyone within a team: the gold medal. A swimmer and a runner are both athletes, but a swimmer swims whereas a runner runs... Here we could say that each team member handles a part of the initial request which is to win the race.
 
+각 스포츠에는 각자의 규칙이 있고 각 선수는 서로 다르게 참여합니다. 따라서 우리는 모든 선수의 역할을 동일하게 평가할 수는 없습니다. 비록 팀 내의 모든 선수의 목표는 동일한 금메달을 획득하는 것이지만 각 선수가 참여하는 방식은 다릅니다. 수영 선수와 달리기 선수 모두 운동 선수지만, 수영 선수는 수영을 하고 달리기 선수는 달립니다. 여기서 각 팀원은 경기에서 승리하는 것이라는 초기 요청의 일부를 처리합니다.
+
 Moreover, this is a relay race, not an individual one. Each athlete must know the next relay where another athlete will wait for the baton before to start.
 
+게다가, 이는 개인 경기가 아닌 릴레이 경기입니다. 각 선수는 다음 릴레이를 알고 다른 선수가 주머니를 전달할 때 시작해야 합니다.
+
 # Solution
 
 Everytime a request should be handled by multiple (and complementary) processing units, the Chain of Responsibility pattern seems ideal. In this case, we can represent each athlete with a simple object literal. We will have:

From 309892ae15218a0420618a48f58a9c68bfecb30a Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 13:42:00 +0900
Subject: [PATCH 39/43] Update README.md

---
 .../Behavioral/ChainOfResponsibility/README.md         | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md b/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md
index 6548117..4d56884 100644
--- a/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md
+++ b/GoF/idiomatic/Behavioral/ChainOfResponsibility/README.md
@@ -18,12 +18,20 @@ Moreover, this is a relay race, not an individual one. Each athlete must know th
 
 Everytime a request should be handled by multiple (and complementary) processing units, the Chain of Responsibility pattern seems ideal. In this case, we can represent each athlete with a simple object literal. We will have:
 
+각 요청이 여러 개의 보조 처리 단위에서 처리되어야 할 때마다, 책임 연쇄 패턴이 이상적으로 보입니다. 이 경우, 각 선수를 간단한 객체 리터럴로 표현할 수 있습니다. 우리는 다음과 같은 구성을 가질 것입니다:
+
   * An object literal representing a walker
+    보행자를 나타내는 객체 리터럴
   * An object literal representing a runner
+    달리기 선수를 나타내는 객체 리터럴
   * An object literal representing a swimmer
+    수영 선수를 나타내는 객체 리터럴
 
 Each of these objects should have at least their own method ("go") whose action will be specific to the associated sport. But each of these particular "go" methods will also transfer some work to the next relay, chosen by the client code.
 
+이러한 각 객체는 적어도 자체 메서드("go")를 가져야 합니다. 이 메서드의 동작은 해당 스포츠와 관련이 있습니다. 그러나 이러한 특정 "go" 메서드 각각은 또한 클라이언트 코드에서 선택한 다음 릴레이에 일부 작업을 전달해야 합니다.
+
 ![Chain of Responsibility (idiomatic)](ChainOfResponsibility.png)
 
-N.B. This design pattern should not be confused with simple method chaining in JavaScript.
+N.B. This design pattern should not be confused with simple method chaining in JavaScript.  
+참고: 이 디자인 패턴은 JavaScript에서의 단순한 메서드 체이닝과 혼동되어서는 안 됩니다.

From be27a41a1177efbc80e6970e021d57dc4b3e80af Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 13:58:22 +0900
Subject: [PATCH 40/43] Update README.md

---
 GoF/idiomatic/Behavioral/Observer/README.md | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Behavioral/Observer/README.md b/GoF/idiomatic/Behavioral/Observer/README.md
index dca81ff..a52d49c 100644
--- a/GoF/idiomatic/Behavioral/Observer/README.md
+++ b/GoF/idiomatic/Behavioral/Observer/README.md
@@ -2,19 +2,31 @@
 
 In the savanna, there are predators like lions or crocodiles and there are preys like gazelles. So lions and crocodiles often attack gazelles.
 
+사바나에는 사자나 악어와 같은 포식자가 있고, 가젤과 같은 피식자가 있습니다. 그래서 사자와 악어는 종종 가젤을 공격합니다.
+
 # Problem
 
 Lions and crocodiles do not attack at any moment. A lion will generally attack if a gazelle is a bit too far from the herd. A crocodile will generally attack if a gazelle is a bit too close to water, especially for drinking.
 
+사자와 악어는 언제든지 공격하지 않습니다. 일반적으로 사자는 가젤이 무리에서 조금 멀리 떨어져 있을 때 공격합니다. 악어는 일반적으로 가젤이 물에 너무 가까이 있을 때, 특히 마실 때 공격합니다.
+
 In programming terms, predators execute some action when a specific event occurs on the preys side. This implies the implementation of an event-handling mechanism in the code, which may be unclear if it is not properly done.
 
+프로그래밍 용어로 이야기하면, 포식자는 피식자 측에서 특정 이벤트가 발생할 때 어떤 동작을 실행합니다. 이는 코드에서 이벤트 처리 메커니즘을 구현하는 것을 의미하며, 제대로 구현되지 않으면 코드가 명확하지 않을 수 있습니다.
+
 # Solution
 
 The Observer design pattern helps a lot when we have to implement an event-driven system like this. Here this pattern is composed of:
 
-  * Object literals to represent different kinds of observers
-  * An object literal to represent the observable entity 
+옵서버 디자인 패턴은 이와 같은 이벤트 기반 시스템을 구현할 때 많은 도움이 됩니다. 여기서 이 패턴은 다음과 같이 구성됩니다:
+
+  * Object literals to represent different kinds of observers  
+    다양한 종류의 관찰자를 나타내기 위한 객체 리터럴
+  * An object literal to represent the observable entity  
+    관찰 가능한 엔티티를 나타내기 위한 객체 리터럴
 
 The observable object (gazelle) maintains a list (array) of predators. Then, depending on its actions (determined by the client code), its "notifyPredators" method may be called. This method would iterate through the array of predators and make them attack.
 
+관찰 가능한 객체(가젤)는 포식자들의 목록(배열)을 유지합니다. 그런 다음, 클라이언트 코드에서 결정한 행동에 따라 "notifyPredators" 메서드가 호출될 수 있습니다. 이 메서드는 포식자들의 배열을 반복하고 그들을 공격하도록 할 것입니다.
+
 ![Observer (idiomatic)](Observer.png)

From fa9f64117c2618f740f42104dd1fa70f8011b355 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 14:52:58 +0900
Subject: [PATCH 41/43] Update README.md

---
 GoF/idiomatic/Behavioral/Command/README.md | 21 +++++++++++++++++++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/GoF/idiomatic/Behavioral/Command/README.md b/GoF/idiomatic/Behavioral/Command/README.md
index cc5b7af..f7931fc 100644
--- a/GoF/idiomatic/Behavioral/Command/README.md
+++ b/GoF/idiomatic/Behavioral/Command/README.md
@@ -2,24 +2,41 @@
 
 I am hungry and I decide to call the nearest Tex-Mex restaurant to place an order. I hope I will receive my meal fast.
 
+저는 배고파서 가장 가까운 텍스멕스 레스토랑에 전화하여 주문을 할 것으로 결정했습니다. 제가 식사를 빨리 받길 바랍니다.
+
 # Problem
 
 Placing an order is easy to do. As a customer, you only need to say what you want to eat and nothing else. However, for the restaurant, there is a true organization behind the scenes to effectively treat your order. The chef cooks for you, then the meal is packaged and finally the delivery man brings it to you as fast as possible. Plus, you are not the only one to be hungry... The restaurant is most likely in a situation where it has to handle many orders, especially when it is time for dinner.
 
+주문하는 것은 쉽습니다. 고객으로서, 당신은 먹고 싶은 것만 말하면 됩니다. 그러나 레스토랑 측에서는 효과적으로 주문을 처리하기 위한 진정한 조직이 뒤에서 이루어집니다. 요리사가 요리를 준비하고, 식사가 포장되며, 마지막으로 배달원이 최대한 빨리 가져다 줍니다. 게다가, 당신이 배고픈 유일한 사람은 아닙니다... 특히 저녁 시간이 되면 레스토랑은 많은 주문을 처리해야 할 상황일 가능성이 높습니다.
+
 In computer science terms, it seems obvious that the restaurant has to handle a queue of orders and that each customer is a unique entity. Since a customer normally pays his order to the delivery man, the payment should be the last step of the process. But this is not so intuitive if you try to find a good code organization for this. On the one hand, all orders are handled by the restaurant and everything required to prepare these orders is like encapsulated in each order. On the other hand, only customers can validate orders since their responsible for payment.
 
+컴퓨터 과학적 용어로 이야기하면, 레스토랑은 주문 대기열을 처리해야 하며 각 고객은 고유한 개체입니다. 일반적으로 고객은 주문을 배달원에게 지불하므로 결제는 프로세스의 마지막 단계여야 합니다. 그러나 이를 위한 좋은 코드 조직을 찾으려고 할 때 이것은 그리 직관적이지 않습니다. 한편으로는 모든 주문이 레스토랑에서 처리되고 각 주문에는 준비에 필요한 모든 것이 캡슐화되어 있는 것처럼 보입니다. 다른 한편으로는 고객만 주문을 승인할 수 있으며 이는 결제에 책임이 있기 때문입니다.
+
 # Solution
 
 The Command pattern is a great help here. In this pattern terminology, we will say that:
+
+여기서 커맨드 패턴은 큰 도움이 됩니다. 이 패턴 용어에서는 다음과 같이 말할 수 있습니다:
  
-  * The restaurant is the "invoker" who creates and handles new orders internally.
+  * The restaurant is the "invoker" who creates and handles new orders internally.  
+    레스토랑은 내부적으로 새로운 주문을 생성하고 처리하는 "invoker"입니다.
   * The order is the "command", in other words the request which comes from a client.
+    주문은 "command"로서, 즉 고객으로부터 온 요청입니다.
   * The customer is the "receiver" of the order.
+    고객은 주문의 "receiver"입니다.
 
 To implement this pattern, we then need three object literals to represent each entity:
+
+이 패턴을 구현하기 위해, 각 엔티티를 나타내는 세 개의 객체 리터럴이 필요합니다:
   
   * The customer has only one method ("pay").
-  * The order has a reference to a given customer and makes him pay using its "deliver" method.
+    고객은 "pay" 메서드만을 가지고 있습니다.
+  * The order has a reference to a given customer and makes him pay using its "deliver" method. 
+    주문은 특정 고객에 대한 참조를 가지고 있으며 "deliver" 메서드를 사용하여 고객에게 지불하게 합니다.
   * The restaurant is a more complex object with a collection (array) of orders and an essential method ("prepareOrders") that start the delivery of each order.
+    레스토랑은 주문의 컬렉션(배열)과 각 주문의 배송을 시작하는 필수 메서드("prepareOrders")를 가진 보다 복잡한 객체입니다.
+
 
 ![Command (idiomatic)](Command.png)

From c27c6f920122456eb80be84ea2b6a1b56687d282 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 14:53:30 +0900
Subject: [PATCH 42/43] Update README.md

---
 GoF/idiomatic/Behavioral/Command/README.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/GoF/idiomatic/Behavioral/Command/README.md b/GoF/idiomatic/Behavioral/Command/README.md
index f7931fc..5b2d53f 100644
--- a/GoF/idiomatic/Behavioral/Command/README.md
+++ b/GoF/idiomatic/Behavioral/Command/README.md
@@ -20,11 +20,11 @@ The Command pattern is a great help here. In this pattern terminology, we will s
 
 여기서 커맨드 패턴은 큰 도움이 됩니다. 이 패턴 용어에서는 다음과 같이 말할 수 있습니다:
  
-  * The restaurant is the "invoker" who creates and handles new orders internally.  
+  * The restaurant is the "invoker" who creates and handles new orders internally.    
     레스토랑은 내부적으로 새로운 주문을 생성하고 처리하는 "invoker"입니다.
-  * The order is the "command", in other words the request which comes from a client.
+  * The order is the "command", in other words the request which comes from a client.  
     주문은 "command"로서, 즉 고객으로부터 온 요청입니다.
-  * The customer is the "receiver" of the order.
+  * The customer is the "receiver" of the order.  
     고객은 주문의 "receiver"입니다.
 
 To implement this pattern, we then need three object literals to represent each entity:

From 020623b7fc92f307d4a2002bc2d4bc2bba0547a5 Mon Sep 17 00:00:00 2001
From: Inho Park <98461850+qamoo@users.noreply.github.com>
Date: Tue, 2 Apr 2024 14:55:08 +0900
Subject: [PATCH 43/43] Update README.md

---
 GoF/idiomatic/Behavioral/Command/README.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/GoF/idiomatic/Behavioral/Command/README.md b/GoF/idiomatic/Behavioral/Command/README.md
index 5b2d53f..464065c 100644
--- a/GoF/idiomatic/Behavioral/Command/README.md
+++ b/GoF/idiomatic/Behavioral/Command/README.md
@@ -35,7 +35,7 @@ To implement this pattern, we then need three object literals to represent each
     고객은 "pay" 메서드만을 가지고 있습니다.
   * The order has a reference to a given customer and makes him pay using its "deliver" method. 
     주문은 특정 고객에 대한 참조를 가지고 있으며 "deliver" 메서드를 사용하여 고객에게 지불하게 합니다.
-  * The restaurant is a more complex object with a collection (array) of orders and an essential method ("prepareOrders") that start the delivery of each order.
+  * The restaurant is a more complex object with a collection (array) of orders and an essential method ("prepareOrders") that start the delivery of each order.  
     레스토랑은 주문의 컬렉션(배열)과 각 주문의 배송을 시작하는 필수 메서드("prepareOrders")를 가진 보다 복잡한 객체입니다.