《设计模式》这本书不是程序员必备书籍嘛？你不看书，开玩笑呢，大兄弟，２３种设计模式就是解决架构耦合的问题的。怎么可能不看。这本书就是圣经。你光学会编程语言是不行的，是没有工程能力的，你必须学设计模式（OOP编程经验）。你现在要做项目，但是对于编程经验欠缺，所以我推荐你去了解ｍｖｃ、三层架构，了解两种个常用的架构模式（还有其它的架构模式）。快速运用到工作里来。你花一晚上看看ｍｖｃ，第二天就超神了，为啥不看？
这是前人用面向对象语言编程时总结下来的解耦经验，虽然大家说不要硬套设计模式，但是你不了解这些模式，你怎么随心所欲的设计。
你没有意识到设计模式的重要性。
不是，你不是程序员嘛？讲道理，编程是个经验技术活，怎么变成情感体验节目了？
我稍微能理解，你的想法了。
如果说，从加速实现，获取结果的角度考虑，所有的代码，都用别人定好的框架，设计模式，当然是好的。
但是你用别人的，总是要遵守别人的准则，就说耦合性问题， 设计要求高内聚低耦合。 你不去试试低内聚高耦合，你怎么明白个中滋味？ 我自己去试一遍，感受过了，是不是再来看看这些书，理解的就会多那么一点点？
我要表达的意思就是，编程应该注重的是，搭框架和写代码的过程，结果反而是附属品了，成功了是缘份，没成功吸取教训。 估计有人有我这个想法，中国大部分老板都要炒他鱿鱼。不过你要把你写的东西，当成自己儿子，没有人能说你对，说你错，只有合不合适。 你凭什么让别人来批判，你的表达？
你这，有点逗啊。
绝了。
我真是闲。
抱歉，打扰了。
把设计模式当圣经，不是每个程序员去看一遍，才能写好代码的。
好吧，稍微讲一下设计模式吧。
编程原本是没有所谓设计模式的，但是就像你这样，很早之前也有这么一个程序员遇到跟你一样的问题。在做项目的时候发现所有东西绑在一起不好，不灵活，后面的项目又要重头搞一遍，效率低，他就根据自己的经验，把代码重新梳理了一遍，解耦，分视图，逻辑，控制等模块，使得流程更加清晰，编程效率更高，这些都是根据经验来的。后来逐渐形成了一套理论，业内大牛把常用的一些模式总结成了一套理论，就是设计模式，23种设计模式不分语言不分环境，是一种编程思想。每一种语言又有比较经典的实现，比如JAVA里面讲设计模式，你直接看完之后再去实践，就会节省你大量摸索时间。同样creator里面到底适不适用设计模式，需要根据编程经验来自己判断，如果你经验不够，那就要去看看别人的，比如你先去熟读设计模式，为什么会有模式出现，不用模式行不行。当然你要自己摸索也没问题，本来这些东西也都是前人摸索出来的，你想自己搞一套，完全可以。
具体情况具体分析，首先都是为了解决问题。
相信有很多程序员最初并不知道设计模式是啥，然后在长久的码农生涯中，（看别人这么写，看老大这么写）稀里糊涂的学到了很多招式，后来又偶然听别人说设计模式，看了下百度的定义，咦，这些个设计模式不就是我之前用的某某方法吗
是的，都是为了解决问题来的
6666666原来如此
MVC模式大量用于WEB应用，难点在于状态管理。用来做游戏个人觉得也没任何问题，我们公司现在用的就是MVC模式。在状态管理部分，我们借用了react-redux封装了我们自己的creator-redux，单向数据流，状态决定游戏界面输出，每个模板，游戏区域都可以单独测试。只要上手了写起来就特别简单。
刚上班的时候，跟楼主一样，想着把逻辑ui完全分离，然后发现走入了一个死胡同，后来慢慢的就好了一点，感觉游戏 想要完全分分离逻辑和UI层，有时候反而很麻烦
楼主写的好诱人啊，搞得我也好想试试啊
好想认识楼主啊
哇 好久看不到有争论这么多的帖子了，楼主 ，咋写都能写，你这么写也没啥毛病，只不过你现在需要的是分解，分步去做。你感觉到的迷惑就是因为 想了一大堆 但是没有下手去写。其实下面评论的那些老哥们说的无论设计模式也好还是各种也好，都是好意，毕竟经过多年的总结出的模板都属于精华，但是我也同意说自己尝试的好处。说了这么多都是废话
其实，最重要的一环是数据的抽象，只有你把你要做的东西拆分到粒度很小的时候，然后根据一定的规则，你的经验来抽象成一个数据模型表示你要做的东西就好，然后剩下的ui以及逻辑，随你折腾。但是独立的数据抽象很重要，放到这里你的塔防游戏，塔就是你最重要的抽象，能把塔抽象好一个具体的数据model就好，同理适用于怪物，这里这两个最重要粒度也最合适的抽象好后，剩下的就是你怎么组织了，就是所谓的游戏逻辑。balbalbal等等，举个例子，你可以弄一个Game逻辑类，来把你的游戏主逻辑和控制放到这里，然后按照你想要的去写就好，也不需要一开始就把架构弄得太大 反而会让你迷惑，你就先把核心的数据和核心逻辑写好，然后去填充，填充的过程中你自然会有想法去优化之类的。自然而然就出来了，核心总结：数据的抽象，以及分解分布去做。
我觉得creator不用硬套MVC模式，在我看来脚本就是所谓的逻辑层控制界面上的UI，UI层不就用说了用编辑器拼出来，数据层自己定义的一个全局变量来管理就行了，不知道我这样理解对不对
元素模式了解下
ui 和logic之间的交互 是用消息通知还是状态监测啊
目前，游戏架构全部做完了，现在就是堆内容了。
跟你说的很类似，抽象了 一个 Game逻辑，和 塔 ，怪 和攻击方式 三个类， 通过组合 塔+攻击方式 /或者 怪+攻击方式 或者道具+攻击方式 组合出不同的逻辑状态 ， 逻辑状态与 场景现存 元素进行交互， 逻辑大概就是这样。 UI 这一块，全部做成分布式的， 怪物创造，怪物移动，怪物攻击，怪物死亡，塔创造，塔攻击。。。等等
其中通过传参形式，传入绑定的精灵，位置信息，行动目标，然后根据调用的API 去进行game逻辑反馈,中间不可避免的在UI里面有一个或多个BOOL值 ，反馈逻辑类，UI执行情况， 是否出现错误，需要重新生成，或者执行完毕等状态，反馈逻辑值。 因为逻辑类脱离了UI，前期代码时，发现数据跟UI完全不同步，然后不得不在UI里面触发逻辑反馈值，这个地方很难完全剥离。 通信方式，试过单例，不太好用，重新生成关卡清理数据 和 同步 不太好。用过单例，要在一个单例里面，调来调去的，也不舒服。 在父层 里面做，跟单例差不多，也很不舒服 ，找到 eventDispatch,很好用，但是发现，其实对主循环的开销很大， 这个玩意最后全部塞到了 Director的循环里面了。所以又改进了一下，做了一个 事件状态机， 就是传过去事件后，UI只管响应、不响应和无法响应 。 响应的是什么，在UI里面判断。就是只用了一个listener ，减少开销。
OK，我最后有去看了下MVC，发现了，在COCOS里实现 MVC是非常容易的，因为人家已经帮你把View解决了大部分， 通信机制也帮你预制了， 数据与逻辑 就剩下是自己的事了。感觉写的过程还是很爽的。 目前准备干的是，不用cocos的消息，开个线程，在线程里面处理消息的传递过程。 实践过程中，发现大量的内存碎片化问题，感觉不太好解决，目前没有好方法，UI层用cocos的retain release还行，逻辑层 完全不继承ref ，无法享用这个东西了，可能方法是用 malloc 2片内存，再动态的检测，互相倒换内存空间，应该可以解决，不过检测追踪的点，有点拿不准位置，要研究研究。
creator，是很挺好的，很方便。全局变量 单例 父节点 消息 都可以用来沟通，不必局限到底用啥啊
好的，有时间会去看，暂时找了本game programming patterns在看