Home > Article > Web Front-end > 5 TypeScript design patterns you need to know
This article introduces 5 TypeScript design patterns to you. It has certain reference value. Friends in need can refer to it. I hope it will be helpful to everyone.
Design patterns are templates that help developers solve problems. There are too many patterns covered in this book, and they often target different needs. However, they can be divided into three different groups:
Composite, Adapter, and Decorator. Observer Pattern. The singleton pattern is probably one of the most famous design patterns. It is a creation pattern because it ensures that no matter how many times we try to instantiate a class, we only have one instance available.
Handling database connections and the like can be done in singleton mode, because we want to process only one at a time without having to reconnect on each user request.
class MyDBConn {
protected static instance: MyDBConn | null = null
private id:number = 0
constructor() {
this.id = Math.random()
}
public getID():number {
return this.id
}
public static getInstance():MyDBConn {
if (!MyDBConn.instance) {
MyDBConn.instance = new MyDBConn()
}
return MyDBConn.instance
}
}
const connections = [
MyDBConn.getInstance(),
MyDBConn.getInstance(),
MyDBConn.getInstance(),
MyDBConn.getInstance(),
MyDBConn.getInstance()
]
connections.forEach( c => {
console.log(c.getID())
})
Now, although the class cannot be instantiated directly, using the getInstance method can ensure that there will not be multiple instances. In the example above, you can see how a pseudo-class that wraps a database connection benefits from this pattern.
This example shows that no matter how many times we call the getInstance method, the connection is always the same.
The above running results:
0.4047087250990713 0.4047087250990713 0.4047087250990713 0.4047087250990713 0.4047087250990713
##Factory mode is a creation mode, just like Single case mode Same. However, this pattern does not work directly on the object we care about, but only manages its creation.
vehicle class, but calling The code of their move methods can be generic.
creator class with 3 methods, or a method that takes parameters. In either case, extending that logic to support the creation of more vehices requires continually growing the same class.
TypeScript:
interface Vehicle {
move(): void
}
class Car implements Vehicle {
public move(): void {
console.log("Moving the car!")
}
}
class Bicycle implements Vehicle {
public move(): void {
console.log("Moving the bicycle!")
}
}
class Plane implements Vehicle {
public move(): void {
console.log("Flying the plane!")
}
}
// VehicleHandler 是“抽象的”，因为没有人会实例化它instantiate it
// 我们要扩展它并实现抽象方法
abstract class VehicleHandler {
// 这是真正的处理程序需要实现的方法
public abstract createVehicle(): Vehicle
public moveVehicle(): void {
const myVehicle = this.createVehicle()
myVehicle.move()
}
}
class PlaneHandler extends VehicleHandler{
public createVehicle(): Vehicle {
return new Plane()
}
}
class CarHandler extends VehicleHandler{
public createVehicle(): Vehicle {
return new Car()
}
}
class BicycleHandler extends VehicleHandler{
public createVehicle(): Vehicle {
return new Bicycle()
}
}
/// User code...
const planes = new PlaneHandler()
const cars = new CarHandler()
planes.moveVehicle()
cars.moveVehicle()The above is a lot of code, but we can use the diagram above to understand it. Essentially in the end, what we care about are custom handlers, here we call them handlers, rather than creators, because they don't just create the objects, they also have the logic to use them (the moveVehicle method). <p></p>The beauty of this pattern is that if you want to add a new vehicle type, all you have to do is add its vehicle class and its handler program class without increasing the LOC of any other class.
Observer Pattern because of the type behavior we can implement it.
type InternalState = {
event: String
}
abstract class Observer {
abstract update(state:InternalState): void
}
abstract class Observable {
protected observers: Observer[] = []
protected state:InternalState = { event: ""}
public addObserver(o: Observer):void {
this.observers.push(o)
}
protected notify () {
this.observers.forEach(o => o.update(this.state))
}
}
class ConsoleLogger extends Observer {
public update(newState: InternalState) {
console.log("New internal state update: ", newState)
}
}
class InputElement extends Observable {
public click():void {
this.state = { event: "click" }
this.notify()
}
}
const input = new InputElement()
input.addObserver(new ConsoleLogger())
input.click()As you can see, with two abstract classes, we can define Observer, which will represent an object that reacts to changes on the Observable entity. In the above example, we assume to have an InputElement entity that is clicked (similar to how you have HTML input fields on the front end), and a ConsoleLogger that logs to the console Everything that happened.
Observable without having to mess with its internal code. We can continue to add observers that perform other actions, even observers that react to specific events, and let their code decide what to do with each notification.
装饰模式试图在运行时向现有对象添加行为。 从某种意义上说，我们可以将其视为动态继承，因为即使没有创建新类来添加行为，我们也正在创建具有扩展功能的新对象。
这样考虑：假设我们拥有一个带有move方法的Dog类，现在您想扩展其行为，因为我们想要一只超级狗和一只可以游泳的狗。
通常，我们需要在 Dog 类中添加move 行为，然后以两种方式扩展该类，即SuperDog和SwimmingDog类。 但是，如果我们想将两者混合在一起，则必须再次创建一个新类来扩展它们的行为，但是，有更好的方法。
组合让我们可以将自定义行为封装在不同的类中，然后使用该模式通过将原始对象传递给它们的构造函数来创建这些类的新实例。 让我们看一下代码：
abstract class Animal {
abstract move(): void
}
abstract class SuperDecorator extends Animal {
protected comp: Animal
constructor(decoratedAnimal: Animal) {
super()
this.comp = decoratedAnimal
}
abstract move(): void
}
class Dog extends Animal {
public move():void {
console.log("Moving the dog...")
}
}
class SuperAnimal extends SuperDecorator {
public move():void {
console.log("Starts flying...")
this.comp.move()
console.log("Landing...")
}
}
class SwimmingAnimal extends SuperDecorator {
public move():void {
console.log("Jumps into the water...")
this.comp.move()
}
}
const dog = new Dog()
console.log("--- Non-decorated attempt: ")
dog.move()
console.log("--- Flying decorator --- ")
const superDog = new SuperAnimal(dog)
superDog.move()
console.log("--- Now let's go swimming --- ")
const swimmingDog = new SwimmingAnimal(dog)
swimmingDog.move()
注意几个细节:
SuperDecorator类扩展了Animal类，与Dog类扩展了相同的类。 这是因为装饰器需要提供与其尝试装饰的类相同的公共接口。SuperDecorator类是abstract ，这意味着并没有使用它，只是使用它来定义构造函数，该构造函数会将原始对象的副本保留在受保护的属性中。 公共接口的覆盖是在自定义装饰器内部完成的。SuperAnimal和SwimmingAnimal是实际的装饰器，它们是添加额外行为的装饰器。进行此设置的好处是，由于所有装饰器也间接扩展了Animal类，因此如果你要将两种行为混合在一起，则可以执行以下操作：
const superSwimmingDog = new SwimmingAnimal(superDog) superSwimmingDog.move()
关于Composite模式，其实就是组合模式,又叫部分整体模式，这个模式在我们的生活中也经常使用。
比如编写过前端的页面，肯定使用过<p></p>等标签定义一些格式，然后格式之间互相组合，通过一种递归的方式组织成相应的结构，这种方式其实就是组合，将部分的组件镶嵌到整体之中。
关于此模式的有趣之处在于，它不是一个简单的对象组，它可以包含实体或实体组，每个组可以同时包含更多组，这就是我们所说的树。
看一个例子：
interface IProduct {
getName(): string
getPrice(): number
}
class Product implements IProduct {
private price:number
private name:string
constructor(name:string, price:number) {
this.name = name
this.price = price
}
public getPrice():number {
return this.price
}
public getName(): string {
return this.name
}
}
class Box implements IProduct {
private products: IProduct[] = []
contructor() {
this.products = []
}
public getName(): string {
return "A box with " + this.products.length + " products"
}
add(p: IProduct):void {
console.log("Adding a ", p.getName(), "to the box")
this.products.push(p)
}
getPrice(): number {
return this.products.reduce( (curr: number, b: IProduct) => (curr + b.getPrice()), 0)
}
}
//Using the code...
const box1 = new Box()
box1.add(new Product("Bubble gum", 0.5))
box1.add(new Product("Samsung Note 20", 1005))
const box2 = new Box()
box2.add( new Product("Samsung TV 20in", 300))
box2.add( new Product("Samsung TV 50in", 800))
box1.add(box2)
console.log("Total price: ", box1.getPrice())
在上面的示例中，我们可以将product 放入Box中，也可以将Box放入其他Box中，这是组合的经典示例。因为我们要实现的是获得完整的交付价格，因此需要在大box里添加每个元素的价格(包括每个小box的价格)。
上面运行的结果：
Adding a Bubble gum to the box Adding a Samsung Note 20 to the box Adding a Samsung TV 20in to the box Adding a Samsung TV 50in to the box Adding a A box with 2 products to the box Total price: 2105.5
因此，在处理遵循同一接口的多个对象时，请考虑使用此模式。 通过将复杂性隐藏在单个实体（组合本身）中，您会发现它有助于简化与小组的互动方式。
今天的分享就到这里了，感谢大家的观看，我们下期再见。
原文地址：https://blog.bitsrc.io/design-patterns-in-typescript-e9f84de40449
作者：Fernando Doglio
译文地址：https://segmentfault.com/a/1190000025184682
更多编程相关知识，请访问：编程课程！！
The above is the detailed content of 5 TypeScript design patterns you need to know. For more information, please follow other related articles on the PHP Chinese website!