interface out 类 in javascript 去耦合
interface out classes in javascript to de-couple
我试图理解此 tutorial 的第一部分是界面部分,而不是 IOC 部分。
我认为措辞很混乱,所以只是想得到更清楚的解释。
教程中的这句话是我不理解的地方。
Therefore, so that our code isn’t as tightly coupled, we should
interface out the dependencies and reference these interfaces instead.
我创建了一个示例 fiddle 与上面的教程使用界面完全一样。
https://jsfiddle.net/89w32ajh/13/
从第一个 class 示例到接口示例,我得到了什么解耦?除了使它更紧凑的接口之外,你必须在 class 本身中拥有接口所需的东西。
我只是没有看到他在引述中谈到的脱钩。
我仍然在构造函数中调用 new Plant() 和 new WateringCan()。
interface IPlant {
name: string;
}
class Plant implements IPlant {
public name: string;
constructor(name: string) {
this.name = name;
}
}
interface IWateringCan {
material: string;
water (plant: IPlant): void;
}
class WateringCan implements IWateringCan {
private material: string;
constructor(material: string){
this.material = material;
}
public water(plant: Plant) {
const str = plant.name + 'is been watered by a ' + this.material + ' waterign can';
return str;
}
}
class Gardener {
private plant: IPlant;
private wateringCan: IWateringCan;
constructor () {
this.plant = new Plant("Daffodil");
this.wateringCan = new WateringCan("Steel");
}
public waterPlant(): void {
return this.wateringCan.water(this.plant);
}
};
const gardner = new Gardener();
gardner.waterPlant();
提前感谢您的帮助。
稍后,当您重构代码并提供不同的实现时,或者当您注入一个实现时,契约保持不变,并且您的类型检查器会告诉您新的实现是否满足它。
如果没有这个,当你把具体的实现作为类型时,一旦你改变了实现,你就会同时改变类型,并且你不能保证新的实现满足契约。
此外,当您构建新的实施时,您可以实施契约,并且在您满足契约之前,您会得到诸如“实施所有必需的成员”之类的信息和错误。
只有一个具体的实现,唯一的好处是在替换该组件(未来重构)期间。如果您转向可注入组件 - 例如可选的数据库连接器,那么您将受益于 contract-based 接口。
稍后您可以创建一个实现 IPlant
的 BigPlant
class,并使用少量重构支持注入的依赖项。很简单:
class Gardener {
private plant: IPlant;
private wateringCan: IWateringCan;
constructor (PlantClass: IPlant) {
this.plant = new PlantClass("Daffodil");
this.wateringCan = new WateringCan("Steel");
}
public waterPlant(): void {
return this.wateringCan.water(this.plant);
}
};
在实践中,您可以将其用于诸如在您不知道或不关心底层数据库的情况下注入数据库提供程序之类的事情 - 只是数据库提供程序实现了您需要的合同。
这样您的应用程序就可以支持各种数据库,而不是与特定的数据库提供程序紧密耦合。
我试图理解此 tutorial 的第一部分是界面部分,而不是 IOC 部分。 我认为措辞很混乱,所以只是想得到更清楚的解释。
教程中的这句话是我不理解的地方。
Therefore, so that our code isn’t as tightly coupled, we should interface out the dependencies and reference these interfaces instead.
我创建了一个示例 fiddle 与上面的教程使用界面完全一样。 https://jsfiddle.net/89w32ajh/13/
从第一个 class 示例到接口示例,我得到了什么解耦?除了使它更紧凑的接口之外,你必须在 class 本身中拥有接口所需的东西。
我只是没有看到他在引述中谈到的脱钩。 我仍然在构造函数中调用 new Plant() 和 new WateringCan()。
interface IPlant {
name: string;
}
class Plant implements IPlant {
public name: string;
constructor(name: string) {
this.name = name;
}
}
interface IWateringCan {
material: string;
water (plant: IPlant): void;
}
class WateringCan implements IWateringCan {
private material: string;
constructor(material: string){
this.material = material;
}
public water(plant: Plant) {
const str = plant.name + 'is been watered by a ' + this.material + ' waterign can';
return str;
}
}
class Gardener {
private plant: IPlant;
private wateringCan: IWateringCan;
constructor () {
this.plant = new Plant("Daffodil");
this.wateringCan = new WateringCan("Steel");
}
public waterPlant(): void {
return this.wateringCan.water(this.plant);
}
};
const gardner = new Gardener();
gardner.waterPlant();
提前感谢您的帮助。
稍后,当您重构代码并提供不同的实现时,或者当您注入一个实现时,契约保持不变,并且您的类型检查器会告诉您新的实现是否满足它。
如果没有这个,当你把具体的实现作为类型时,一旦你改变了实现,你就会同时改变类型,并且你不能保证新的实现满足契约。
此外,当您构建新的实施时,您可以实施契约,并且在您满足契约之前,您会得到诸如“实施所有必需的成员”之类的信息和错误。
只有一个具体的实现,唯一的好处是在替换该组件(未来重构)期间。如果您转向可注入组件 - 例如可选的数据库连接器,那么您将受益于 contract-based 接口。
稍后您可以创建一个实现 IPlant
的 BigPlant
class,并使用少量重构支持注入的依赖项。很简单:
class Gardener {
private plant: IPlant;
private wateringCan: IWateringCan;
constructor (PlantClass: IPlant) {
this.plant = new PlantClass("Daffodil");
this.wateringCan = new WateringCan("Steel");
}
public waterPlant(): void {
return this.wateringCan.water(this.plant);
}
};
在实践中,您可以将其用于诸如在您不知道或不关心底层数据库的情况下注入数据库提供程序之类的事情 - 只是数据库提供程序实现了您需要的合同。
这样您的应用程序就可以支持各种数据库,而不是与特定的数据库提供程序紧密耦合。