Answers:
如果我理解正确，这意味着在有意义之前不要使用设计模式，对吗？
是。
不要一开始就说要使用策略模式，请等到编写一些代码为止，如果使用策略模式对您的设计有意义，那么就使用它。
是。从技术上讲，您甚至可能在编写任何代码之前就已经意识到策略模式是适当的，但这应该是因为您正在考虑实际问题并为该问题设计解决方案，我认为这就是您的意思。
创建GUI应用程序时，是否以相同方式对待MCV / MVP模式？从各自的链接，它说这是一种建筑模式。
是的，MVC / MVP / etc是架构模式。从某种意义上说，这没有什么区别，因为您仍然应该只在有意义的情况下使用MVC / MVP / etc。当它正适合您要解决的实际问题时。确实有所不同的地方是，由于它的应用水平要比策略模式高得多，因此您通常会弄清楚它是否有意义并决定是否将其用作策略的一部分。您的设计工作，然后编写大量代码。
另外请记住，“ MVC / MVP”不是一个单一的模式，而是一个非常大的相关模式系列，对于“ MVC”或“ MVP”或“ MVVM”或其他类型的确切含义尚无共识相关的字母汤。
假设如果我创建一个GUI应用程序并且不使用MCV / MVP模式，但是我的代码是干净，可读且可维护的，那么我是否仍未使用MCV / MVP模式仍然是代码异味/不良设计？ ？
根本不行，因为MVC / MVP / etc不适用于每个GUI应用程序。例如，某些GUI可能非常简单，以至于完全被矫kill过正，或者某些GUI可能没有任何持久状态可放入“模型”中，等等。有充分的理由说明该系列模式如此受欢迎，但是它们不是编写优质GUI软件的唯一方法。
同样，“代码气味”通常表示有关特定代码段的某些内容，这可能是更大问题的征兆。如果您所有的代码都是“干净，可读且可维护的”，没有任何例外，那么按照定义，您几乎没有任何代码气味（除了一些“假阳性”代码气味并不表示任何实际问题） ）。
因此，回答您的问题的标题：“如何对待MVC / MVP模式？”，我想说：请阅读为什么这些模式如此流行，即它们正在尝试解决什么问题，以便将来使用。您可以判断出您的最新问题是否可以通过这些模式解决。