【问题标题】:Accessing subclasses from the parent class从父类访问子类
【发布时间】:2018-06-22 19:53:18
【问题描述】:

对于我构建的许多应用程序,我使用一个包含许多常用方法的自定义类。

随着时间的推移,这个库已经变得相当广泛,现在我正在尝试清理那个库并为每个类别添加子类,例如常规、调试、日志记录和设置。

目前我的班级是这样的:

public class General
{
    public Form frmMain;

    public void updateText(Control ctrl, string content)
    {
        if (ctrl != null && (ctrl is Label || ctrl is TextBox))
        {
            if (ctrl.InvokeRequired)
            {
                ctrl.Invoke(new MethodInvoker(delegate
                {
                    ctrl.Text = content;
                }));
            }
            else ctrl.Text = content;
        }
    }
}

我想做的是像这样转换它:

public class Library
{
    public class General
    {
        public Form frmMain;
        public void updateText(Control ctrl, string content)
        {
            if (ctrl != null && (ctrl is Label || ctrl is TextBox))
            {
                if (ctrl.InvokeRequired)
                {
                    ctrl.Invoke(new MethodInvoker(delegate
                    {
                        ctrl.Text = content;
                    }));
                }
                else ctrl.Text = content; 
            }
        }
    }

    public class Settings
    {
        public Form frmMain;
        public void someMethod() { }
    } 
}

在实现中我想引用类库,例如:

Tools.Library library = new Tools.Library();

但我真的不想为每个子类实现新变量。理想情况下,我想从 Library 类中访问不同的方法。 例如:

Tools.Library library = new Tools.Library();
library.General.updateText(lblTest, "test");
library.Settings.someMethod();

有没有办法做到这一点? 谢谢。

【问题讨论】:

  • 将 General 和 Settings 类设为静态(当然还有这些类中的所有方法)
  • 从您发布的代码看来,您可以制作这些静态类和方法。您的构造函数没有接受任何参数,并且方法中没有引用 frmMain。一般来说,我发现如果我有一个可重用的实用程序方法,那么它很可能可以设为静态并存在于静态类中。
  • 这是一个糟糕的设计......但如果你不能实现一些关注点分离,我猜上面的解决方案是不错的。
  • 你试过继承吗? Class General extends Library 这样General 类就获得了Library 类的所有方法。像在代码中那样在另一个类中声明一个类并不常见
  • @BradleyDotNET 感谢您的支持 ;-) 我总是乐于接受建议,您将如何处理?

标签: c# class subclass


【解决方案1】:

除了将所有嵌套类设置为静态(如果这适合您需要,这样做是一个更好的选择),您可以在主类“库”的构造函数中实现嵌套类“通用”。不过这有点奇怪。

另外我认为重要的是要注意这不是一个“子类”,它是完全不同的东西。这些是“嵌套类”。如果您在此处搜索“子类”并尝试将这些建议应用于您的“嵌套类”想法,您可能会在 Google 上得到一些非常错误的建议。

namespace Tools
{
    public class Library
    {
        public General general;

        public Library
        {
             general = New General();
        }

        public class General
        {

            public Form frmMain;


            public void updateText(Control ctrl, string content)
            {
                if (ctrl != null && (ctrl is Label || ctrl is TextBox))
                {
                    if (ctrl.InvokeRequired)
                    {
                        ctrl.Invoke(new MethodInvoker(delegate
                        {
                            ctrl.Text = content;
                        }));
                    }
                    else
                    {
                        ctrl.Text = content;
                    }
                }
            }


        }

        public class Settings
        {

            public Form frmMain;


            public void someMethod()
            {

            }


        }

}

然后你可以在不初始化嵌套类的情况下引用它的方法(因为它已经在主类的构造函数中初始化了)。

Tools.Library library = new Tools.Library();
library.general.updateText(...);

【讨论】:

  • 不过,我认为,如果这些类真的是一组通用的通用方法,那么 static 方法可能更好,并避免所有这些构造函数
  • 感谢 JNevill 的回答。在设计方面,这是否是在常用方法中实现某种结构的正确方法,还是您会使用另一种方法?
  • 我对回答这个问题没有信心。我肯定使用过这样的嵌套类来为复杂对象建模。一个拥有自己的方法和属性的父对象(就像汽车有颜色并且可以加速),它有一个子类,该子类永远不会在父类之外实现,但与父类的区别在于它有它有自己的属性和类别(就像具有多个气缸并且可以增加或减少其吸入的气体量的发动机)。然后引擎嵌套在 Car 类中,并通过 Car 的实现来实现。
  • 您可以在这里做的一件好事是在General 的构造函数中,您可以将父类作为参数。 public General(Library parent) 并将parent 作为General 的属性设置在构造函数this.parent = parent; 中。然后,当您在Library 构造函数中实现general 时,您可以执行general = New General(this);。现在General 获得了关于它嵌套的类的实例的知识。在 Car/Engine 示例中,实现的 engine 会知道关于它的事情是 Car
  • *但是...这在您的情况下可能没有意义,因为这似乎是为了代码组织而进行的类嵌套。我的意思是..如果是这种情况,那么将整个事情设为静态可能是有意义的,因为您不太可能实现Library 的多个实例,或者如果您这样做,那么可能不会有多个实例General..你知道?像这样感觉就像您将常用函数折腾到类结构中一样。不过很难说,因为我不知道“图书馆”和“一般”在这种情况下是什么意思。
猜你喜欢
  • 1970-01-01
  • 2017-10-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2017-12-02
  • 1970-01-01
相关资源
最近更新 更多