标签: class-design

我有这些课程和程序:

 TParent = class(TObject);
 TChild1 = class(TParent);     
 TChild2 = class(TParent);

 Procedure DoSomething(obj:TParent);

我想做的是什么时候obj,TParent而不是后代提出异常.

我想过做这样的事情:

if obj.classname = TParent.classname then raise exception.create....

但似乎有点hackish(TM)

更多:我的意图是能够传递共享属性/过程的对象.经过深思熟虑后,根本不需要TParent Object,我需要的是我的答案中显示的接口对象.

假设我有一个"应用程序"类.为了初始化,它需要在构造函数中进行某些设置.我们还假设设置的数量太多,以至于将它们放在自己的类中是很有吸引力的.

比较此方案的以下两种实现方式.

实施1:

class Application 
{
   Application(ApplicationSettings settings) 
   {
       //Do initialisation here
   }
}

class ApplicationSettings 
{
   //Settings related methods and properties here
}

实施2:

class Application 
{
   Application(Application.Settings settings) 
   {
       //Do initialisation here
   }

   class Settings 
   {
      //Settings related methods and properties here
   }
}

对我来说,第二种方法更为可取.它更具可读性,因为它强调了两个类之间的关系.当我编写代码以在任何地方实例化Application类时,第二种方法看起来更漂亮.

现在想象一下,Settings类本身又有一些类似的"相关"类,而该类反过来也是如此.只有三个这样的级别,类命名在'非嵌套'的情况下失控.然而,如果你筑巢,事物仍然保持优雅.

尽管如此,我还是读过人们在StackOverflow上说嵌套类只有在外部世界不可见时才被证明是合理的.也就是说,它们仅用于包含类的内部实现.通常引用的异议是包含类的源文件的大小膨胀,但是部分类是解决该问题的完美解决方案.

我的问题是,为什么我们对嵌套类的"公开暴露"使用持谨慎态度？还有其他反对这种用法的论据吗？

是否有任何免费工具可用于从c ++源文件生成类图,如果可能,也可用于mfc源文件.

使用嵌套类对常量进行分组有什么问题？

像这样:

public static class Constants
{
    public static class CategoryA
    {
        public const string ValueX = "CatA_X";
        public const string ValueY = "CatA_Y";
    }
    public static class CategoryB
    {
        public const string ValueX = "CatB_X";
        public const string ValueY = "CatB_Y";
    }
}

像这样使用:

Console.WriteLine(Constants.CategoryA.ValueY);
Console.WriteLine(Constants.CategoryB.ValueX);

你也可以使"常数" - 类偏...

让我们面对它编写好的toString消息是一个无聊的杂乱的工作需要完成,因为它可以真正有助于调试或记录中的检查.

你喜欢或希望在这样的帮手中有什么功能......

• 转储属性应该带标签.

  name = mP country =澳大利亚......

• 应该可以跳过某些默认值.

  • 没有必要打印许多0或null的属性.
  • 如果设置标签并且值为null,则不包括任何一个.

• 标签和值之间的分隔符应该是可更新的,并且在添加标签和值时应自动插入标签和值之间.

• 它还应该自动插入您选择的分隔符.

  如果你想在包含一个数组时让逗号在值之间留空间,那就这样吧.

• 它应该自动引用字符串值...因为知道字符串开始和结束的确切位置非常重要.

  *name = mP state ="新南威尔士"

• 当添加列表,地图或集合时,应该遵守有关引用字符串的规则,使用集合分隔符等.请不要只转储Collection.toString().

我还有其他一些人正在改进,你可以列出自己的想法,观察等.

  new ToStringBuilder()
    .setLabelValueSeparator('=')
    .label("name")
    .value(Country.AUSTRALIA) // -> returns "Australia" without the quotes.
    .label("day of death")
    .value(null) //
    .label("numbers")
    .valueSeparator(",");
    .value(Arrays.asList( 1, 2, 3 )
    .build();

当然会导致"name ="Australia"数字= 1,2,3;

C#类可以拥有的属性数量是否有限制？

我快速浏览标准ECMA-334并没有找到任何相关信息.

在进入为什么一个有很多方法的课程设计不好之前,我想更明确一下这个意图.当然,我不会手动编写一个包含大量方法的类.我问这个的原因是我需要通过代码生成大量的执行单元.我讨论的是具有单个方法的多个类或具有多个方法的一个大类.

所以对于这个问题,如果有限制我会感兴趣,属性数量,方法的限制是多少.

我有一个在xaml中创建的用户控件,让我们将其命名为"View".在View.xaml.cs中,我将类View的访问修饰符更改为internal:

internal partial class View : ViewBase { ... }

更改访问修饰符后,编译器会声明错误:

"ABView"的部分声明具有冲突的可访问性修饰符

我的第一个猜测是视图必须通过xaml代码在内部进行.所以我添加了两行xaml:

x:Name="View"
x:FieldModifier="internal"

但这并没有解决错误.我在哪里更改访问修饰符以使内部视图？

我正在尝试创建一个传递参数x并返回一个新类的函数C.C应该是固定基类的子类A,只有一个加法:添加某个类属性并设置为相等x.

换一种说法:

class C(A):
  C.p = x # x is the parameter passed to the factory function

这很容易吗？我应该注意哪些问题？

我有一个叫做的类List_Field,顾名思义,它构建列表输入字段.这些列表输入字段允许用户为每个列表选择单个项目.

我希望能够构建列表输入字段,允许用户为每个列表选择多个项目,所以我有以下两难:

我应该通过multiple_choice_allowed在现有List_Field属性中实现属性来实现,还是应该实现Multiple_Choice_List_Field类的子List_Field类？

面对像这样的困境,我应该遵循什么样的工程原理？

我对OO设计过程很新,所以请耐心等待....

我有两个实体,我需要建模为类,称为父和子(它足够接近实际的问题域).一位家长将有一个或多个孩子 - 在这个申请中,我对没有孩子的父母没有兴趣.

我的大脑出去吃午饭的地方是我需要能够找到另一个.在我的数据库中,我可以使用正常的外键关系实现它,并且SQL的基于集合的特性使得查找给定父项的所有子项或给定子项的父项变得容易.但作为对象......？

我认为家长应携带儿童的集合(列表,无论如何).我还认为每个孩子都应该提及其父母.然而,参考文献的循环性质让我头疼.

我是:

• 在正确的轨道上？
• 完全离开基地？如果是这样,我该怎么办？

这几乎肯定会在VB.NET中实现,但我还是可以通过切割代码来实现.

8个答案后编辑:

谢谢大家.很难选择一个接受的答案.

澄清答案中提出质疑的几件事:

• 父和子是非常不同的实体 - 根本没有继承关系.我选择了我所做的名字,因为它们真的非常接近真实世界的问题领域,现在看来它是从OO角度来看混淆的根源.
• 层次结构只有一层深度 - 孩子们永远不会在应用程序中拥有子级.

再次感谢.