第三阶段学习目标理解常见的软件设计问题以及如何使用抽象、组合、接口和多态控制复杂度。核心思想不要背设计模式要理解“为什么需要这种设计”。目录1. 设计模式到底解决什么2. 第一原则组合优于继承3. Strategy策略模式4. Factory工厂模式5. Adapter适配器模式6. Facade外观模式7. Observer观察者 / 事件模式8. Command命令模式9. State状态模式10. Dependency Injection依赖注入11. 设计模式真正应该学习什么12. 设计模式的反模式13. AI Coding 中如何使用设计模式14. 本阶段最终能力1. 设计模式到底解决什么设计模式不是为了让代码显得高级。它解决的是反复出现的软件设计问题需求变化 ↓ 代码结构开始复杂 ↓ 找到变化点 ↓ 隔离变化 ↓ 减少影响范围所以设计模式与前面的“高内聚、低耦合、封装变化”是一脉相承的。2. 第一原则组合优于继承不要看到不同类型就马上建立复杂继承树。很多时候继承容易形成强耦合。而组合更灵活。例如ModelService ├── Loader ├── Cache ├── CoordinateTransformer └── LoggerModelService 通过组合获得能力。3. Strategy策略模式适合同一个业务流程存在多个可替换算法 / 实现。例如 GIS 模型加载ModelLoader ├── OSGBLoader ├── Tiles3DLoader ├── GLTFLoader └── OBJLoader上层只依赖ModelLoader4. Factory工厂模式适合创建对象的逻辑比较复杂或者创建过程需要根据类型选择实现。例如createModelLoader(type)根据osgb 3dtiles gltf返回不同 Loader。注意简单对象不要为了“设计模式”强行使用 Factory。5. Adapter适配器模式适合两个接口不兼容但你希望它们能够协作。例如你的业务接口 ↓ ModelLoader ↓ 第三方 GIS SDK如果第三方 SDK 的接口与你的业务接口不同可以通过 Adapter 转换。6. Facade外观模式适合一个复杂系统对外只需要暴露一个简单入口。例如GISFacade内部SceneManager ModelManager TerrainManager CameraManager CoordinateService外部只需要gis.loadProject()7. Observer观察者 / 事件模式适合一个事件发生后多个模块需要响应但不希望它们互相直接依赖。例如ModelService ↓ model:loaded ↓ ┌──────────┬──────────┐ ↓ ↓ ↓ UI Logger SceneManager非常适合Electron前端状态变化GIS 场景事件异步任务8. Command命令模式把“一个操作”封装成对象或独立命令。例如LoadModelCommand RemoveModelCommand MoveModelCommand适合进一步实现UndoRedo操作记录批量执行命令队列GIS 编辑类软件尤其值得理解。9. State状态模式当一个对象的行为会随着状态变化而变化时可以显式建模状态。例如Model ├── Idle ├── Loading ├── Loaded ├── Failed └── Disposed这比到处使用isLoading isLoaded isError更容易控制复杂度。10. Dependency Injection依赖注入核心思想不要让一个模块自己决定所有依赖。例如不推荐ModelService ↓ new CesiumModelLoader()可以考虑ModelService ↓ ModelLoader然后外部注入ModelService(loader)这样测试时可以传FakeModelLoader从而降低耦合、提高可测试性。11. 设计模式真正应该学习什么不要记Strategy 策略 Factory 工厂 Observer 观察者而要记什么问题 ↓ 什么变化 ↓ 哪里耦合 ↓ 如何隔离例如为什么使用 Strategy不是因为“Strategy 是经典设计模式。”而是因为这里有多个可替换算法而且未来可能继续增加。12. 设计模式的反模式常见错误简单问题 ↓ 硬套设计模式 ↓ Factory AbstractFactory Strategy Adapter ↓ 代码复杂度暴涨最终设计模式解决的问题比原来的问题还复杂。所以应该遵循先有问题再有模式。13. AI Coding 中如何使用设计模式不要问“这里帮我用设计模式优化。”更好的问法当前代码存在多个模型格式。 请分析 1. 这些实现有哪些变化点 2. 是否存在高耦合 3. Strategy / Factory / Adapter 哪种更适合 4. 是否真的有必要引入设计模式 5. 最简单的方案是什么这会训练你的设计判断能力。14. 本阶段最终能力能够看到一个问题时自然思考这里什么会变化 ↓ 能不能封装 ↓ 能不能通过接口隔离 ↓ 能不能通过组合降低耦合 ↓ 有没有必要使用某种设计模式最终目标不是会背设计模式而是会识别设计问题。
3.《设计模式》：软件设计与解耦能力提炼
第三阶段学习目标理解常见的软件设计问题以及如何使用抽象、组合、接口和多态控制复杂度。核心思想不要背设计模式要理解“为什么需要这种设计”。目录1. 设计模式到底解决什么2. 第一原则组合优于继承3. Strategy策略模式4. Factory工厂模式5. Adapter适配器模式6. Facade外观模式7. Observer观察者 / 事件模式8. Command命令模式9. State状态模式10. Dependency Injection依赖注入11. 设计模式真正应该学习什么12. 设计模式的反模式13. AI Coding 中如何使用设计模式14. 本阶段最终能力1. 设计模式到底解决什么设计模式不是为了让代码显得高级。它解决的是反复出现的软件设计问题需求变化 ↓ 代码结构开始复杂 ↓ 找到变化点 ↓ 隔离变化 ↓ 减少影响范围所以设计模式与前面的“高内聚、低耦合、封装变化”是一脉相承的。2. 第一原则组合优于继承不要看到不同类型就马上建立复杂继承树。很多时候继承容易形成强耦合。而组合更灵活。例如ModelService ├── Loader ├── Cache ├── CoordinateTransformer └── LoggerModelService 通过组合获得能力。3. Strategy策略模式适合同一个业务流程存在多个可替换算法 / 实现。例如 GIS 模型加载ModelLoader ├── OSGBLoader ├── Tiles3DLoader ├── GLTFLoader └── OBJLoader上层只依赖ModelLoader4. Factory工厂模式适合创建对象的逻辑比较复杂或者创建过程需要根据类型选择实现。例如createModelLoader(type)根据osgb 3dtiles gltf返回不同 Loader。注意简单对象不要为了“设计模式”强行使用 Factory。5. Adapter适配器模式适合两个接口不兼容但你希望它们能够协作。例如你的业务接口 ↓ ModelLoader ↓ 第三方 GIS SDK如果第三方 SDK 的接口与你的业务接口不同可以通过 Adapter 转换。6. Facade外观模式适合一个复杂系统对外只需要暴露一个简单入口。例如GISFacade内部SceneManager ModelManager TerrainManager CameraManager CoordinateService外部只需要gis.loadProject()7. Observer观察者 / 事件模式适合一个事件发生后多个模块需要响应但不希望它们互相直接依赖。例如ModelService ↓ model:loaded ↓ ┌──────────┬──────────┐ ↓ ↓ ↓ UI Logger SceneManager非常适合Electron前端状态变化GIS 场景事件异步任务8. Command命令模式把“一个操作”封装成对象或独立命令。例如LoadModelCommand RemoveModelCommand MoveModelCommand适合进一步实现UndoRedo操作记录批量执行命令队列GIS 编辑类软件尤其值得理解。9. State状态模式当一个对象的行为会随着状态变化而变化时可以显式建模状态。例如Model ├── Idle ├── Loading ├── Loaded ├── Failed └── Disposed这比到处使用isLoading isLoaded isError更容易控制复杂度。10. Dependency Injection依赖注入核心思想不要让一个模块自己决定所有依赖。例如不推荐ModelService ↓ new CesiumModelLoader()可以考虑ModelService ↓ ModelLoader然后外部注入ModelService(loader)这样测试时可以传FakeModelLoader从而降低耦合、提高可测试性。11. 设计模式真正应该学习什么不要记Strategy 策略 Factory 工厂 Observer 观察者而要记什么问题 ↓ 什么变化 ↓ 哪里耦合 ↓ 如何隔离例如为什么使用 Strategy不是因为“Strategy 是经典设计模式。”而是因为这里有多个可替换算法而且未来可能继续增加。12. 设计模式的反模式常见错误简单问题 ↓ 硬套设计模式 ↓ Factory AbstractFactory Strategy Adapter ↓ 代码复杂度暴涨最终设计模式解决的问题比原来的问题还复杂。所以应该遵循先有问题再有模式。13. AI Coding 中如何使用设计模式不要问“这里帮我用设计模式优化。”更好的问法当前代码存在多个模型格式。 请分析 1. 这些实现有哪些变化点 2. 是否存在高耦合 3. Strategy / Factory / Adapter 哪种更适合 4. 是否真的有必要引入设计模式 5. 最简单的方案是什么这会训练你的设计判断能力。14. 本阶段最终能力能够看到一个问题时自然思考这里什么会变化 ↓ 能不能封装 ↓ 能不能通过接口隔离 ↓ 能不能通过组合降低耦合 ↓ 有没有必要使用某种设计模式最终目标不是会背设计模式而是会识别设计问题。
