将“this”作为参数传递是不好的做法吗？我现在很想写以下内容：publicclassClass1(){publicClass1(){MyProperty=newClass2(this);}publicClass2MyProperty{得到;私有集；}}publicclassClass2(){publicClass2(Class1class1){ParentClass1=class1;}publicClass1ParentClass1{get;放;将“this”作为参数传递给设计问题？什么是更好的方法？不，通过这个没有根本的设计问题。显然这可能会被误用（例如，当相关类依赖于你自己的值时，依赖于存储在你的实例中的值会产生过于紧密的耦合），但它没有一般性问题。不，这不是问题。这就是存在“this”关键字的原因，这使得很难通过发布的内容告诉自己。您应该问自己的问题是：为什么class2需要了解class1？class2将在其生命周期内对class1执行哪些类型的操作，是否有更好的方法来实现这种关系？这样做有充分的理由，但这取决于实际的班级。通常我更喜欢将接口传递给“子”类，因为这样可以减少耦合。如果Class2确实需要访问Class1的所有服务，而Class2是这样暴露出来的（没有被Class1完全封装构造），那么我会考虑在构造函数中要求一个具体的Class1实例，这可能是设计问题。符号。只是为了让您放心：将this作为参数传递甚至可以通过BCL中的类来完成。例如，List.Enumerator类型保留对其父List对象的引用，以便了解列表是否在枚举之间被修改（以及因此何时抛出InvalidOperationException）。当您有两个（或更多）类型实际上属于一个内聚的、逻辑上相关的组（例如前面提到的集合和枚举器）时，这是非常标准的。我见过许多开发人员竭尽全力避免这种完全合理的耦合的情况，没有任何真正的原因。举个例子，看看访问者模式：interfaceIVisitor{Visit(SomeClassc);访问（另一个c类）；}interfaceIAcceptVisitor{voidAccept(IVisitorv);}publicSomeClass:IAcceptVisitor{voidAccept(IVisitorv){v.Visit(this);我不太确定C#中的内存模型（一点也不）。但是将它从构造函数传递给另一个对象在许多语言中本质上是不安全的，包括Java。如果您在构造函数中，则该对象尚未构造。如果此时另一个对象决定使用传递的this参数，它将引用处于未定义状态的对象。在您的示例中，这种未定义的用法不会发生，但是您如何保证它将来不会发生？如果有人以在自己的构造函数中使用来自ParentClass1的东西的方式对类进行子类化/修改怎么办？如果您在设计中明确需要关系，那不是问题。这种模式通常用于各种应用程序中，表示“父母”或“所有者”。我特别在编译器实现或GUI工具包中遍历树时使用它。以上是C#学习教程：将“this”作为参数传递是不好的做法吗？如果所有分享的内容对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
