이제 AI 시대가 도래했습니다. 지금은 const fetch = require('node-fetch') ? (현재 ChatGPT와 Gemini 모두에 해당) 인터넷과 그 콘텐츠인 순환 기계의 또 다른 회전을 제공합니다.
콘텐츠의 융합 속에서 디자인 패턴이 다시 등장하고 있습니다
Node(???)에서 디자인 패턴을 적용하는 방법을 설명하는 게시물부터 Java(2014년 3월에 출시된 Java 8에서 람다 추가)에서 팩토리 패턴을 적용하는 방법과 같은 구식 내용을 자세히 설명하는 게시물까지 ).
리팩토링 전문가를 우연히 만난 적이 있나요?
컴퓨터 과학, 특히 프로그래밍을 배우는 여정에서 아마도 방문했을 웹사이트일 것입니다. 디자인 패턴 섹션은 매우 잘 설명되어 있으며 수년 동안 다양한 포럼을 통해 가장 많이 공유된 섹션 중 하나입니다.
디자인 패턴의 정의를 살펴보면 다음과 같습니다.
디자인 패턴은 일반적인 문제에 대한 일반적인 솔루션입니다
소프트웨어 디자인에서. 각 패턴은 청사진과 같습니다
특정 문제를 해결하기 위해 사용자 정의할 수 있습니다
코드에 디자인 문제가 있습니다.
그렇다면 왜 이 게시물을 작성하는 걸까요? 즉, 위에 링크된 웹사이트에는 많은 정보가 있습니다. 이게 전부일 수도 있어요.
문제는 저는 항상 이 정의를 받아들이는 데 어려움을 겪었습니다... "내 코드에서 특정 디자인 문제를 해결하기 위해"... 내 코드에서? 내 코드에 해결해야 할 문제가 있나요?
실제로는 프로젝트에 사용된 프로그래밍 언어에 추상화가 부족한특정 "무언가"를 코딩해야 하는 경우가 발생합니다.
간단하고 간단합니다. 아직 마음에 들지 않는 경우를 대비해 코드를 포함한 몇 가지 예를 살펴보겠습니다.
이것은 Java(주로 객체 지향 프로그래밍 언어)에서 팩토리 패턴을 매우 간단하게 구현한 것입니다.
public class ShapeFactory {
public Shape createShape(String type) {
if (type.equalsIgnoreCase("CIRCLE")) {
return new Circle();
} else if (type.equalsIgnoreCase("SQUARE")) {
return new Square();
}
return null;
}
}
그런 다음 Java 8 (2014년 3월, 잊어버린 경우를 대비해)에는 Lambdas(함수형 프로그래밍의 개념)가 추가되어 대신 이 작업을 수행할 수 있습니다.
Map<String, Supplier<Shape>> shapeFactory = new HashMap<>();
shapeFactory.put("CIRCLE", Circle::new);
shapeFactory.put("SQUARE", Square::new);
Shape circle = shapeFactory.get("CIRCLE").get();
다시는 공장 설계 패턴이 필요하지 않습니다(적어도 Java에서는).
예, 공장 패턴이 대부분의 사람들이 항상 사용하는 예라는 것을 알고 있습니다. 하지만 다른 패턴은 어떻게 되나요? 그러면 다른 프로그래밍 언어에서는 어떻게 되나요?
Typescript의 방문자 패턴은 다음과 같습니다.
interface Shape {
draw(): void;
accept(visitor: ShapeVisitor): void;
}
class Circle implements Shape {
radius: number;
constructor(radius: number) {
this.radius = radius;
}
draw() {
console.log("Drawing a circle");
}
accept(visitor: ShapeVisitor) {
visitor.visitCircle(this);
}
}
class Square implements Shape {
sideLength: number;
constructor(sideLength: number) {
this.sideLength = sideLength;
}
draw() {
console.log("Drawing a square");
}
accept(visitor: ShapeVisitor) {
visitor.visitSquare(this);
}
}
interface ShapeVisitor {
visitCircle(circle: Circle): void;
visitSquare(square: Square): void;
}
class AreaCalculator implements ShapeVisitor {
private area = 0;
visitCircle(circle: Circle) {
this.area = Math.PI * circle.radius * circle.radius;
console.log(`Circle area: ${this.area}`);
}
visitSquare(square: Square) {
this.area = square.sideLength * square.sideLength;
console.log(`Square area: ${this.area}`);
}
getArea(): number {
return this.area;
}
}
// Using the Visitor
const circle = new Circle(5);
const square = new Square(4);
const calculator = new AreaCalculator();
circle.accept(calculator);
square.accept(calculator);
다음 코드는 방문자 패턴 대신 리플렉션(런타임에 자체 객체를 검사하고 조작하는 언어의 기능)을 사용한다는 점만 제외하면 완전히 동일한 작업을 수행합니다.
interface Shape {
draw(): void;
}
class Circle implements Shape {
// ... (same as before)
radius: number;
}
class Square implements Shape {
// ... (same as before)
sideLength: number;
}
function calculateArea(shape: Shape) {
if (shape instanceof Circle) {
const circle = shape as Circle; // Type assertion
const area = Math.PI * circle.radius * circle.radius;
console.log(`Circle area: ${area}`);
} else if (shape instanceof Square) {
const square = shape as Square; // Type assertion
const area = square.sideLength * square.sideLength;
console.log(`Square area: ${area}`);
}
}
const circle = new Circle(5);
const square = new Square(4);
calculateArea(circle);
calculateArea(square);
이제 TypeScript에서도 관찰자 패턴을 사용할 수 있습니다.
interface Observer {
update(data: any): void;
}
class NewsPublisher {
private observers: Observer[] = [];
subscribe(observer: Observer) {
this.observers.push(observer);
}
unsubscribe(observer: Observer) {
this.observers = this.observers.filter(o => o !== observer);
}
notify(news:
string) {
this.observers.forEach(observer => observer.update(news));
}
}
class NewsletterSubscriber implements Observer {
update(news: string) {
console.log(`Received news: ${news}`);
}
}
// Using the Observer
const publisher = new NewsPublisher();
const subscriber1 = new NewsletterSubscriber();
const subscriber2 = new NewsletterSubscriber();
publisher.subscribe(subscriber1);
publisher.subscribe(subscriber2);
publisher.notify("New product launched!");
동일하지만 내장된(Node API에) EventEmitter를 사용합니다:
public class ShapeFactory {
public Shape createShape(String type) {
if (type.equalsIgnoreCase("CIRCLE")) {
return new Circle();
} else if (type.equalsIgnoreCase("SQUARE")) {
return new Square();
}
return null;
}
}
그 시점에서 "문제"가 OOP 구현이라는 것을 깨달았을 수도 있으며, 당신의 말이 완전히 옳기는 하지만 완전히는 아닙니다.
모든 프로그래밍 패러다임은 특히 가장 순수한 형태로 받아들여지면 고유한 특징, 어려움 또는 "직선으로는 달성할 수 없는 것"이 있습니다.
함수형 프로그래밍 영역으로 들어가 보겠습니다. 아마도 모나드(Monads)에 대해 들어보셨을 것입니다.
당신이 수학적 정의의 함정에 빠졌든 아니든, 우리 소프트웨어 개발자들은 모나드를 디자인 패턴으로도 이해할 수 있습니다. 예상치 못한 일이 일어나지 않는 순수 기능의 세계에서는 부작용을 상상하기 어려운데, 대부분의 소프트웨어 제품에는 부작용이 필요한데 어떻게 해야 할까요...?
이것은 하스켈의 IO 모나드의 예입니다:
Map<String, Supplier<Shape>> shapeFactory = new HashMap<>();
shapeFactory.put("CIRCLE", Circle::new);
shapeFactory.put("SQUARE", Square::new);
Shape circle = shapeFactory.get("CIRCLE").get();
부작용(파일 읽기)은 IO 모나드에 포함되어 있습니다.
typescript를 사용하여 모나딕 예제를 추가해 보겠습니다.
interface Shape {
draw(): void;
accept(visitor: ShapeVisitor): void;
}
class Circle implements Shape {
radius: number;
constructor(radius: number) {
this.radius = radius;
}
draw() {
console.log("Drawing a circle");
}
accept(visitor: ShapeVisitor) {
visitor.visitCircle(this);
}
}
class Square implements Shape {
sideLength: number;
constructor(sideLength: number) {
this.sideLength = sideLength;
}
draw() {
console.log("Drawing a square");
}
accept(visitor: ShapeVisitor) {
visitor.visitSquare(this);
}
}
interface ShapeVisitor {
visitCircle(circle: Circle): void;
visitSquare(square: Square): void;
}
class AreaCalculator implements ShapeVisitor {
private area = 0;
visitCircle(circle: Circle) {
this.area = Math.PI * circle.radius * circle.radius;
console.log(`Circle area: ${this.area}`);
}
visitSquare(square: Square) {
this.area = square.sideLength * square.sideLength;
console.log(`Square area: ${this.area}`);
}
getArea(): number {
return this.area;
}
}
// Using the Visitor
const circle = new Circle(5);
const square = new Square(4);
const calculator = new AreaCalculator();
circle.accept(calculator);
square.accept(calculator);
고전적인 이야기로, 아마도 모나드는 인터넷에서 50번 정도 본 것 같은데, 그게 정말 뭔데요?
문제 해결하려는 문제:
interface Shape {
draw(): void;
}
class Circle implements Shape {
// ... (same as before)
radius: number;
}
class Square implements Shape {
// ... (same as before)
sideLength: number;
}
function calculateArea(shape: Shape) {
if (shape instanceof Circle) {
const circle = shape as Circle; // Type assertion
const area = Math.PI * circle.radius * circle.radius;
console.log(`Circle area: ${area}`);
} else if (shape instanceof Square) {
const square = shape as Square; // Type assertion
const area = square.sideLength * square.sideLength;
console.log(`Square area: ${area}`);
}
}
const circle = new Circle(5);
const square = new Square(4);
calculateArea(circle);
calculateArea(square);
객체의 속성을 정의하는 것을 잊었습니다! ?
실제 사용 사례에서는 주로 데이터베이스나 파일에서 읽는 것과 같은 부작용으로 인한 입력이 됩니다
이제 그렇게 하면:
interface Observer {
update(data: any): void;
}
class NewsPublisher {
private observers: Observer[] = [];
subscribe(observer: Observer) {
this.observers.push(observer);
}
unsubscribe(observer: Observer) {
this.observers = this.observers.filter(o => o !== observer);
}
notify(news:
string) {
this.observers.forEach(observer => observer.update(news));
}
}
class NewsletterSubscriber implements Observer {
update(news: string) {
console.log(`Received news: ${news}`);
}
}
// Using the Observer
const publisher = new NewsPublisher();
const subscriber1 = new NewsletterSubscriber();
const subscriber2 = new NewsletterSubscriber();
publisher.subscribe(subscriber1);
publisher.subscribe(subscriber2);
publisher.notify("New product launched!");
프로그램이 폭발합니다.
Maybe 모나드가 없는 솔루션:
import { EventEmitter } from 'events';
class NewsPublisher extends EventEmitter {
publish(news: string) {
this.emit('news', news);
}
}
const publisher = new NewsPublisher();
publisher.on('news', (news) => {
console.log(`All subscribers received the news: ${news}`);
});
publisher.publish("New product launched!");
프로그램이 터지지 않습니다.
maybe 모나드는 선택적 연결 연산자로 인해 JavaScript나 typescript에서는 필요하지 않지만 이를 구현하지 않는 언어를 사용하는 경우... 음, 어쩌면 모나드를 적용할 수 있습니다. 디자인 패턴이라고 할까요?
네 알아요. Maybe라는 개념을 막 배워서 그것을 6개의 사이드 프로젝트에 한꺼번에 열심히 적용한 사람들이 있는데, 지금은 파티에서 "필요하지 않다"고 말하면서 낄낄거리고 있습니다. 그래도 계속 사용할 수 있습니다. 사실 괜찮다고 느끼면 그렇게 하도록 초대합니다 (결국 원하는 것은 무엇이든 할 수 있는 예쁜 얼굴의 코드입니다! ?)
하지만 다시 기본으로 돌아가세요. 다른 패러다임은 어떻습니까? OOP/FP 상자 밖에서 생각하고 있다면 마음에 듭니다!
공식적으로 '디자인 패턴'이라고 부르지는 않더라도 모든 패러다임에는 확실히 고유한 반복 솔루션과 기술이 있습니다.
다음은 몇 가지 예입니다(생각하지 않게 해준 Gemini에게 감사하고, 예쁜 형식과 부가 가치를 알려주셔서 감사합니다 ?):
"기술"과 "패턴"이 많이 있습니다. 이 목록은 궁금하신 분들을 위해 참고할 내용을 제공하기 위한 것입니다.
이 내용이 도움이 되기를 바랍니다. 곧 읽어 보시기 바랍니다!
'디자인 패턴'이라는 용어는 OOP와 가장 밀접하게 연관되어 있지만 다른 패러다임에는 고유한 반복 솔루션 및 기술 세트가 있습니다. 이러한 기술은 해당 패러다임의 특정 과제와 제약을 해결하여 일반적인 문제에 대한 확립된 접근 방식을 제공합니다. 따라서 공식적으로 항상 "디자인 패턴"으로 표시되지는 않더라도 개발자를 효과적이고 유지 관리 가능한 솔루션으로 안내하는 비슷한 목적을 제공합니다.
디자인 패턴은 우리가 사용하는 프로그래밍 언어에 추상화가 부족한 기능을 패치하기 위한 잘 알려진 해결 방법으로 이해할 수 있습니다.
이 게시물은 거의 전적으로 제가 작성했으며, 예시는 Gemini 1.5 Pro를 사용하여 작성되었습니다
위 내용은 디자인 패턴 이해하기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
