Fed*_*can 7 java oop design-patterns
我的一个朋友正在讨论关于对象的状态转换的这些设计技术(他是一个Java大师,顺便说一句),在没有boolean myState成员的情况下执行,而是将该myState成员声明为实现"所有者"的相同接口的对象.
好吧,我太神秘了,所以你可以在这里找到讨论代码示例.
就个人而言,我对这种方法很兴奋,因为我的朋友向我解释了背后的哲学; 从设计的角度来看,我也认为它非常连贯.顺便说一句,我关心的是性能和内存使用情况,因为编译时和运行时优化可能会进入游戏.由于我不了解JIT编译器和JVM内部,我很想知道更广泛的意见.
你有什么想法？
我不同意 - 除了有用的设计模式,这个特殊的例子是荒谬的过度杀伤:
我没有看到这是一个改进 - 它违反了YAGNI 1和ASAP 2,使代码膨胀,并降低了效率(多个对象在不需要时实例化以完成工作).
作为一种智力锻炼,温和有趣.作为编程习惯,可怕!;-)
2 ASAP =尽可能简单
听起来您好像在问使用状态设计模式是否有“具体有用”的好处，对此我肯定会说是的，特别是如果您的应用程序实际上严重依赖于其对象的“状态”。一个流行的规范示例是视频播放器，它始终处于一种状态，并且只能根据当前所处的状态转换为不同的状态（例如，如果已经停止，则无法停止，但可以播放，并且它可以倒带，等等）。
虽然可以使用一些 if/else/switch 类型条件（if (isStopped())、play() 等）相对轻松地管理该特定示例，因为没有那么多状态需要处理，但当状态或者它们的转换规则开始变得越来越多或越来越复杂，状态模式绝对变得非常有价值，因为如果没有它，您的代码往往会疯狂地积累 elseif，并且随着时间的推移，事情会变得越来越难以阅读和管理。
所以是的，一般来说，如果您发现对象的行为根据其状态而变化（if isStopped() play() / elseif isPlaying() stop() / elseif (isBroken() fix()) 等），那么是的，请考虑使用状态模式。预先需要做更多的工作，但通常非常值得付出努力，并且做得正确，我怀疑您不会注意到仅仅因为使用它而产生的任何重大开销。
《Head First Design Patterns》也很好地描述了它的原理和原因——我强烈建议几乎所有编写面向对象代码的人都拿起这本书。