流程设计的合理编程模式是什么

㈠ 编程模式是什么意思啊

模式这个概念被广泛使用。一位仁兄的文章中说，国外已经把模式这个概念推向日常生活中的许多领域。具体情况怎么样，我没有机会去考证，但是从西方人崇尚务实的精神推测，我想出现这种势头很合理。

我理解，模式是一种归纳整理已有经验的方式。比如设计模式，就系统整理了一些通用幽雅的设计经验。

作为程序员，”掌握某种技术”和”能合理地使用该技术解决实际问题”并不是一回事。前者偏向理论，后者侧重实践。前者得到人们的一致重视，而后者一直被忽略。我参与的项目中，经常出现这种情况，新加入项目组的程序员得不到这方面的培训，需要自己花费很大的精力来寻找使用特定技术实现特定应用的方式。这样降低了开发效率，使程序代码晦涩难懂，可读性差，而且代码隐藏BUG的几率大，影响了系统的稳定性和质量。而项目中经验丰富的程序员和编程高手们，掌握了大量的经验，但是这些经验都是个人技巧，很少拿出来交流。这种状况使高手们的编程方式各不相同，所以他们编写的代码可读性也不高。而且由于缺少系统的交流和整理，高手们的编程模式也难免存在一些不尽合理的地方，甚至可能潜伏了一些影响系统稳定性的错误步骤。我觉得有必要把这个问题提出来和大家讨论，论题就叫编程模式，希望能引起大家的关注。

把编程模式定义为：合理地使用特定技术解决实际问题的经验。编程模式这个概念应该被明确地提出来，在程序员间系统地交流、讨论、整理。每个项目组在编码之前，都可以归纳出一组针对自己开发环境的编程模式，要求程序员参考这些模式进行编码，质量检查人员以这些模式为标准进行质量检查。当然编程模式需要不断地补充和完善，这个不断改进的过程需要项目组所有人员的共同智慧。关注这个问题，我们的软件代码的质量和可读性将大大提高。我们就可以在软件开发水平上迈出踏踏实实的一步。

现在常被我们挂在嘴边的一个话题就是“印度软件业”，有人说它好，有人骂他烂，不过印度软件既然被国际社会承认，我想它在质量上应该还过得去。静下心来比较一下，印度和我们的主要区别之一在于软件业的基础——程序员。让一群印度程序员用同一种编程语言解决同一个问题，会发现他们的程序几乎一模一样，变量命名、程序结构、处理思路等就象是抄袭下来的，可以说他们在使用相同的编程模式。站在软件工程的角度看，所有的程序员都以相同的编程模式作为模板编码，是保证代码质量的一条途径，毕竟所有的软件系统都是建立再代码之上的，基础不牢，上层建筑再花哨也没有用。软件工程是一个侧重应用和实践的领域，国外的工程方法更多地来自实践经验，所以可操作性很强。但是传到国内以后就变味了，许多人更愿意把它抽象成纯理论去研究，最后出来的理论，只能看，不好使。

这或许还涉及到一个心态的问题，业内的气氛比较浮，有点急功近利。关注软件开发的基础问题,相信可以提高个人和整体的水平。

㈡ 编程模式指的是什么

各种网站上面最常见的就是23种设计模式
我就说几个好了，简单工厂模式，工厂模式，装饰者模式，责任链模式等等
我把别人的贴过来算了。。。

设计模式主要分三个类型:创建型、结构型和行为型。
其中创建型有：
一、Singleton，单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点
二、Abstract Factory，抽象工厂：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们的具体类。
三、Factory Method，工厂方法：定义一个用于创建对象的接口，让子类决定实例化哪一个类，Factory Method使一个类的实例化延迟到了子类。
四、Builder，建造模式：将一个复杂对象的构建与他的表示相分离，使得同样的构建过程可以创建不同的表示。
五、Prototype，原型模式：用原型实例指定创建对象的种类，并且通过拷贝这些原型来创建新的对象。
行为型有：
六、Iterator，迭代器模式：提供一个方法顺序访问一个聚合对象的各个元素，而又不需要暴露该对象的内部表示。
七、Observer，观察者模式：定义对象间一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知自动更新。
八、Template Method，模板方法：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中，TemplateMethod使得子类可以不改变一个算法的结构即可以重定义该算法得某些特定步骤。
九、Command，命令模式：将一个请求封装为一个对象，从而使你可以用不同的请求对客户进行参数化，对请求排队和记录请求日志，以及支持可撤销的操作。
十、State，状态模式：允许对象在其内部状态改变时改变他的行为。对象看起来似乎改变了他的类。
十一、Strategy，策略模式：定义一系列的算法，把他们一个个封装起来，并使他们可以互相替换，本模式使得算法可以独立于使用它们的客户。
十二、China of Responsibility，职责链模式：使多个对象都有机会处理请求，从而避免请求的送发者和接收者之间的耦合关系
十三、Mediator，中介者模式：用一个中介对象封装一些列的对象交互。
十四、Visitor，访问者模式：表示一个作用于某对象结构中的各元素的操作，它使你可以在不改变各元素类的前提下定义作用于这个元素的新操作。
十五、Interpreter，解释器模式：给定一个语言，定义他的文法的一个表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。
十六、Memento，备忘录模式：在不破坏对象的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
结构型有：
十七、Composite，组合模式：将对象组合成树形结构以表示部分整体的关系，Composite使得用户对单个对象和组合对象的使用具有一致性。
十八、Facade，外观模式：为子系统中的一组接口提供一致的界面，fa?ade提供了一高层接口，这个接口使得子系统更容易使用。
十九、Proxy，代理模式：为其他对象提供一种代理以控制对这个对象的访问
二十、Adapter,适配器模式：将一类的接口转换成客户希望的另外一个接口，Adapter模式使得原本由于接口不兼容而不能一起工作那些类可以一起工作。
二十一、Decrator，装饰模式：动态地给一个对象增加一些额外的职责，就增加的功能来说，Decorator模式相比生成子类更加灵活。
二十二、Bridge，桥模式：将抽象部分与它的实现部分相分离，使他们可以独立的变化。
二十三、Flyweight，享元模式

㈢ java 流程式代码适合什么设计模式

总体来说设计模式分为三大类：
创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
二、设计模式的六大原则
1、开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。
2、里氏代换原则（Liskov Substitution Principle）
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Bai 网络
3、依赖倒转原则（Dependence Inversion Principle）
这个是开闭原则的基础，具体内容：真对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（Interface Segregation Principle）
这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。还是一个降低类之间的耦合度的意思，从这儿我们看出，其实设计模式就是一个软件的设计思想，从大型软件架构出发，为了升级和维护方便。所以上文中多次出现：降低依赖，降低耦合。
5、迪米特法则（最少知道原则）（Demeter Principle）
为什么叫最少知道原则，就是说：一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（Composite Reuse Principle）
原则是尽量使用合成/聚合的方式，而不是使用继承。

㈣ MVC编程模式是什么

MVC模式：它是Java里面常用23的设计模式中的一种软件设计模式 MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分成三个层――模型层、视图层、控制层。 视图(View)代表用户交互界面，对于Web应用来说，可以概括为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具有挑战性。一个应用可能有很多不同的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。比如一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。

模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来说是黑箱操作，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计可以说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型做了进一步的划分，以便充分利用现有的组件，但它不能作为应用设计模型的框架。它仅仅告诉你按这种模型设计就可以利用某些技术组件，从而减少了技术上的困难。对一个开发者来说，就可以专注于业务模型的设计。MVC设计模式告诉我们，把应用的模型按一定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并没有提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提高重用性。我们可以用对象编程来做比喻，MVC定义了一个顶级类，告诉它的子类你只能做这些，但没法限制你能做这些。这点对编程的开发人员非常重要。

业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据保存（持续化）。比如将一张订单保存到数据库，从数据库获取订单。我们可以将这个模型单独列出，所有有关数据库的操作只限制在该模型中。

控制(Controller)可以理解为从用户接收请求, 将模型与视图匹配在一起，共同完成用户的请求。划分控制层的作用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，可以完成什么样的用户请求。控制层并不做任何的数据处理。例如，用户点击一个连接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型做什么，选择符合要求的视图返回给用户。因此，一个模型可能对应多个视图，一个视图可能对应多个模型。

㈤ 编程好的思路。

我认为编程，重要的不是如何华丽的代码，而是能够将用户需求转化为机器语言的能力
你的很多思想，是刚开始做程序员的普遍想法，开始思考通过模块化设计能够更省力，更快捷的完成工作，程序运行效率还要高。
如果你在大软件公司工作过，就不会有这种困惑了。因为对于具有一定规模的软件公司，已经在相当的时间内积累起很丰富的模块和库资源，程序员们只需要根据项目的不同象选择自助餐一样给拼接到一起，就有了基本框架。
最重要的还是做好用户需求到需求说明，再到系统框架设计这个工作，会少走很多弯路。
细化到编写程序，我觉得很重要的一点就是要求公司里面的程序员要有绝对规范的编程习惯，不然在团队协作的时候会出很多问题，做出来的基础库也经不起时间的考验。
还有就是你说的模块化的东西不是万能的，和你经常从事的项目领域密切相关，你用着很顺手，别人可能用不了。比如你是做信息系统的，那么一个好的查询分析模块很多地方都能用，用户信息管理就要根据复杂程度做几套，比如能够定期更换密码的，比如权限是要细化到列的，比如只是一个简单的用户密码。根据项目的不同选用。

有些人鼓吹自动化编程，利用商业化的系统模板进行配置。我认为对于企业应用还是可以的，但是对于软件开发就不可取了。因为提供模板的单位水平如何你并不知道，里面是否存在大量bug你也不清楚，只是演示做的漂亮。一旦你用了这个东西，在你的项目中出现问题，你debug是查不到具体原因的，苦果只能自己吃，这是个建议，有点离题，但是怕你思路到了一定程度就推崇这种方法。
最后一点，大部分的项目都是需要数据库作为后台支持的，一定要注意处理好数据库设计的问题，不然很容易因为库设计的不合理造成程序复杂，或者是在使用一段时间后效率严重降低，造成程序重新返工，就说这么多，希望你能有所收获

㈥ 形成良好的程序设计风格的原则是什么

形成良好的复程序设计风格的原制则是：

1、源程序文档化；

2、数据说明的次序规范化，说明语句中变量安排有序化，使用注释来说明复杂数据的结构；

3、程序编写要做到清晰第一、效率第二，先保证程序正确再要求提高速度，避免不必要的转移；

4、对所有的输入数据都要进行检验，确保输入数据的合法性。

(6)流程设计的合理编程模式是什么扩展阅读：

程序设计风格指一个人编制程序时所表现出来的特点，习惯逻辑思路等。 在程序设计中要使程序结构合理、清晰，形成良好的编程习惯，对程序的要求不仅是可以在机器上执行，给出正确的结果，而且要便于程序的调试和维护，这就要求编写的程序不仅自己看得懂，而且也要让别人能看懂。

随着计算机技术的发展，软件的规模增大了，软件的复杂性也增强了。为了提高程序的可阅读性，要建立良好的编程风格。

风格就是一种好的规范，当然我们所说的程序设计风格肯定是一种好的程序设计规范，包括良好的代码设计，函数模块，接口功能以及可扩展性等，更重要的就是程序设计过程中代码的风格，包括缩进，注释，变量及函数的命名，泛型和容易理解。