C# 软件开发模式、设计模式、设计原则和架构

admin管理员组

文章数量:1547087

一、怎样做好软件开发？

        软件是数据+算法的集合体，是利用一定方法将数据进行合理的组合和分配的产物。其实在人们的生活当中，处处都充满着资源(数据)和方法(算法)，成功的人都是善于使用他们总结的方法来使用资源的。软件开发也不例外，只用我们学习了一些语言并用我们总结好的方法来开发，我们就能轻松、高效、巧妙地设计出我们想要实现的软件。所以我们最需要注意的只有两点，1.学习一定的语言 2.掌握方法论(善于总结和利用方法)。

二、产品开发策略？

背景：在我们的软件开发过程中，往往会出现客户的要求变动，升级，使我们原本规划的设计和开发产生偏离，最后生产出的软件与客户想要的产品不符。客户需要在变动的过程中，可能需要重新设计和开发，这样使得软件开发效率慢、重复劳动多、开发成本变高、产品漏洞多不好维护等结果，这是客户和开发者都不能容忍和接受的。因此我们需要有一种开发策略，让开发变得高效，让客户的变化需求对软件开发影响变小，产品的MVP策略应运而生。

最小可行性产品MVP：是一种避免开发出客户并不是真正需要的产品的开发策略。是快速地构建出符合产品预期最小功能集合，通过迭代来完善，是让开发团队用最小的代价实现一个产品，以此最大程度上了解和验证对用户问题的解决程度。

      

 产品MVP要点：

1、以用户问题为中心，而不是以解决方案为中心

2、首先着眼于基本的客户要求，通过客户反馈，逐步修正产品设计和实现

3、在各个迭代过程中，做出的产品始终是可为用户所用的产品

三、主要的软件开发模式？

1、瀑布式开发(适合大型软件，需求明确且改动小)

2、敏捷型开发(适合小型软件，需求不明确且改动大)

瀑布式开发：及里程碑式开发模式，强调文档，强调分工，避免变化。缺点：1、阶段性的分工，让一部分人是一直处于等待状态，没有合理利用资源  2、需求变化，是开发者需要堆到重来，重复开发

敏捷型开发：发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。需要开发人员不局限与自己的专业分工，发挥每个人的力量让产品完善和尽快上线。

 

四、软件设计模式？

GoF的23种设计模式的功能：
前面说明了 GoF 的 23 种设计模式的分类，现在对各个模式的功能进行介绍。
单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
工厂方法（Factory Method）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。
代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。
装饰（Decorator）模式：动态的给对象增加一些职责，即增加其额外的功能。
外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
模板方法（TemplateMethod）模式：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。
 

五、软件设计七大原则(遵守原则是程序更安全、健壮、易扩展)

1. 单一职责原则（Single Responsibility Principle）
每一个类应该专注于做一件事情。一个类改变，不会影响其他类，便于维护。

2. 开闭原则（Open Close Principle）
面向扩展开放，面向修改关闭。源代码不改变，只是实现它的扩展，减少代码审查和测试。

3. 里氏替换原则（Liskov Substitution Principle）
类可以扩展父类的功能，但不能改变父类原有的功能。

4. 依赖倒置原则（Dependence Inversion Principle）
实现尽量依赖抽象，不依赖具体实现。

5. 接口隔离原则（Interface Segregation Principle）
应当为客户端提供尽可能小的单独的接口，而不是提供大的总的接口。

6. 迪米特法则（Law Of Demeter）
又叫最少知识原则，一个软件实体应当尽可能少的与其他实体发生相互作用。

7. 组合/聚合复用原则（Composite/Aggregate Reuse Principle CARP）
尽量使用合成/聚合达到复用，尽量少用继承。原则： 一个类中有另一个类的对象。

六、软件的架构？

1、单体架构

2、垂直/水平拆分架构

3、分布式架构

4、微服务架构

其他：Service Mesh，Cloud Native，Serverless

单体架构：全部功能都集中在一个项目内
优点：架构简单，前期开发成本低、开发周期短，适合小型项目 
缺点：1.不利于开发、扩展、维护 2.项目之间功能冗余、数据冗余、耦合性强

垂直/水平拆分架构：功能模块拆分，独立部署

优点：功能模块独立部署，互不影响

缺点：1.重复工作增多 2.存储复杂性增多 3.开发成本增加

分布式架构：将一个大的系统划分为多个业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间通过接口进行数据交互。数据库也大量采用分布式数据库，如redis、ES、solor等。通过LVS/Nginx代理应用，将用户请求均衡的负载到不同的服务器上。

优点：1.降低了耦合度,把模块拆分,使用接口通信,降低模块之间的耦合度  2.责任清晰,把项目拆分成若干个子项目,不同的团队负责不同的子项目  3.扩展方便,增加功能时只需要再增加一个子项目,调用其他系统的接口就可以 4.部署方便,可以灵活的进行分布式部署
缺点：1.系统之间的交互要使用远程通信,接口开发增大工作量 

 

微服务架构：主要是中间层分解，将系统拆分成很多小应用（微服务），微服务可以部署在不同的服务器上，也可以部署在相同的服务器不同的容器上。当应用的故障不会影响到其他应用，单应用的负载也不会影响到其他应用。

优点：1.易于开发和维护,一个微服务只会关注一个特定的业务功能，所以它业务清晰、代码量较少。2.局部修改容易部署,单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。 一般来说，对某个微服务进行修改，只需要重新部署这个服务即可 3.技术栈不受限 4.可以针对不同服务制定对应的优化方案 5.适用于互联网时代，产品迭代周期更短
缺点：1.粒度太细，导致服务太多，运维要求较高  2.复杂性增多，开发的技术成本高，对团队的挑战大

 其他架构：待补充！！！

参考：

GoF32设计模式：使用c#实现23种常见的设计模式 - 知乎

软件架构：四种软件架构，看看你属于哪个层次 - 简书 

本文标签： 模式架构原则软件