Answers:
重用是良好设计的指标。这表明系统的耦合足够松散,特定单元的内聚性足够高,可以促进重用,而不会遇到依赖关系问题或不必重写大多数代码。
可重用性在很大程度上是一种幻想。在不事先知道将在何处或如何使用的情况下,测量一个单元的“可重用性”是不可验证的。许多开发人员将尝试设计“可重复使用的”组成部分,经常发现后,他们试图使“灵活”的具体方面是到底是哪的那些并不需要的人。
我会使用另一种“光泽”:可测试性。
现在我不是TDD的拥护者,也不觉得需要对任何事物进行单元测试。但是为组件编写测试将使您很快地很好地了解其耦合/内聚特性。如果它依赖抽象,那就是松耦合。您会发现模拟依赖关系很容易,这表明设计很好。如果它有明确的目的(另请参见“ 单一责任原则”),则其行为将相对直观,您会发现很容易弄清要测试的内容,这再次表明是一个好的设计。
当然,这不能保证一个好的设计。实际的实现甚至整个体系结构可能都不适合其既定的目的。但是,至少它告诉您您不使用意大利面条代码或God Objects。
请不要对组件的“可重用性”进行大胆的猜测,尤其不要用作“良好设计”的证据。只有在实际重用它之后,您才可以事后确定它,然后设计可能会发生重大变化。
没有。
可重用性是一个很好的功能,因为它可以加快未来的发展。(尽管在实践中,很少有组织看到未来的发展速度几乎达到了他们希望的速度。)但是,任何重要的软件都有特定于该应用程序的部分。而且,当没有领域经验的人尝试编写可重用软件时,他们通常会混淆该部分并降低性能,而实际上并未使其成功可重用。
因此,好的设计是模块化的,并且仅在您可以看到部件可以重复使用的地方,并且您具有实际实现可重复使用性的专业知识时,才可以重复使用。在其他地方,您应该尝试使事物整洁,但不要担心可重用性。(除了在脑后做笔记之外,以便在将来的某些系统上,您会知道如何使该笔记可重用。)
我相信(这是我个人的信念),可重用性与良好设计之间的关系不是自反的,因此基本且简单的答案是“ 否”。如果您对一些好的设计指南感兴趣,请查看此 Wikipedia文章。
一个好的软件设计至少在某些核心部分必须是可重用的,我认为很少有人真正地重用源代码,这是因为将系统的核心设计为可在许多不同的上下文中重用是极其复杂的事实。 (我说这是出于经验)
考虑一类具有大量职责(又名Blob)的类,可以很好地执行您需要的所有任务,但完全没有任何设计方面的考虑,也许您已经看到了这种情况。拥有此类的大多数人会反复使用它,我认为我们必须同意它是可重用的,无设计的重用。
希望我不要把我的解释弄得太乱
可重用性通常是一个隐式设计目标。如果你可以创建一个部件或整个设计,在这样一种方式,它可以在以后重复使用,它似乎很明显,你应该做的。并非总是显而易见的是,使某些东西可重复使用可能需要大量的时间和精力(和金钱),因此必须权衡可重复使用性的好处和成本。
从客户的角度来看,成本比客户所需成本高两倍和/或所需时间两倍的可重用设计并不是一个好的设计,特别是在客户不需要可重用性的情况下。
有许多相似的属性通常被认为是隐式设计目标,因为它们看起来似乎很不错:
降低成本
缩短开发时间
最小化复杂度
最大化可靠性
这些东西在客观上都是不错的,但对于特定时间的特定客户而言可能并不总是很重要,因此,充分了解客户的需求(即使该客户只是您的老板)也很重要。有很多格言让我们想起这个事实(例如,“做得比完美更好”和“好,便宜,快速:选择其中两个”),但是仍然容易陷入尝试当实际上并不总是需要在各个方面都出色的软件时,就可以制作在各个方面都很棒的软件。
为了解决标题问题,那么:不,可重用性不是好的设计的代名词。可重用性可能是特定良好设计的有用组成部分,但仅在需要时才有用。