我的一个朋友正在讨论关于对象的状态转换的这些设计技术(他是一个
Java大师,顺便说一句),没有布尔myState成员执行,而是将myState成员声明为实现相同接口的对象老板“一个.
就个人而言,我对这种方法很兴奋,因为我的朋友向我解释了背后的哲学;从设计的角度来看,我也认为它非常连贯.顺便说一句,我关心的是性能和内存使用情况,因为编译时和运行时优化可能会进入游戏.由于我不了解JIT编译器和JVM内部,我很想知道更广泛的意见.
你有什么想法?
解决方法
这听起来像是在询问使用状态设计模式是否具有“具体有用”的好处,我肯定是肯定的,特别是如果你的应用程序实际上很大程度上依赖于其对象的“状态”.一个流行的规范示例是视频播放器,它总是处于一种状态,并且只能根据它当前所处的状态转换到不同的状态(例如,如果它已经停止但是它可以播放它不能停止,它可以倒带,等等).
虽然可以使用少数if / else / switch类型条件(if(isStopped()),play()等)相对容易地管理该特定示例,因为没有那么多状态要处理,当状态或者他们的转换规则开始变得更多或更复杂,状态模式绝对变得非常有价值,因为没有它,你的代码往往会像疯了一样积累其他东西,随着时间的推移,事情变得越来越不易读和可管理.
所以是的,一般来说,如果你发现你的对象的行为根据它们的状态而变化(如果isStopped()play()/ elseif isPlaying()stop()/ elseif(isBroken()fix())等),那么是的,请考虑使用State模式.这是一个更多的工作,但通常值得努力,并做得正确我怀疑你会发现任何显着的开销只是为了使用它.
Head First Design Patterns也提供了它的方法和原因的很好的描述 – 我强烈建议将这本书拿给几乎任何编写面向对象代码的人.