程序设计模式浅析（plain framework商业版设计模式）

程序设计其实对程序开发者来说十分重要，但是在工作中往往我们却忽略了这一块，因为我们所用的都是现有的模式。一个设计模式的好坏，往往能够体现出程序的专业性，还有整个项目的可持续性。这就是为什么有些公司，在经历了若干年后忽然重写整套代码的原因，因为他们会发现在越来越多的需求的情况下，以前那些设计模式完全不能满足了，或者说程序的复杂度和维护成本实在太高。最近我又看到了一个公司的项目设计，文档中写的还算优秀，可是整体的框架设计总觉得还有差强人意。那么我们又该怎样来设计我们的程序，怎么减少维护代码的成本，怎样使框架能够满足不断增添的新需求或技术？设计模式是一个老生常谈的问题，而且有些技术员将其神乎其能，作为一个出来也有几年的人来说，我也很感谢网络上许多朋友无私的知识分享，所以基于plainframe work（简称PF）的开源精神，就算是做成了商业版，我也将对接下来的设计模式完全公开的分享给大家。

什么是设计模式？

　　设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的；设计模式使代码编制真正工程化；设计模式是软件工程的基石脉络，如同大厦的结构一样。（这段来自百度百科）
　　一句话设计模式的产生和应用主要是方便代码的管理，以及节省维护的复杂成本。

现有的模式

　　最近进入一家公司，该公司主要进行页游方面的开发，据说有一款比较不错的产品。抱着去学习的心态，那是因为自己觉得技术还要需要不断的提高，还有就是别人的成功是否和技术有着直接的关系。因为来的日子并不太长，所以只能简单看到一些脚本层的东西，其脚本也就是大家所熟知的lua了。只不过在脚本层，他们进行了一些简单的封装，如自己写的加载文件的接口等。不过他们似乎很聪明的把lua的扩展名改为.txt，这么别人一眼就不能看出这是一个lua脚本了。其次再看脚本的结构，我只是粗略的看了下，分为几个目录场景、配置目录、方法目录。乍看之下，目录层次还是比较分明的，可是如果要找寻某个系统对于刚看不到一天的我来说还是觉得十分吃力。一是服务端没有详细的目录介绍，似乎大家的开发很随意，那个模块需要你十分熟悉了才能找得到。二是脚本调用结构不分明，调用C++和自身的一些方法没有一定的区分。最后说一点的就是，如果你需要找寻某个功能就需要问熟悉的同事，或者你需要将里面的代码重新梳理一次不可，而且注释极少，你很难看到那里是真正你应该去修改或是增加。看了这些后，对于赚钱的项目就有好的技术，我一下子就彻底的明了了。
　　鉴于上面的原因，很多的开发者才那么觉得应该进入技术较好的公司，诸如网易腾讯之流来提升自己。而且从这些公司流传出来的代码，可谓成为大家手头上觉得十分厉害的香饽饽。其实麻烦是自己造成的，如果大家懂得合理运用比较好的设计模式，那么你也不必去羡慕那些技术很牛的公司或是人。作为一个开发者，大家并没有太大的区别，而且技术又是在每天在进步，旧的技术很可能会在下一刻更换，那么这个时候人人的机会都是平等的。
　　一种好的开发模式，必然会对今后的发展有着很大的帮助，如果你想要达到更高的层次的话，对于一名开发者，你就需要全面的去了解设计模式。现在市面上用的比较多的是工厂模式以及MVC的思想，工厂模式这是一个很古老的东西，在这里就不详谈了。而之所以将MVC称之为思想，那是因为早先这个模式是用在网页开发上的，特别是在一些大型语言JSP、.NET.ASP、PHP上。简单说一下在网页设计的三个东西：数据的处理（MODULE）、逻辑的处理（CONTROL）、界面的显示（VIEW），在WEB开发中一开始人们几乎是将这三者糅合在一起来做的，这样代码的可读性和重用性非常之不好。所以有人就这样将各自的分工独立开来做，就像早期的资本主义里的公司体系一样，没有统一的管理，分工非常不明确，效率非常之低。在网页中数据的处理一般指的是读写数据库的操作，逻辑的处理主要处理从用户操作所返回的一个系统的请求，比如说登陆这些，需要处理验证密码、处理注册这些操作，而界面的显示主要负责客户端界面上可以直接看到的东西。
　　MVC的思想现在已经广泛的用在了各种设计上，包括在客户端也会用到这个思想，只不过数据的处理这块变成了内存的读写而已。不过对于MVC个人的理解是，它充分体现了面向对象的设计，更趋于人性化的管理。

　　MVC基本的思想：

　　除了工厂模式和MVC的思想，其实现有的模式还有很多，我在这里就不一一举例了。

我们需要一点改变　　

　　任何设计模式都有其局限性，这里称之为改变的，其实是指不要生搬硬套模式的思想。在设计的过程中，我们往往要这样想：这样设计可行吗？这样设计复杂吗？这样设计有没有后遗症？
　　弄清了三面的几个问题后，我们再来说目录结构的设计，目录结构尽量的层次分明，但是目录嵌套的层数尽可能的少，最好的设计目录的嵌套最好不好超过五级目录。因为太多的嵌套，会将整个目录看起来比较复杂，有的时候我们宁可使用文件前加前缀来做，如opencode_style.h、opencode_view.h这样，而不是将其分成目录（当前其前提是目录层级已经是第五层了）。
　　再来我们说说接口的设计，接口的设计看起来简单，因为他用不着关心怎么实现，可是从深一层来说，接口设计其实并不简单。在一些比较大型的企业里，接口的设计并不是一般程序可以随便能接触的，而是由专人去负责这个东西，而且这样的人，在公司内来说是有一定的技术的（称之为大牛）。接口设计的重要性，主要是它是不是更灵活，是不是可以方便的扩展，是不是有更好的复用性？如果一个接口都同时满足了这三点，那么这样的接口算是比较好的了。用通俗的话来说，接口主要是看能否在以后能够继续使用，就算出现了新的技术，这个接口是否可以灵活的适应。
　　最后说一下具体的代码设计，尽量将逻辑的处理与数据分离，尽量将消息的处理单独的放到一个地方统一进行。

PF商业版核心人员招募

开篇语
　　我们没有大神，只有解决问题的人。
　　我们没有强悍的技术，只有一颗向往简单的心。
　　我们没有惊人的理论，只有一堆不可思议的妄想。
　　我们不需要复杂，只需要够简洁。
　　我们不需要固定的思维，只需要你能想得到。

核心成员资格需求
　　1、精通或熟练掌握一门语言
　　2、能够接受和遵从谷歌C++代码风格
　　3、灵活而大胆的思考问题
　　4、能够在规定时间段内完成自己分配的模块（可以灵活调度）
　　5、有坚持不懈的动力（很重要）

核心成员项目优势
　　1、无限制的使用商业版到自己的项目中，如果是别的项目则需要和所有成员商量
　　2、在过程中，你可以得到飞一般的技术提高
　　3、商业版如果有盈利核心成员的利益将会最大

　　名额有限，如果大家想加入的话，请发送一段自己熟悉的语言利用plain framework（简称PF）风格的代码到邮箱viticm.ti@gmail.com，我们将尽快的在15年前确定人选，因为商业版的计划从15年1月份开始。

PF托管地址

　　https://github.com/viticm/plainframework1

PF安装教程

　　http://www.cnblogs.com/lianyue/p/3974342.html

PF交流QQ群