571
社区成员




软件工程是指导计算机软件开发和维护的一门工程学科,采用工程的概念、原理、技术和方法来开发和维护软件,把经过时间考验而证明正确的管理技术和当前能够得到 的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它。
软件工程专业是以计算机科学与技术学科为基础,强调软件开发的工程性,借鉴传统工程的原则、方法,以提高质量、降低成本。使学生在掌握计算机科学与技术方面知识和技能的基础上熟练掌握从事软件需求分析、软件设计、软件测试、软件维护和软件项目管理等工作所必需的基础知识、基本方法和基本技能,突出对学生专业知识和专业技能的培养,培养毕业后能够在IT行业、科研机构、企事业中从事软件开发、测试、维护和软件项目管理的高级软件工程技术人才。
作为一名刚刚系统地学习完一门编程语言和开发框架的学生,如何尝试进行项目开发,如何对软件开发过程中的问题进行关注和了解,怎么样的软件才是优秀的软件?这些问题曾经对我来说都是摸不着头脑的。孟宁老师的高级软件工程课程,让我对个人,团队的开发过程,以及软件工程这一学科有了一个系统的认识。这门课的覆盖面较为广泛,编写代码的必备工具与技能,到代码编写的规范;从底层的CPU、编译器、内存模型到高层的模块化、微服务的思想及设计模式……对大大小小的问题都进行了一系列的说明。
软件浓缩了人类的智慧,是人类智慧的结晶;是一个复杂易变的,迭代快速的,不稳定的工程。使得我们在抽象的基础上建立逻辑模型的努力,永远达不到终点,难以达成软件概念上的完整性和一致性。那么如何让我们设计出的软件更加标准化、工程化,让我们的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强,拥有更长的使用周期?这就是设计模式可以解决的问题。
设计模式是在某一情景下的问题解决方案。设计模式的本质是面向对象设计原则的实际运用总结出的经验模型。是对类的三大特性:封装、继承、多态性以及类的关联关系和组合关系的充分理解和熟练运用的结晶。
一般由四个部分组成
设计模式的名称
设计模式的目的
该设计模式的解决方案
该设计模式的解决方案有哪些约束和限制条件
可以提高程序员的思维能力、编程能力和设计能力。
使程序设计更加标准化、代码编制更加工程化,使软件开发效率大大提高,从而缩短软件的开发周期。
使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。
设计模式的分类标准主要有两个
根据模式是主要用于类上还是主要用于对象上
可分为类模式和对象模式两种类型的设计模式
类模式:用于处理类与子类之间的关系,这些关系通过继承来建立,是静态的,在编译时刻便确定下来了。
对象模式:用于处理对象之间的关系,这些关系可以通过组合或聚合来实现,在运行时刻是可以变化的,更具动态性。
根据设计模式可以完成的任务类型来划分
可以分为创建型模式、结构型模式和行为型模式 3 种类型的设计模式
创建型模式
用于描述“怎样创建对象”,它的主要特点是“将对象的创建与使用分离”
结构型模式
用于描述如何将类或对象按某种布局组成更大的结构
行为型模式
用于描述程序在运行时复杂的流程控制,即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务。
常见的创建型模式
单例模式
某个类只能生成一个实例,该类提供了一个全局访问点供外部获取该实例。
原型模式
将一个对象作为原型,通过对其进行复制而克隆出多个和原型类似的新实例
建造者模式
将一个复杂对象分解成多个相对简单的部分,然后根据不同需要分别创建它们,最后构建成该复杂对象。
常见的结构型模式
代理模式
为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象,从而限制、增强或修改该对象的一些特性。
适配器模式
将一个类的接口转换成客户希望的另外一个接口,是的原本由于接口不兼容而不能一起工作的那些类能一起工作。
装饰模式
在不改变现有对象结构的情况下,动态地给对象增加一些职责,即增加其额外的功能。
外观模式
为复杂的子系统提供一个一致的接口,使这些子系统更加容易被访问。提供类似“视图”的功能。
享元模式
运用共享技术来有效地支持大量细粒度对象的复用。比如线程池、固定分配存储空间的消息队列等往往都是该模式的应用场景。
常见的行为型模式
策略模式
定义了一系列算法,并将每个算法封装起来,使它们可以相互替换,且算法的改变不会影响使用算法的客户。
命令模式
将一个请求封装为一个对象,使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行,方便将命令对象进行储存、传递、调用、增加与管理。
模板方法模式
定义一个操作中的算法骨架,而将算法的一些步骤延迟到子类中,使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
职责链模式
为了避免请求发送者与多个请求处理者耦合在一起,将所有请求的处理者通过前对象记住其下一个对象的引用而连成一条链;当有请求发生时,可将请求沿着这条链传递,直到有对象处理它为止。通过这种方式将多个请求处理者串联为一个链表,去除请求发送者与它们之间的耦合。
中介者模式
定义一个中介对象来简化原有对象之间的交互关系,降低系统中对象间的耦合度,使原有对象之间不必相互了解。如在 MVC 框架中,控制器(C)就是模型(M)和视图(V)的中介者。
观察者模式
指多个对象间存在一对多的依赖关系,当一个对象的状态发生改变时,把这种改变通知给其他多个对象,从而影响其他对象的行为,这样所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式。
开闭原则
“软件应该对修扩展开放,对修改关闭”。
遵守开闭原则使软件拥有一定的适应性和灵活性的同时具备稳定性和延续性。软件结构模型本质上具有不稳定性,因此开闭原则在基本需求稳定且被充分理解的前提下才具有一定的价值。
Liskov 替换原则
“子类可以扩展父类的功能,但不能改变父类原有的功能”
主要阐述了继承用法的原则,也就是什么时候应该使用继承,什么时候不应该使用继承:
依赖倒置原则
“高层模块不应该依赖低层模块,两者都应该依赖其抽象”
其核心思想是:要面向接口编程,不要面向实现编程。由于在软件设计中,细节具有多变性,而抽象层则相对稳定,因此以抽象为基础搭建起来的架构要比以细节为基础搭建起来的架构要稳定得多。依赖倒置原则在模块化设计中降低模块之间的耦合度和加强模块的抽象封装提高模块的内聚度上具有普遍的指导意义。
单一职责原则
“一个类只负责一项职责”
单一职责原则的核心就是控制类的粒度大小、提高其内聚度。符合模块化设计的高内聚低耦合的设计原则。
迪米特原则
“只与你的直接朋友交谈,不跟“陌生人”说话”
如果两个软件实体无须直接通信,那么就不应当发生直接的相互调用,可以通过第三方转发该调用。其目的是降低类之间的耦合度,提高模块的相对独立性。
合成复用原则
“在软件复用时,要尽量先使用组合或者聚合关系来实现,其次才考虑使用继承关系来实现”
参考资料 代码中的软件工程