设计 - 何时创建新功能?

时间:2010-12-30 15:37:49

标签: reusability

这是一个与任何语言无关的一般设计问题。我在寻求最低限度的代码或最佳组织方面有点不知所措。

我将以当前项目为例。我在表单上有一堆执行不同功能的选项卡。让我们说Tab 1读入一个具有特定布局的文件,tab 2将文件导出到一个特定的位置,等等。我现在遇到的问题是我需要这些标签根据a的内容做一些稍微不同的事情。变量。如果它包含1我可能需要使用布局A并执行一些额外的连接,如果它包含2我可能需要使用布局B并且不进行连接但是添加两个整数字段等。可能有10个以上的代码我将会看。

最好在早期为每个代码创建单独的路径,或者尝试创建仅在绝对需要时分支出来的单个路径。

为每个代码创建一个单独的路径将使我的代码一目了然非常容易,这反过来将帮助我在以后调试或进行更改时。这样做的缺点是我会通过在多个地方调用一些相同的函数来增加编写的代码量(例如,每个代码的步骤3,5和9可能完全相同。

创建一个只在需要时才会分支出来的单一路径会有点麻烦而且难以一目了然,但我会通过仅将条件放在唯一的步骤来创建更少的代码。

我意识到这可能是个案决定,但总的来说,如果你交了一个以前建立的程序来处理,你更喜欢哪个?


编辑:我画了一些简单的图片来帮助表达它。代码1/2/3是变量,它们下面的行表示它们将采用的路径。所有这些步骤都需要以线性时间顺序执行,因此基本上只需按正确的顺序调用其他函数。

不同的路径

alt text

单一路径

alt text

4 个答案:

答案 0 :(得分:3)

  

创建一个可以的单一路径   只有在需要时才会分支出来   有点麻烦,更难   一目了然,但我会创造   通过仅放置条件来减少代码   在独特的步骤。

我不买这个声明。在决定何时编写新功能时,有一定程度的技巧。功能应该尽可能简单和可重用(但不能简单)。正确的答案几乎从来都不是“一个可以进行大量分支的大文件”。

较少的LOC(代码行)不应该是目标。可读性和可维护性应该是目标。创建函数时,名称应该是自我记录的。如果你有一大块代码,最好做一些像

这样的事情
   function doSomethingComplicated() {
        stepOne();
        stepTwo(); 
        // and so on
   }

其中函数名称是自我记录的。代码不仅更具可读性,而且可以更容易地单独测试代码的每个代码段。

对于您将拥有许多调用相同方法的方法的情况,您可以使用良好的OO设计和设计模式来最小化执行相同操作的函数的数量。这是对你的陈述的引用“这样做的缺点是我将通过在多个地方调用一些相同的函数来增加编写的代码量(例如,对于每个代码,步骤3,5和9可能是准确的同样的。“

从一大块代码开始,最大的危险在于它实际上永远不会被重构为更小的单元。只需从正确的道路开始......

编辑 -

对于你的图片,我将使用所有常用方法创建一个基类。基类是抽象的,带有抽象方法。子类将实现抽象方法并使用它们所需的常用函数。当然,用你选择的语言替换“抽象”。

答案 1 :(得分:1)

你总是应该在泛化方面犯错,唯一的例外是早期原型设计(生成工作的吞吐量主要受设计正确的抽象/概括的影响)。话虽如此,你不应该把那些乱七八糟的非泛化克隆分支留在早期的原型阶段,因为它会导致难以维护的代码(如果你在3个不同的时间做了几乎相同的事情,需要改变那个东西) ,你几乎肯定会忘记改变1中的1分。

答案 2 :(得分:0)

同样很难专门回答这样一个开放式问题,但我相信你不必为另一个问题牺牲一个。

OOP技术允许您封装代码的可重用部分并生成子类来处理特定于对象的行为,从而解决了这个问题。

答案 3 :(得分:0)

就我个人而言,我认为您可以(如果可能,通过您的API)创建继承的表单,在主表单上创建它们(带标签),传递agruments并嵌入标签容器。

何时继承表单以及何时决定使用参数(代码)来显示/隐藏/添加/删除功能取决于您,但是主表单应该只包含决策和参数传递和可嵌入表单只是简单的功能 - 这种方式您可以将组织与实施分开。