将"this"作为论据传递是不好的做法？

Question

我现在很想写下面的内容:

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"作为参数传递给设计问题的标志？什么是更好的方法？

Answer 1

不,传递没有基本的设计问题this.显然,这可能被误用(例如,当一个相关的类依赖于你自己的值的值时,依赖于存储在你的实例中的值来创建过于紧张的耦合),但是它没有普遍的问题.

Answer 2

不,这不是问题.这就是为什么'this'关键字存在,让你自己传递

Answer 3

你发布的内容很难说.你应该问自己的问题是:为什么class2需要知道class1？class2在其生命周期中将在class1上执行哪些类型的操作,是否有更好的方法来实现该关系？

这样做有正当理由,但这取决于实际的类.

Answer 4

一般来说,我更喜欢将接口传递给'child'类,因为这会减少耦合.如果Class2真的需要访问Class1的所有服务,并且Class2以这种方式公开(没有完全封装并由Class1构造),那么我会考虑在构造函数中要求一个具体的Class1实例作为可能的设计问题的标志.

Answer 5

只是为了缓解你的想法:

this作为参数传递甚至由BCL中的类完成.例如,该List<T>.Enumerator类型保存对其父List<T>对象的引用,以便知道列表是否在枚举之间被修改(因此何时抛出一个InvalidOperationException).

当你有两个(或更多)类型实际上属于一个紧密结合的逻辑相关组(例如前面提到的集合和枚举器)时,这是非常标准的.我已经看到很多情况下开发人员向后弯腰以避免这种完全合理的耦合,没有任何实际原因.