将“this”作为参数传递是不好的做法？
我现在很想写下面的内容：
public class Class1() { public Class1() { MyProperty = new Class2(this); } public Class2 MyProperty { get; private set; } } public class Class2() { public Class2(Class1 class1) { ParentClass1 = class1; } public Class1 ParentClass1 { get; set; } } 将“this”作为参数传递给设计问题的标志？ 什么是更好的方法？
不，传递this没有根本的设计问题。 显然，这可能会被误用（例如，当一个相关的类依赖于你自己的值的值时，依赖于存储在你的实例中的值来创建过于紧张的耦合），但它没有普遍的问题。
不，这不是问题。 这就是为什么’this’关键字存在，让你自己通过
你发布的内容很难说。 你应该问自己的问题是：为什么class2需要知道class1？ class2在其生命周期中将在class1上执行哪些类型的操作，是否有更好的方法来实现该关系？
这样做有正当理由，但这取决于实际的类。
通常我更喜欢将接口传递给’child’类，因为这会减少耦合。 如果Class2确实需要访问Class1的所有服务，并且Class2以这种方式公开（没有完全封装并由Class1构造），那么我会考虑在构造函数中要求一个具体的Class1实例，这是一个可能的设计问题的标志。
只是为了缓解你的想法：
this作为参数传递甚至可以通过BCL中的类来完成。 例如， List类型保存对其父List对象的引用，以便知道列表是否在枚举之间被修改（因此何时抛出InvalidOperationException ）。
当你有两个（或更多）类型实际上属于一个紧密结合的逻辑相关组（例如前面提到的集合和枚举器）时，这是非常标准的。 我已经看到很多情况下开发人员向后弯腰以避免这种完全合理的耦合，没有任何实际原因。
举个例子，看看访客模式：
interface IVisitor { Visit(SomeClass c); Visit(AnotherClass c); } interface IAcceptVisitor { void Accept(IVisitor v); } public SomeClass : IAcceptVisitor { void Accept(IVisitor v) { v.Visit(this); } }
我不太清楚C＃中的内存模型（根本没有）。 但是将它从构造函数传递到另一个对象在许多语言（包括Java）中本质上是不安全的。
如果您在构造函数中，则尚未构造该对象。 如果此时另一个对象决定使用传递的this参数，它将引用处于未定义状态的对象。
在您的示例中，这种未定义的用法不会发生，但您如何保证将来不会出现这种情况？ 如果有人以一种在自己的构造函数中使用ParentClass1中的东西的方式对类进行子类化/修改，该怎么办？
如果您的设计中明确需要关系， 那就不是问题。 该模式经常在各种应用中用于表示“父”或“所有者”。
我在编译器实现或GUI工具包中遍历树时特别使用它。