0

我有一个大类，用于应用程序的用户界面。它服务于大约 20 个模块。暂时只有一个模块，我需要在Label. 形成的应用程序化地只是一行源代码。案例的分离可以通过使用boolean标志变量来完成，或者通过应用inheritance：

通过布尔标志变量：

class MyClass{

    private boolean isYear;
    ...

    public setValue(){
    ...

    if(!isYear)
     doFormat();

    ...
    }

}

isYear当需要一个模块用于年份值时，该变量当然是在外部设置的。

通过应用继承，我必须创建一个派生自的新类MyClass，即MyYearClass仅覆盖该方法setValue()。我认为在 OO 编程中推荐使用第二种方法，但我也听说过这样的观点，即在这种情况下，它会使代码变得复杂、模糊、不整洁，而且当只需要一行代码时，这通常看起来有点矫枉过正。改变了。你认为什么方法值得推荐？

4

4 回答 4

0

我认为第二种方法是最佳实践。这似乎有点多余，但始终最好让您的编程尽可能模块化。试想一下，如果其他人正在使用您的代码，或者您稍后使用它并且不记得 MyClass 是如何工作的，但您想要做的就是使用 MyYearClass 的功能。

于 2013-08-14T12:26:25.087 回答
0

一如既往，这取决于。现在可以是一行，但以后可能会更多。我同意过度设计你的代码是不好的，但是如果你觉得当前的设计会改变（而且它通常会改变）你可以在这里和那里使用一个简单的设计模式。对于您的问题（稍后描述），我相信您可以创建一个简单的并让该工厂在您需要时Factory为您返回您需要的子类之一。MyClass

于 2013-08-14T08:42:48.747 回答
0

良好的设计实践将支持第二种方法（继承），因为从长远来看它更容易管理。当您开始将特定代码添加到公共类时，您正在打开一罐蠕虫病毒。也许不是你，而是在你之后工作的开发人员会添加另一个特性，另一个特性到同一个类，然后支持变成一场噩梦。

更让我担心的是你的“我有一个大班”的报价。好的设计原则会告诉你把它分开。

如果你的类有超过 1000 行，那么它是重构为特定功能的一个很好的候选者。

于 2013-08-14T08:43:52.003 回答
0

第二种方法通常更好。但是在您的情况下，您有一个逻辑简单的小类。如果你知道你将要对这个类进行大量更改并且它会变得更大更复杂，那么现在就拆分它。否则，您可能会保持原样，如果您觉得类变得太复杂，则将重构推迟到以后。相反，专注于应用程序的其他部分。

于 2013-08-14T09:26:48.303 回答