写代码总被Dis：5个项目案例带你掌握SOLID技巧,代码有架构风格

最新推荐文章于 2024-10-13 18:12:20 发布
最新推荐文章于 2024-10-13 18:12:20 发布
阅读量1k 收藏 10
点赞数 26
文章标签： 架构 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2301_78976656/article/details/140351822
版权

SOLID 原则图

  • 单一职责原则是基础，确保每个类只关注一件事情。
  • 开闭原则建立在单一职责原则之上，强调通过扩展而不是修改现有代码来添加新功能。
  • 里氏替换原则确保继承体系的健全性，让派生类可以安全地替换基类。
  • 接口隔离原则避免让客户端依赖于它们不需要的接口，提高了接口的可用性。
  • 依赖倒置原则将高层策略性业务规则与低层细节解耦，使系统更加灵活。

文本通过ERP案例、支付系统集成案例、订单案例、折扣案例、汽车租赁项目案例代码片段来讲解SOLID设计原则如何落地到业务项目来提高项目整体的质量,不讲概念,注重实战落地。

依赖倒置

1. 依赖倒置原则设计图：

整理了这份面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

需要全套面试笔记【点击此处】即可免费获取

2. 依赖倒置原则解决什么：

依赖倒置原则解决了在支付网关设计中，业务逻辑层与具体支付实现之间的紧密耦合问题。

3. 依赖倒置原则使用场景：

  • 当系统需要支持多种支付方式，并且预期会引入更多支付方式或修改现有支付逻辑时。
  • 在ERP系统中，当需要从多个数据源生成报告，或预期报告生成方式将随时间变化时。

4. ERP 案例

重构前：

 

java
 

代码解读
 

复制代码
 

public class FinancialModule { public void generateReports() { // 直接依赖于具体的数据库报告生成服务 DatabaseReportingService service = new DatabaseReportingService(); service.generate(...); } } class DatabaseReportingService { public void generate(/* parameters */) { // 从数据库生成报告的逻辑 } } 
 

问题分析：
 

  1. 紧耦合: FinancialModule 直接依赖于 DatabaseReportingService 的具体实现，耦合度高，导致系统灵活性差。
  2. 扩展性差: 当需要添加新的报告生成方式（例如基于文件的报告）时，可能需要修改 FinancialModule 的代码，这违背了开闭原则。
  3. 维护困难: 如果 DatabaseReportingService 的接口或实现发生变化，可能会影响到 FinancialModule，增加了维护成本。
  4. 测试复杂性: 直接依赖具体实现使得单元测试 FinancialModule 变得复杂，可能需要大量模拟（mocking）具体类。
  5. 代码重复: 如果系统中其他模块也需要生成报告，可能会复制 FinancialModule 中的代码，导致代码重复。
 

重构后：
 

 

java
 

代码解读
 

复制代码
 

interface ReportingService { void generate(ReportRequest request); } class DatabaseReportingService implements ReportingService { public void generate(ReportRequest request) { // 从数据库生成报告的逻辑 } } class FileBasedReportingService implements ReportingService { public void generate(ReportRequest request) { // 从文件生成报告的逻辑 } } class FinancialModule { private ReportingService reportingService; public FinancialModule(ReportingService reportingService) { this.reportingService = reportingService; } public void generateReports(ReportRequest request) { // 使用抽象的报告服务生成报告 reportingService.generate(request); } } // 使用FinancialModule FinancialModule financialModule = new FinancialModule(new DatabaseReportingService()); financialModule.generateReports(new ReportRequest()); 
 

解决的问题：
 

  1. 解耦合: FinancialModule 现在依赖于 ReportingService 接口，而不是任何具体实现，降低了耦合度。
  2. 扩展性增强: 新的报告生成方式（如 FileBasedReportingService）可以通过实现 ReportingService 接口轻松添加，无需修改 FinancialModule。
  3. 维护简化: 由于 FinancialModule 不依赖于具体实现，因此维护和升级报告生成服务时对 FinancialModule 的影响较小。
  4. 测试简化: 可以轻松地为 FinancialModule 编写单元测试，只需模拟 ReportingService 接口，而不是具体实现。
  5. 代码复用: 其他需要报告生成功能的模块可以重用 FinancialModule，通过注入不同的 ReportingService 实现来满足特定需求。
  6. 依赖注入: 通过构造函数或设置器注入 ReportingService 的实现，提高了 FinancialModule 的灵活性和可配置性。
  7. 单一职责: FinancialModule 专注于其业务逻辑，而报告生成的具体细节由 ReportingService 的实现负责，符合单一职责原则。
 

接口隔离
 

1. 接口隔离设计图：
 

将一个臃肿的接口拆分为多个客户端特定的接口：
 

 

2. 接口隔离解决什么：
 

接口隔离原则解决了因为接口设计过于庞大而导致的低内聚和高耦合问题，使得使用接口的类实现了许多它们不需要的方法。
 

3. 接口隔离使用场景：
 

当一个类实现了许多它不需要的方法时，或者当多个类因为依赖同一个接口而互相影响时，应该考虑使用接口隔离原则。
 

4.支付系统集成案例
 

商务平台，需要集成多种支付方式，如信用卡支付和银行转账
 

重构前：
 

 

java
 

代码解读
 

复制代码
 

public interface IPayable { void processPayment(); } public class PaymentService { public void processPayment(IPayable payment) { payment.processPayment(); } } // 特定支付方式实现IPayable接口 public class CreditCardPayment implements IPayable { @Override public void processPayment() { // 处理信用卡支付逻辑 } } public class BankTransferPayment implements IPayable { @Override public void processPayment() { // 处理银行转账逻辑 } } 
 

分析问题：
 

  1. 过度依赖: IPayable 接口强制所有实现类都实现 processPayment 方法，但不同支付方式可能需要不同的处理逻辑和附加步骤，例如信用卡授权或账户验证。
  2. 低内聚性: IPayable 接口可能包含了与支付处理无直接关联的方法，导致接口的内聚性降低。
  3. 扩展性差: 当需要添加新的支付方式或改变现有支付逻辑时，可能需要修改接口定义或对多个类进行更改，这增加了扩展的难度。
  4. 违反LSP: 如果子类重写了基类的方法以添加特定逻辑，这可能会影响使用基类引用的客户端代码，违反了里氏替换原则。
  5. 代码冗余: 为了满足接口定义，某些类可能不得不提供空实现或不相关的实现，导致代码冗余。
 

重构后：
 

 

java
 

代码解读
 

复制代码
 

public interface IPaymentProcessor { void processPayment(); } public interface ICreditCardPaymentProcessor extends IPaymentProcessor { void authorizeCard(); } public interface IBankTransferPaymentProcessor extends IPaymentProcessor { void validateAccount(); } public class CreditCardPaymentProcessor implements ICreditCardPaymentProcessor { @Override public void processPayment() { // 处理信用卡支付逻辑 } @Override public void authorizeCard() { // 授权信用卡 } } public class BankTransferPaymentProcessor implements IBankTransferPaymentProcessor { @Override public void processPayment() { // 处理银行转账逻辑 } @Override public void validateAccount() { // 验证账户信息 } } public class PaymentService { public void processPayment(IPaymentProcessor paymentProcessor) { paymentProcessor.processPayment(); } } 
 

解决的问题：
 

  1. 职责明确: 通过将 IPayable 拆分为 IPaymentProcessor、ICreditCardPaymentProcessor 和 IBankTransferPaymentProcessor，每个接口都聚焦于特定的支付处理职责，提高了内聚性。
  2. 更好的扩展性: 新的支付方式可以通过实现相应的接口轻松添加，而不影响现有代码。例如，如果需要添加微信支付，可以创建一个实现 IPaymentProcessor 的 WeChatPaymentProcessor 类。
  3. 遵循LSP: 子类（特定支付处理器）现在可以安全地替换基类（IPaymentProcessor），而不改变客户端代码的行为，因为它们提供了与基类相同的方法。
  4. 减少代码冗余: 每个支付处理器类只需要实现与其职责相关的接口方法，消除了不必要的空实现或不相关的方法。
  5. 灵活性增强: 通过分离接口，可以更灵活地组合不同的支付处理步骤，例如，可以在信用卡支付处理器中添加额外的授权步骤，而不会影响到其他支付方式。
  6. 易于维护: 当需要修改特定支付方式的逻辑时，只需修改对应的接口实现，而不会影响到其他支付方式的实现，简化了维护工作。
 

单一职责
 

1. 单一职责设计图：
 

 

 

2. 单一职责解决什么：
 

单一职责原则解决了类设计中的职责不明确和过度耦合问题。它确保每个类只关注一个功能领域，从而降低类之间的依赖，提高代码的可维护性和灵活性。
 

3. 单一职责使用场景：
 

当系统复杂度增加，原有类开始承担多个职责，或者当修改一个功能需要同时修改多个地方时，就需要考虑使用单一职责原则进行重构。
 

4. 订单案例
 

重构案例：
 

  • 考虑一个电子商务平台的订单处理系统，其中订单服务类同时处理订单创建、支付和物流等。
 

重构前：
 

 

java
 

代码解读
 

复制代码
 

public class OrderService { public void createOrder(Order order) { // 创建订单逻辑 } public void processPayment(Order order) { // 处理支付逻辑 } public void shipOrder(Order order) { // 发货逻辑 } } 
 

重构后：
 

 

java
 

代码解读
 

复制代码
 

public class OrderCreationService { public void createOrder(Order order) { // 创建订单逻辑 } } public class PaymentService { public void processPayment(Order order) { // 处理支付逻辑 } } public class ShipmentService { public void shipOrder(Order order) { // 发货逻辑 } } 
 

开闭原则
 

1. 开闭原则设计图：
 

 

设计一个电子商务平台的支付模块，该模块需要能够处理不同类型的支付方式，例如信用卡支付和PayPal支付。随着市场的发展，我们可能需要添加更多的支付方式，如微信支付、Apple Pay等。
 

2. 开闭原则解决什么：
 

开闭原则解决了软件中因需求变更导致的频繁修改问题。遵循此原则的系统可以在不修改现有代码的基础上，通过增加新的代码来扩展功能。
 

3. 开闭原则使用场景：
 

当面临需求频繁变更或预期将来会有变更时，应考虑使用开闭原则来设计系统。
 

4. 折扣案例
 

图书管理系统需要根据不同的会员等级应用不同的折扣策略。我们预期未来可能会增加更多的会员等级和折扣规则。
 

重构前的代码：
 

  • 硬编码编写所有的折扣逻辑
 

 

java
 

代码解读
 

复制代码
 

public class DiscountCalculator { public double calculateDiscount(double originalPrice, String membershipLevel) { switch (membershipLevel) { case "Gold": return originalPrice * 0.90; // Gold members get 10% off case "Silver": return originalPrice * 0.95; // Silver members get 5% off default: return originalPrice; // No discount for others } } } 
 

应用开闭原则的重构：
 

为了遵循开闭原则，我们将折扣逻辑抽象化，使其能够容易地扩展新会员等级和折扣规则，而不需要修改现有的DiscountCalculator类。
 

  1. 定义折扣策略接口 (DiscountStrategy.java)
 

 

java
 

代码解读
 

复制代码
 

public interface DiscountStrategy { double calculateDiscount(double originalPrice); } 
 

  1. 实现具体的折扣策略 (GoldDiscountStrategy.java, SilverDiscountStrategy.java)
 

 

java
 

代码解读
 

复制代码
 

public class GoldDiscountStrategy implements DiscountStrategy { public double calculateDiscount(double originalPrice) { return originalPrice * 0.90; } } public class SilverDiscountStrategy implements DiscountStrategy { public double calculateDiscount(double originalPrice) { return originalPrice * 0.95; } } 
 

  1. 修改折扣计算器以使用策略 (DiscountCalculator.java)
 

 

java
 

代码解读
 

复制代码
 

public class DiscountCalculator { private DiscountStrategy discountStrategy; public DiscountCalculator(DiscountStrategy discountStrategy) { this.discountStrategy = discountStrategy; } public double calculateDiscount(double originalPrice) { return discountStrategy.calculateDiscount(originalPrice); } } 
 

  1. 客户端代码 (Client.java)
 

 

java
 

代码解读
 

复制代码
 

public class Client { public static void main(String[] args) { DiscountStrategy goldDiscount = new GoldDiscountStrategy(); DiscountCalculator calculator = new DiscountCalculator(goldDiscount); double discountedPrice = calculator.calculateDiscount(100.0); System.out.println("Discounted price for Gold member: " + discountedPrice); // Easily switch to a different discount strategy DiscountStrategy silverDiscount = new SilverDiscountStrategy(); calculator.setDiscountStrategy(silverDiscount); discountedPrice = calculator.calculateDiscount(100.0); System.out.println("Discounted price for Silver member: " + discountedPrice); } } 
 

里氏替换原则
 

1. 里氏替换原则设计图：
 

展示金融交易系统中的基类和子类之间的关系：
 

 

2. 里氏替换原则解决什么：
 

里氏替换原则解决了继承关系中的脆弱性问题，确保子类能够安全地替换基类，避免因继承带来的风险和错误。例如： 在金融交易系统中，需要处理不同类型的交易，每种交易都有其特定的执行和撤销逻辑。LSP确保这些不同的交易类型可以安全地使用基类接口进行操作。
 

3. 什么情况下需要用原则：
 

在需要实现多种类型交易的金融系统中，当系统要求不同类型的交易能够统一处理，但又各自具有特殊行为时。
 

4. 汽车租赁
 

重构前：
 

 

java
 

代码解读
 

复制代码
 

public class Vehicle { protected double dailyRate; public Vehicle(double dailyRate) { this.dailyRate = dailyRate; } public double calculateRentalCost(int numberOfDays) { // 普通车辆的租赁费用计算 return dailyRate * numberOfDays; } } public class RegularCar extends Vehicle { // 普通汽车特有逻辑 } public class LuxuryCar extends Vehicle { private double luxurySurcharge; public LuxuryCar(double dailyRate, double luxurySurcharge) { super(dailyRate); this.luxurySurcharge = luxurySurcharge; } @Override public double calculateRentalCost(int numberOfDays) { // 豪华车的租赁费用计算，包括额外的附加费 return super.calculateRentalCost(numberOfDays) + (luxurySurcharge * numberOfDays); } } 
 

分析问题：
 

  1. 不一致的成本计算：LuxuryCar 类改变了 calculateRentalCost 方法的行为，这可能导致基类 Vehicle 的其他潜在子类也必须以相同的方式重写该方法，违反了里氏替换原则。
  2. 扩展性问题：如果未来需要添加更多的车辆类型，如 ElectricCar，它们可能有自己的成本计算逻辑，这将导致更多的方法重写，增加了系统的复杂性。
 

重构后：
 

引入策略模式来定义不同的成本计算策略，并将这些策略应用到具体的车辆类中。
 

 

java
 

代码解读
 

复制代码
 

public interface RentalCostStrategy { double calculateCost(Vehicle vehicle, int numberOfDays); } public class RegularCostStrategy implements RentalCostStrategy { public double calculateCost(Vehicle vehicle, int numberOfDays) { return vehicle.getDailyRate() * numberOfDays; } } public class LuxuryCostStrategy implements RentalCostStrategy { public double calculateCost(Vehicle vehicle, int numberOfDays) { double baseCost = new RegularCostStrategy().calculateCost(vehicle, numberOfDays); return baseCost + (vehicle.getLuxurySurcharge() * numberOfDays); } } public abstract class Vehicle { protected double dailyRate; private RentalCostStrategy costStrategy; public Vehicle(double dailyRate, RentalCostStrategy costStrategy) { this.dailyRate = dailyRate; this.costStrategy = costStrategy; } public double getDailyRate() { return dailyRate; } public double getLuxurySurcharge() { // 默认没有附加费 return 0; } public double calculateRentalCost(int numberOfDays) { return costStrategy.calculateCost(this, numberOfDays); } } public class RegularCar extends Vehicle { public RegularCar(double dailyRate) { super(dailyRate, new RegularCostStrategy()); } } public class LuxuryCar extends Vehicle { private double luxurySurcharge; public LuxuryCar(double dailyRate, double luxurySurcharge) { super(dailyRate, new LuxuryCostStrategy()); this.luxurySurcharge = luxurySurcharge; } @Override public double getLuxurySurcharge() { return luxurySurcharge; } }

                

        

        

    

  


    

      

        

            

              
                
                  「已注销」
                
              
            

            

                关注
              
            

        

        

          
      

      









                



	

		

			

				
					
Dis-tune:我们论文的代码

				
			

			

				

					03-25
				

			

		

		

			
				
"Dis-tune:我们论文的代码"这个标题表明这是一份与音乐调音技术相关的科研项目源代码。在计算机科学领域，尤其是音频处理和音乐信息检索（MIR）子领域，这样的代码库可能是用于实现某种新颖的音高调整算法或者音乐...

			
		

	



                

              
                



	

		

			

				
					
EMOJI2019：EMOJI2019上Twitter和微博上的表情符号-情感协会中的探索（Dis-）相似之处论文附带的代码

				
			

			

				

					02-05
				

			

		

		

			
				
在Twitter和微博上探索表情符号-情感协会的（Dis-）相似之处  在EMOJI2019上的Twitter和微博上的表情符号情感协会中的探索（Dis-）相似之处论文附带的代码。  主要代码文件是Notebook EMOJI2019 - After Models Are ...

			
		

	



                


  
              

                


	

		

			

				
					
接口隔离原则：精简接口，专注职责，多环境配置管理案例

				
			

			

				

					肖哥弹架构博客
				

				

					07-10
					
					795
					
				

			

		

		

			
				
接口隔离原则解决了因为接口设计过于庞大而导致的低内聚和高耦合问题，使得使用接口的类实现了许多它们不需要的方法。

			
		

	





	

		

			

				
					
设计模式之SOLID原则

				
			

			

				

					Ariel_欢
				

				

					08-04
					
					2104
					
				

			

		

		

			
				
介绍

设计模式中的SOLID原则，分别是单一原则、开闭原则、里氏替换原则、接口隔离原则、依赖倒置原则。前辈们总结出来的，遵循五大原则可以使程序解决紧耦合，更加健壮。


			        SRP
			
			
			            单一责任原则
			
		
			        OCP
			
			
			            开放封闭原则
			
		
			        LSP
			...

			
		

	



		

			
		



	

		

			

				
					
项目初期：架构师不要炫技，3大设计原则你不懂

				
			

			

				

					肖哥弹架构博客
				

				

					07-16
					
					688
					
				

			

		

		

			
				
架构师避免过度设计的关键在于理解真实业务需求，采用迭代和敏捷开发方法，专注于核心功能实现。通过遵循SOLID和GRASP原则、适度使用设计模式、保持设计简洁（KISS原则）、避免过早优化，以及进行持续的代码重构，架构师可以确保系统的灵活性和可维护性。同时，建立快速反馈循环、管理技术债务、进行风险评估和原型验证，都是确保设计适度且实用的重要策略。

			
		

	





	

		

			

				
					
功能强大,代码优雅：Java8真实案例Stream大数据集高效之旅(收藏版)

				
			

			

				

					肖哥弹架构博客
				

				

					07-29
					
					677
					
				

			

		

		

			
				
功能强大,代码优雅：Java8真实案例Stream大数据集高效之旅(收藏版)
Java8 新增了非常多的特性，我们主要讨论以下几个：
-   **Lambda 表达式** − Lambda 允许把函数作为一个方法的参数（函数作为参数传递到方法中）。
-   **Stream API** −新添加的Stream API（java.util.stream） 把真正的函数式编程风格引入到Java中。

			
		

	





	

		

			

				
					
Java 8函数式编程全攻略：43种函数式业务代码实战案例解析(收藏版)

				
			

			

				

					肖哥弹架构博客
				

				

					07-28
					
					1033
					
				

			

		

		

			
				
Java 8 (又称为 jdk 1.8) 是 Java 语言开发的一个主要版本。 Oracle 公司于 2014 年 3 月 18 日发布 Java 8 ，它支持函数式编程，新的 JavaScript 引擎，新的日期 API，新的Stream API 等。

			
		

	





	

		

			

				
					
68种架构可扩展性设计：从类到服务治理(成就架构师必备,收藏金典)

				
			

			

				

					weixin_37066607的博客
				

				

					08-17
					
					39
					
				

			

		

		

			
				
在现代软件工程中，可扩展性是确保软件系统能够适应未来增长的关键特性。本文将全方位探讨可扩展性的多个方面，包括类设计、插件化、框架设计、架构设计、中间件集成扩展和服务治理。主要传递给大家扩展性设计的思路与涉足的范围。具体完善的细节，可以参考各中间件与业务架构。不了解的可以关注肖哥，提问。

肖哥弹架构 跟大家“弹弹” 代码...

			
		

	





	

		

			

				
					
架构师妙用：充血模型行为与状态管理类设计

				
			

			

				

					肖哥弹架构博客
				

				

					07-23
					
					1007
					
				

			

		

		

			
				
在充血模型（Rich Domain Model）中，对象的“行为”和“状态管理”：

1.  **行为（Behavior）** ：

    -   这指的是领域对象执行的动作或操作，通常是通过对象的方法（函数）来实现的。这些方法定义了对象可以做什么，以及它如何响应来自外部的请求。

1.  **状态（State）** ：

    -   这指的是领域对象在任何给定时间点的内部数据或属性的集合。状态可以影响对象的行为，并且对象的行为可能会改变其状态。

在充血模型中，领域对象负责管理自己的状态，这意味着它

			
		

	





	

		

			

				
					
贫血模型：简化设计还是过度简化(架构篇)？

				
			

			

				

					cnzzs的博客
				

				

					07-21
					
					865
					
				

			

		

		

			
				
贫血模型是一种软件设计模式，其中业务逻辑被放置在服务层或管理类中，而领域模型仅包含数据和访问这些数据的方法。这种模式有时被认为是反模式，因为它可能导致领域模型过于简单，缺乏业务逻辑。

肖哥弹架构 跟大家“弹弹” 代码设计技巧，需要代码关注
欢迎 点赞，点赞，点赞。
关注公号Solomon肖哥弹架构获取更多精彩内容

历...

			
		

	





	

		

			

				
					
架构师妙用：充血模型行为与状态管理类设计(架构篇)

				
			

			

				

					肖哥弹架构博客
				

				

					09-29
					
					430
					
				

			

		

		

			
				
在充血模型中，领域对象负责管理自己的状态，这意味着它们不仅拥有数据（状态），还拥有改变这些数据的逻辑（行为）。领域对象的状态管理包括确保状态的完整性、一致性，以及在状态变化时执行任何必要的业务规则或约束。

			
		

	





	

		

			

				
					
open-dis:Open-DIS以多种语言实现IEEE DIS协议。-开源

				
			

			

				

					04-29
				

			

		

		

			
				
C ++，C-Sharp，Objective-C，Java，Javascript和XML的分布式交互式仿真（IEEE-... 有关每个感兴趣的软件包，请参见单独的代码目录。 该项目处于非活动状态，并已迁移到位于https://github.com/open-dis的GitHub项目。

			
		

	





	

		

			

				
					
matlab代码不反应-G14DIS-Code:为我的论文创建的代码为“淋巴间质中的趋化因子梯度和树突状细胞迁移”。

				
			

			

				

					05-26
				

			

		

		

			
				
matlab代码不ReactG14DIS代码 为我的论文创建的代码为“趋化因子趋化因子梯度和树突状细胞在淋巴间质中的迁移”。 文件'CodeHeirarchy.png'是一张图像，显示哪些函数相互调用，以及该过程的一般顺序。 文件“ Video_...

			
		

	





	

		

			

				
					
bsxbios_dis:BS-X BIOS拆卸

				
			

			

				

					05-02
				

			

		

		

			
				
【标题】"BS-X BIOS拆卸...总的来说，"bsxbios_dis"项目是一个典型的逆向工程案例，通过汇编语言的解析，揭示了BS-X BIOS的工作原理，这不仅有助于提高开发者的技术水平，也可能推动GBA平台的游戏开发和研究向前发展。

			
		

	





	

		

			

				
					
OpenStack系列第二篇：深入浅出了解OpenStack架构与优劣势

				
			

			

				

					weixin_41004518的博客
				

				

					10-10
					
					1065
					
				

			

		

		

			
				
在当今的云计算领域，OpenStack作为一个开源的云平台软件，被广泛应用于构建私有云和公有云。本文将为初学者提供一个深入浅出的讲解，帮助你理解OpenStack的工作原理、核心组件以及它在企业中的应用场景，并对比其与公有云和VMware的优势和劣势。OpenStack是一个开源的云计算平台，它通过模块化的方式管理和控制大规模的计算、存储和网络资源。

			
		

	





	

		

			

				
					
【linux】冯诺依曼架构

				
			

			

				

					Quietcoder的博客
				

				

					10-10
					
					1225
					
				

			

		

		

			
				
🔥个人主页Quitecoder🔥linux笔记仓。

			
		

	





	

		

			

				
					
Oracle架构之用户，权限，角色讲解

				
			

			

				

					上善若泪
				

				

					10-07
					
					735
					
				

			

		

		

			
				
Oracle用户（user）就是访问oracle数据库的人。通过对用户的各种安全参数进行控制，以维护数据库的安全性，这些概念包括模式（schema）、权限、角色、存储设置、空间限额、存取资源限制、数据库审计等。当用户登录Oracle时需要进行身份认证，以便确认该用户能够进行的操作。认证是指对需要使用数据、资源或应用程序的用户进行身份确认。通过认证后，可以为用户后面的数据库操作提供一种可靠的连接关系。Oracle提供了多种身份认证方式：操作系统身份认证，Oracle 数据库身份认证，管理员身份认证。

			
		

	





	

		

			

				
					
电子电气架构---汽车OEM敏捷式集成方案简介

					
最新发布

				
			

			

				

					Soly_kun的博客
				

				

					10-13
					
					1105
					
				

			

		

		

			
				
快速响应需求变化：
汽车OEM需要建立灵活的生产计划和供应链体系，以便快速响应市场需求的变化。这包括采用先进的预测模型来预测市场趋势，以及建立能够快速调整生产计划的机制。
优化库存管理：
通过敏捷的供应链管理，汽车OEM可以更有效地管理库存，减少库存积压和缺货现象。这有助于降低成本，提高资金利用效率。
提升供应商协同：
敏捷的供应链管理还强调与供应商的紧密协同。通过信息共享和协同规划，汽车OEM可以确保供应商能够及时、准确地提供所需的零部件和材料。

			
		

	



              




          




        



    





    



      

      

        
      

      





	

		评论	
	

	
	




  

    

      添加红包
      
    

    

      

        
        

          
          
        

        
请填写红包祝福语或标题

      

      

        
        

          
          个
        

        
红包个数最小为10个

      

      

        
        

          
          元
        

        
红包金额最低5元

      

      

        
        

          当前余额3.43元
          前往充值 >
        

      

      

        

          需支付：10.00元
        

        
        
      

    

  





  

    
    
  

  

    
    
  








  

    

      

        

          

            
            
成就一亿技术人!

          

          

        

        

          

          

            领取后你会自动成为博主和红包主的粉丝
            规则
          

        

      

      

        

          

            
              
            
            

              
hope_wisdom
 发出的红包
            

          

        

        

          

          

          

        

      

    

    

  



      
      

      
实付元

      
使用余额支付

      

        

          

            
            点击重新获取
          

        

        
扫码支付

      

      

        
          
            
          
          
        
      

      

        
        钱包余额
          0
          

            
            

              

                
抵扣说明：

                
 1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
 2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

              

            

          

      

      余额充值