|
|
|
|
|
|
|
- 上次的设计太糟糕了，痛下决心以后要好好设计
- 再次进行软件设计时却不知道该怎样设计
- 思考了很多，不知如何下手
- 需求一变更，重新回到了糟糕的状态
- 软件的质量保证：内部质量与外部质量
- 高质量软件设计的标准：易读、易于维护、易于变更
|
|
|
- 规范代码、编写注释与表明动机
- 领域驱动设计
- 互联网+带来的挑战
- 系统需要不断地技术升级与改造
- 传统行业必须向互联网转型
- 但技术变革不是换零件那么简单
- 剖析应对技术变革的方案
- 低耦合
- 依赖反转原则（DIP）
- 开放-封闭原则（OCP）
- 里氏替换原则（LSP）
- 高内聚
- 单一职责原则（SRP）
- 信息专家模式
- 不要重复自己原则（DRY）
- 设计模式的由来
- 设计模式的发展
- 设计模式对高质量软件设计的作用
|
|
|
|
|
- 软件设计中外部接口的难题
- 第三方框架带来的设计难题
- 适配器模式及其概念
- 适配器模式解决第三方框架带来的难题
- 适配器模式解决外部接口的设计难题
|
|
|
- 工资发放功能遇到的难题
- 工资发放功能最初的设计及其问题
- 对问题的分析过程及其新的设计思路
- 策略模式及其概念
- 案例：工资发放功能设计改进的过程
- 工资发放功能的Java实现
- 工资发放功能的C++实现
- 案例：数据导出功能的设计实现
- 深入理解开放-封闭原则
- 数据导出功能的变更与改进过程
- 案例：财务凭证生成功能的设计过程
- 财务凭证生成功能的初始需求与设计
- 财务凭证生成功能的扩展与分析过程
- 财务凭证生成功能的最终设计
- 深入理解单一职责原则
- 学习“两顶帽子”的设计方式
|
|
|
- 依赖反转原则的设计难题
- 开放-封闭原则的设计难题
- 探讨工厂模式的本质
- 简单工厂模式的C++实现
- 基于配置的简单工厂模式
- 剖析简单工厂如何实现依赖反转原则
- 解读工厂模式对设计的重大意义
- 讲解如何创建一个工厂
- 创建工厂的步骤与关键点
- 利用Spring框架简化工厂类的设计
- 工厂方法模式的概念
- 工厂方法模式的应用
- 抽象工厂模式的概念
- 抽象工厂模式的实现
- 最初的标签库设计
- 运用简单工厂的标签库设计
- 运用工厂方法的标签库设计
- 运用抽象工厂的标签库设计
- 最终基于配置的标签库设计
|
|
|
- 设计工厂类面临的问题
- 单例模式及其概念
- 如何实现单例模式
- 单例模式带来的设计变革
- 充血模型vs.贫血模型
- 探讨单例模式与性能问题
- 单例模式改变了很多软件的设计
|
|
|
- 工厂类在提供产品时遇到的设计问题
- 原型模式及其概念
|
|
|
- 煮咖啡给我们的启示
- 设计工厂类的新思路
- 模板方法模式及其概念
- 重复代码带来的严重后果
- 散弹式修改及其解决思路
- 探讨实现代码复用的难题
- 代码复用在不同场合采用的方法
- 模板方法模式在代码复用中的作用
|
|
|
- 业务量增长带来的多数据源问题
- 运用装饰者模式巧妙解决多数据源问题
- 装饰者模式及其概念
- 多数据源问题的分析设计过程
- 多数据源的设计与实现
- 商城收银系统期初的设计
- 混合策略的设计与实现
- 多层装饰者的设计与实现
- 透明的功能扩展
- 里氏替换原则
|
|
|
- 对象继承的泛滥
- 桥接模式及其概念
- 员工管理与工资发放带来的继承泛滥问题
- 采用桥接模式的设计与实现
- 查询支持类遭遇的继承泛滥问题
- 查询支持类的解决方案
- 单例模式下查询支持类的设计
|
|
|
- Hibernate是怎样访问数据的
- 享元模式及其概念
|
|
|
|
|
|
|
|
|
|
|
- 程序代码越来越乱
- 软件维护成本越来越高
- 软件变更越来越困难
- 无法进行新技术的改造
- 头痛医头，脚痛医脚
- 抛弃掉重新编写
- 因担心未来变化而做的过度设计
- 团队成员越来越多但效率却越来越低
- 测试变得越来越困难而任务繁重
- 软件系统越来越笨重而不适应未来变化
- 起初的设计
- 随后的变更
- 质量不断下降的过程
- 软件总是因变更而变得越来越复杂
- 软件结构已经不再适应复杂的软件需求
- 必须要调整软件结构以适应新的软件需求
- 重构原有代码以适应新的需求
- 实现新的需求
|
|
|
- 低耦合
- 依赖反转原则（DIP）
- 开放-封闭原则（OCP）
- 里氏替换原则（LSP）
- 高内聚
- 单一职责原则（SRP）
- 信息专家模式
- 不要重复自己原则（DRY）
- 演示以往软件设计的过程
- 剖析以往软件设计的问题与风险
- 用最快的速度开发一个最核心的功能
- 让第一个版本运行起来并可以验证
- 在第一个版本的基础上不断添加功能：
- 每次只添加一个很简单、很单一的功能
- 每次以两顶帽子的方式添加新功能
- 运行、调试与验证
- 重复这个过程添加下一个功能
- 复杂的系统就是由一次次正确开发的不断积累而成
- 复杂功能有效地解耦
- 代码编写总是可测试与验证
- 简化设计与思考的复杂度
- 适时重构以避免软件退化
|
|
|
|
|
- 重构是一系列代码的等量变换
- 重构的保险索：自动化测试
- 软件修改的四种动机——重构的价值
- 一个真实的谎言——重构的误区
- 重构的主要方法与技巧
- 重构第一步：分解大函数
- 重构第二步：拆分大对象
- 重构第三步：提高复用率
- 重构第四步：可扩展设计
- 重构第五步：降低耦合度
- 重构第六步：系统分层
- 重构第七步：领域驱动设计
- 最初的领域驱动设计过程
- 需求变更的领域驱动设计
- 面向物联网的架构演进
|
|
|
- 重构是一种习惯
- 重构让程序可读
- 重构，才好复用
- 先重构，再扩展
- 紧急任务时的重构
- 重构初期的困局
- 解耦与自动化测试
- 建立自动化测试体系
- 评价软件质量的指标
- 评价软件质量的工具
|
.png)
收藏人
会议介绍
会议日程
（最终日程以会议现场为准）
会议嘉宾
（最终出席嘉宾以会议现场为准）
参会指南
您可能还会关注
会员折扣
该会议支持会员折扣
