Initialize()vsConstructor()方法，正确使用创建对象我们都知道Constructor和用户自定义Initialize()方法的区别.我的问题侧重于对象创建的最佳设计实践。我们可以将所有Initialize()代码放入Constructor()中，反之亦然（将所有预热代码移至Initialize方法并从Constructor调用此方法）。目前，在设计新类时，我会在constructor()中创建任何新实例，并将任何其他预热代码移至Initialize()方法中。你认为最好的权衡是什么？我认为应该考虑几个方面：因此，在大多数情况下，Initialize方法是不需要的。如果初始化涉及的不仅仅是将对象置于可用状态（例如，当需要执行繁重的工作或需要调用虚拟成员或外部对象时），则Initialize方法是一个好主意。我发现自己最近在思考这个问题（因此找到了这个问题），虽然我没有答案，但我想我会分享我的想法。this.member=成员；在我看来，这很好地补充了IoC、继承和测试。但有时需要繁重的工作，所以我一直在尝试做的是：这意味着将初始化代码抽象到另一个类中并将其传递进来。这通常是因为繁重的工作不是你的对象的责任，所以这样做实际上可以重构更好的代码。如果那不可能，并且您确实需要在使用前初始化类的状态，则添加一个初始化方法。这确实为代码添加了时间依赖性，但这不一定是坏事，尤其是在使用IoC容器时：假设CarEngine需要一个DrivingAssistComputer，而DrivingAssistComputer需要大量初始化，即加载所有参数、天气状况检查,等等。另一件需要注意的事情是CarEngine不直接与DrivingAssistComputer交互，它只需要它存在并完成它的一部分。事实上，如果没有DrivingAssistComputer在后台执行DrivingAssistComputer（在某处更改某些状态），引擎可能无法正常工作。如果我们使用IoC，那么我们有：//没有初始化（即在计算机构造函数中完成初始化）publicCarEngine(FuelInjectorsinjectors,DrivingAssistComputercomputer){this.injectors=injectors;//不需要引用计算机，因为我们并不真正与它交互。}...所以我们在这里有一个构造函数参数，将computer标记为依赖项，但实际上并没有使用它。所以这很丑陋，但让我们添加一个Initialise方法：publicCarEngine(FuelInjectorsinjectors,DrivingAssistComputercomputer){//这当然也可以移动到CarEngine.Initialsecomputer.Initialise();}...仍然不是一个有凝聚力的类，但至少我们知道我们依赖于计算机，即使我们没有在构造函数之外直接与它交互。另一种选择是使用CarEngineFactory：CarEngineCreateEngine(FuelInjectorsinjectors){newDrivingAssistComputer().Initialise();返回新的CarEngine（喷油器）；}...但是，我发现工厂和IoC只是混淆矩阵，所以我会选择前两个选项。很想听听对此的一些想法。编辑1：我错过的另一个选择是使用Initialise方法，但将此调用移至IoC初始化模块。所以创建和初始化还是有些封装的。以上就是C#学习教程：Initialize()vsConstructor()方法，正确使用创建对象共享的所有内容。如果对大家有用，需要了解更多C#学习教程，希望大家多加关注——本文来自网络合集，不代表立场，如涉及侵权，请右击联系管理员删除。如需转载请注明出处：
