二维码生成器网站手机如何翻到国外网站

二维码生成器网站,手机如何翻到国外网站,网站规划的基本原则,ih5 做视频网站关注我的公众号#xff0c;获取独家技术分享和资料一、先讲个故事#xff1a;老王开饭店老王开了一家饭店#xff0c;雇了个厨师叫小李。最初的做法#xff08;直接依赖#xff09;#xff1a;老王的饭店所有菜单、流程、采购都是围绕小李来设计的。小李喜欢用铁锅#…关注我的公众号获取独家技术分享和资料一、先讲个故事老王开饭店老王开了一家饭店雇了个厨师叫小李。最初的做法直接依赖老王的饭店所有菜单、流程、采购都是围绕小李来设计的。小李喜欢用铁锅老王就买铁锅小李习惯早上8点到老王就8点开门。问题来了小李要回老家了饭店怎么办找个新厨师小张但小张用不惯铁锅喜欢用不粘锅...老王不得不把厨房重新装修一遍这就是直接依赖带来的问题高层饭店被低层具体的厨师绑架了。二、依赖倒置是怎么解决的老王学聪明了他定了一个厨师岗位规范规范里写着必须会做本店菜单上的菜早上7:30到岗会用店里提供的标准厨具现在不管是小李、小张还是小王只要符合这个规范都能来老王店里上班。老王的饭店不再依赖某个具体的厨师而是依赖于一个抽象的规范。这就是依赖倒置的核心思想高层模块不应该依赖低层模块两者都应该依赖于抽象。抽象不应该依赖于细节细节应该依赖于抽象。用人话说就是老板别盯着具体的人要盯着岗位说明书。三、代码世界里的依赖倒置错误示范直接依赖// 订单服务直接依赖MySQL public class OrderService { private MySQLOrderRepository repository new MySQLOrderRepository(); public void createOrder(Order order) { repository.save(order); } }问题哪天老板说要换成 PostgreSQL你得改 OrderService要换成 MongoDB再改一遍...正确示范依赖倒置// 定义抽象接口 publicinterface OrderRepository { void save(Order order); } // 高层模块依赖抽象 publicclass OrderService { private OrderRepository repository; // 依赖接口不依赖具体实现 public OrderService(OrderRepository repository) { this.repository repository; } public void createOrder(Order order) { repository.save(order); } } // 具体实现也依赖抽象 publicclass MySQLOrderRepository implements OrderRepository { public void save(Order order) { /* MySQL实现 */ } } publicclass MongoOrderRepository implements OrderRepository { public void save(Order order) { /* MongoDB实现 */ } }现在换数据库只需要// 用MySQL OrderService service new OrderService(new MySQLOrderRepository()); // 换MongoDB OrderService service new OrderService(new MongoOrderRepository());OrderService 一行代码都不用改四、在DDD中依赖倒置有多重要在领域驱动设计DDD中依赖倒置简直是灵魂级别的存在。DDD的分层架构┌─────────────────────────────────────┐ │ 用户接口层 │ ├─────────────────────────────────────┤ │ 应用服务层 │ ├─────────────────────────────────────┤ │ ★ 领域层核心业务逻辑★ │ ← 这是老大 ├─────────────────────────────────────┤ │ 基础设施层 │ ← 数据库、消息队列、第三方服务等 └─────────────────────────────────────┘传统做法的问题领域层要存订单直接调用基础设施层的 MySQLRepository。结果呢核心业务代码里混入了数据库操作细节想换个存储方案业务代码全得改写单元测试先给我起个数据库再说...依赖倒置后领域层定义 interface OrderRepository { save(order); } 基础设施层实现 class MySQLOrderRepository implements OrderRepository领域层只关心我需要能存订单这个能力至于用MySQL还是Redis领域层根本不care测试时换个内存实现就行秒测这才是DDD要的效果让领域模型成为真正的核心不被技术细节污染。五、依赖倒置是必须的吗说实话不是。什么时候可以不用简单的CRUD项目就是增删改查业务逻辑简单数据库基本不可能换团队就两三个人沟通成本低一次性项目临时性的工具脚本用完即弃的演示项目性能极致要求某些场景抽象层会带来微小开销但说实话99%的项目瓶颈不在这什么时候必须用业务复杂度高的系统电商、金融、供应链等业务规则多变化快需要长期维护的项目预期生命周期3年以上团队会不断更换有明确的技术选型不确定性今天用MySQL明天可能要迁移今天用短信验证码明天可能换人脸识别需要高质量测试覆盖没有依赖倒置很多单元测试根本写不了六、依赖倒置的代价既然依赖倒置有那么多好处那有哪些代价呢代价说明代码量增加多了接口、多了注入逻辑理解成本初级开发者可能绕晕过度设计风险简单问题复杂化调试困难依赖关系不够直观架构师的价值就在于在正确的场景做正确的选择。七、总结一句话总结依赖倒置别让你的核心业务代码依赖具体的技术实现而是让技术实现来适配你的业务需求。形象比喻USB接口电脑不关心你插的是鼠标还是键盘只要符合USB规范220V插座插座不关心你接的是电视还是冰箱只要是220V的插头招聘JD公司不关心谁来应聘只要符合岗位要求最终建议依赖倒置不是银弹但在中大型项目、复杂业务场景、长期维护的系统中它几乎是必选项。记住好的架构不是一开始就完美的而是在正确的时机做出正确的权衡。依赖倒置只是工具而已。