软件模块化设计原则_软件框架设计的艺术
本文关键词：软件框架设计的艺术，由笔耕文化传播整理发布。
软件框架设计的艺术----读书总结
总结 软件开发的艺术 理想主义，经验主义和无绪
文艺复兴时期，现代科学产生了两个重量级理论： 理性主义和经验主义。
理性主义认为理智是信息的首要来源。给出一个假设，只要通过思考就能理解和描述这个世界，如著名的伽利略自由落体实验。
经验主义则认为人类对世界认识的主要来源是经验。
我们开一辆车，不必知道其内部实现细节。
如果孤立地基于两种极端的方式来观察世界都是片面的。对大多数人来说，懵懂无知是一种生活方式，也是理性主义和经验主义结合在一起的结果。今天的程序开发和软件工程方法也是如此。
软件的演变过程我们可以发现在软件演变的过程中， 理性主义几乎已无存身之处。
因为软件的趋势是： 程序员在可以不深入了解很多内容的情况下就可以写出非常好的代码。
大型软件是如何开发的现状: 开发团队往往直接复用现有的一些软件框架，完全不重视这些重量级的框架是否超过我们的需要的。现代软件都是基于大型组件的方式进行组装的。 我要一个web服务器就装一个tomocat, 要一个数据库就装个mysql。 这完全是一种推土机式的开发方式，，不管你的组件有多大， 总会找到合适的推土机把他推上去。 运行效率太差 就 加内存，搞服务器集群，
这种方法是好还是坏呢？实际上绝大多数公司已经用这种方式了。
因为推土机式的工作方式可以使你在不关注内部细节的情况下，也可以得到不错的结果。 我们可以在不了解汽车原理的情况下，可以把汽车开得很好。 在写win32程序时候，也不必了解系统是怎么实现。 我们只需要关注windows 系统API， 以及这些API的功能。
理解一个系统有两个层面：
而在软件开发中， 一般只要做到浅层理解就可以了。
我们说明软件开发其实是一个经验的积累过程，并且可以是复用前人的经验积累的。
设计API的动力之源好的API可以使功能的使用者聚焦在使用层面而不是其内部细节
为什么需要好的API:
设计API过程中遇到的最大问题--- 不断变化的需求一个软件开发的生命周期：
变化是万恶之源。
那么如何才能设计好的API 评价API好坏的标准第一步先确认什么才叫好。
很多人认为所谓的API，不过是类和方法。但是这是比较片面的。
强调一点， 我们为什么需要开发好的API:我们希望能够将大块的构建模块，”无绪“地集合成应用程序。
那么如何评价一个API的质量： 漂亮？ 但是评价漂亮的标准是很主观的。我们应该设计易于使用、广为接受且富有成效的API。我们可以有一下几个方面来衡量一个API的好坏。
实现API的步骤第二步弄清楚写API的步骤
写一个API有三个步骤：用例， 场景， 文档。
一个用例就是一种用法的描述，他指出用户可能要面临的问题，而这个问题不是一个具体的问题，而是很多问题的抽象。
举个例子
用例： 设计一个数据库管理器，他的功能是注册JDBC驱动。
场景：对用例的回答。我们把API要描述的每一个功能下列出来：
注意一些设计原则第三步 学习一些设计原则和通用方法
只公开你要公开的内容我们所设计的API都会被可能误用。几乎所有的API设计者都会有这样的共识：一个人API设计的时间越长，他设计的API公开的内容会越少。
设计API的几种方法：
1. 方法优于字段这个不用说了。 geter setter。 这样做会有很多改变的余地。 如计算、转换、校验、覆盖
2.工厂方法优于构造函数工厂方法会带来很大的灵活性，三个好处：
3. 让所有的内容都不可改变通常情况下， 在设计一个类的时候，如果不考虑让拥有子类，那就不应该让这个类被继承。 用final 来修饰。 还有些其他方案来： 不公开构造函数转而提供工厂方法。把大部分方法变为final或者private
4. 避免滥用setter方法一个宝贵的教训： 如无必要，绝对不要再正式的API中声明setter方法。
5. 尽可能通过友元的方式来公开功能在java中，所谓的友元就是用默认的package方式访问，即允许同一个包内的代码进行访问。
有个实际的例子
6. 赋予对象创建者更多的权利 7. 避免暴露深层次继承避免深层次的继承，定义程序的接口，并让用户来实现这些接口。 如果一个类继承了某个类或者接口，那么就可以作为响应的类或接口被使用。
如在swing中， frame间接继承了compoment，这样就表示所有使用compoment的地方，都可以使用frame. 实际上frame继承 compoment是为了复用compoment的代码。这是一种典型的面向对象的复用的误用。 所以如果发现继承提醒超过2层，一定要想清楚“我是在设计API还是在复用代码”，如果是后者，则做好子类化准备。
面向接口而非实现进行编程本质上讲，这个原则倡导的是，当我们写一个函数或一个方法时，我们应该引用相应的接口，而不是具体的实现类。接口提供了非常优秀的抽象归纳，让我们的开发工作变得容易很多。 让API的使用者和API的实现者解耦出来。
模块化架构随着软件规模的增大以及功能的复杂性增加。只要代码开始访问其他无关模块的内容，那么架构的退化不可避免。模块化能有效变缓这种退化。
模块化的目的非常简单，就是要实现程序中各个组成部分的松耦合。如果两个模块是独立的，那两个模块就不需要知道对方的存在。如果两个模块要交互，那么他们应该通过具有良好定义的接口来进行交互。
声明式编程声明式编程的基本思路， 不是让API用户一步一步告诉程序如何做，而只是需要告诉程序他们要的结果，然后交给API去完成。声明式编程的好处是能在较高的抽象层次来定义操作。
比如写一个资源管理API： API的使用者很容易找到一个方法去注册一个功能，运行一下成功了，然后不再往下继续找注销的方法了。 声明式编程就是解决这个问题的一剂良药： 开发人员只需要声明注册什么，响应的注销和清理由系统完成。
极端的意见有害无益最后提醒一点，任何极端的想法都是有害的，在软件框架设计中也一样， 有以下单不仅限几个点：
团队协作现代的大型工程很少是有一个人单独开发完成的，所以团队协作非常重要。一下几个点能很好帮助在大型软件工作中完成好的API设：
以上非常简单，但是在外面平常工作中缺少的就是执行。
posted @
本文关键词：软件框架设计的艺术，由笔耕文化传播整理发布。
本文编号：175783
本文链接：https://www.wllwen.com/wenshubaike/mishujinen/175783.html
