考虑以下来自Web Dev Simplified的视频中的依赖反转原理的代码:https://www.youtube.com/watch?v=9oHY5TllWaU
class Store {
constructor(paymentProcessor) {
this.paymentProcessor = paymentProcessor;
}
purchase(quantity) {
this.paymentProcessor.pay(200 * quantity);
}
}
class StripePaymentProcessor {
constructor(user) {
this.user = user;
this.stripe = new Stripe(user);
}
pay(amountInDollars) {
this.stripe.makePayment(amountInDollars * 100);
}
}
class Stripe {
constructor(user) {
this.user = user;
}
makePayment(amountInCents) {
console.log(
`${this.user} made a payment of $${amountInCents / 100} with Stripe`
);
}
}
class PayPalPaymentProcessor {
constructor(user) {
this.user = user;
this.paypal = new PayPal();
}
pay(amountInDollars) {
this.paypal.makePayment(this.user, amountInDollars);
}
}
class PayPal {
makePayment(user, amountInDollars) {
console.log(`${user} made a payment of $${amountInDollars} with PayPal`);
}
}
// const store = new Store(new StripePaymentProcessor('John'));
const store = new Store(new PayPalPaymentProcessor('John'));
store.purchase(2);
这应该是一个成功实现依赖反转原理的例子,因为我们松散地耦合了高级模块Store
和低级模块Stripe
和Paypal
。
然而,让我感到困扰的是,我们正在StripePaymentProcessor
和PayPalPaymentProcessor
中创建Stripe
和Paypal
的新示例。
因为我们在这些类中示例化另一个类,而没有通过参数注入它,我们不是创建了一个隐藏的依赖项吗?因此违反了SOLID中的D?我们不是只是将依赖项移动到另一个类吗?
如果这不是违规,那么我们是否可以在一个低级模块中示例化一个不同的低级模块?
在Typescript中包含每个支付处理器作为使用PaymentProcessor
接口的Store
的参数,是否可以通过应用抽象来解决依赖性问题?
这让我很生气&我希望你能澄清一下。谢谢。
1条答案
按热度按时间kdfy810k1#
Stripe和PayPal既不被认为是依赖项,也不被认为是低级模块。
这两个构造表示数据模型或域模型,或者简单地表示具有要持久化到存储中或要检索到客户端的信息的实体。
因此,它们不应该有生命周期方面。根据定义,它们是作为流的一部分在特定点创建(或从存储中查询)的。
商店示例的作者(如您所呈现的)选择在处理器对象的构造函数中示例化Stripe(或PayPal)的单个示例,可能是为了简化,但在某些场景中仍然可以被认为是有效的。