网站建设学习心得ui设计网课

网站建设学习心得,ui设计网课,互联网+创业项目,视频拍摄器材事实上#xff0c;许多学习者将重点放在了记忆“招式”#xff08;即具体模式#xff09;上#xff0c;导致即便背熟了众多模式#xff0c;在实际开发中仍鲜有应用。设计模式真正的核心在于其背后的设计原则。所有经典的设计模式#xff0c;无一不是在这些基本原则的指导…事实上许多学习者将重点放在了记忆“招式”即具体模式上导致即便背熟了众多模式在实际开发中仍鲜有应用。设计模式真正的核心在于其背后的设计原则。所有经典的设计模式无一不是在这些基本原则的指导思想下衍生出来的。因此欲成高手必先修炼好“内功”。下面我将系统阐述构成设计模式基石的七大设计原则。一、单一职责原则定义一个类应该只有一个引起它变化的原因。解读通俗来讲如果你能找到两种及以上不同类型的理由去修改某个类那么这个类就违反了单一职责原则。示例剖析javaclass UserService {public void register(String username, String password) {// 1. 校验用户名和密码if (username null || password.length() 6) {throw new IllegalArgumentException(参数错误);}// 2. 保存用户到数据库System.out.println(save user to mysql);// 3. 发送欢迎短信System.out.println(send sms to user);// 4. 打印日志System.out.println(log register success);}}上述 UserService 类至少面临四种独立的修改原因1. 产品需求变化密码规则调整为数字字母组合。2. 运维需求变化日志需同时输出至本地与远程日志系统。3. 技术架构变化数据库从 MySQL 迁移至 Oracle。4. 运营需求变化欢迎通知从短信改为邮件。这四种毫无关联的变化都可能导致修改同一个类若系统中有多个 Service修改将变得异常繁琐且风险极高。设计模式的目标之一正是将变化的影响局部化最大限度减少修改范围。重构方案将不同变化的职责封装到独立的类中。javaclass UserService {private UserValidator validator new UserValidator();private UserRepository repository new UserRepository();private Notifier notifier new Notifier();private Logger logger new Logger();public void register(String username, String password) {validator.validate(username, password); // 封装规则变化repository.save(username, password); // 封装存储变化notifier.notifyUser(username); // 封装通知变化logger.log(register success); // 封装日志变化}}策略模式即是单一职责原则的一个典型应用。二、开闭原则定义对扩展开放对修改关闭。解读系统设计应允许在不修改现有稳定代码的前提下通过扩展来增加新功能。此原则与单一职责原则相辅相成后者负责封装变化前者则倡导通过扩展而非修改来应对变化。反面示例javaclass PayService {public void pay(String type, int amount) {if (alipay.equals(type)) {System.out.println(use alipay);} else if (wechat.equals(type)) {System.out.println(use wechat);}// 每新增一种支付方式都需要修改此方法添加一个else if}}此种设计会导致类不断膨胀难以维护。遵循开闭原则的重构java// 定义抽象策略interface PayStrategy {void pay(int amount);}// 具体策略实现class AliPay implements PayStrategy {public void pay(int amount) {System.out.println(alipay amount);}}class WeChatPay implements PayStrategy {public void pay(int amount) {System.out.println(wechat amount);}}// 上下文依赖抽象class PayService {private PayStrategy strategy;public PayService(PayStrategy strategy) {this.strategy strategy;}public void pay(int amount) {strategy.pay(amount);}}此后新增支付方式如 BankPay只需实现 PayStrategy 接口即可PayService 核心逻辑无需改动。策略模式、工厂模式、装饰器模式、观察者模式等都是开闭原则的典型体现。三、里氏替换原则定义子类对象必须能够替换其父类对象且替换后程序的正确性不被破坏。解读任何使用父类类型的地方都应能透明地替换为子类对象。违反LSP的示例javaclass Employee { // 全职员工public double calculateSalary(double baseSalary) {return baseSalary; // 全职工资 基本工资}}class PartTimeEmployee extends Employee { // 兼职员工Overridepublic double calculateSalary(double baseSalary) {return baseSalary 0.5; // 兼职按半薪算}}// 使用方法public void printAnnualSalary(Employee employee) {// 期望年薪 月薪 12System.out.println(employee.calculateSalary(1000) 12);}当 PartTimeEmployee 实例传入 printAnnualSalary 方法时计算出的“年薪”是基于错误假设的兼职可能干不满12个月程序行为出现错误。这说明 PartTimeEmployee 并不是 Employee 合适的子类。遵循LSP的设计应基于共同行为抽象接口而非不恰当的继承。javainterface SalaryCalculator {double calculateSalary(double baseSalary);}class FullTimeSalaryCalculator implements SalaryCalculator {public double calculateSalary(double baseSalary) { return baseSalary; }}class PartTimeSalaryCalculator implements SalaryCalculator {public double calculateSalary(double baseSalary) { return baseSalary 0.5; }}策略模式、模板方法模式、装饰器模式等都体现了LSP思想确保子类或具体实现能安全替换父类或接口。四、依赖倒置原则定义1. 高层模块不应依赖低层模块二者都应依赖抽象。2. 抽象不应依赖细节细节应依赖抽象。解读高层业务逻辑应依赖于接口抽象而非具体的实现类。反面示例javaclass OrderService {private PayService payService new PayService();public void checkout(double amount, String type) {if (type.equals(alipay)) {payService.payByAliPay(amount);} else if (type.equals(wechat)) {payService.payByWeChat(amount);}}}OrderService高层直接依赖了具体的 PayService 及其方法。新增支付方式需要同时修改高层和低层代码。遵循DIP的重构java// 抽象interface PayStrategy {void pay(double amount);}// 具体实现class AliPay implements PayStrategy { / ... / }class WeChatPay implements PayStrategy { / ... / }// 高层模块依赖抽象class OrderService {private PayStrategy payStrategy;public OrderService(PayStrategy payStrategy) { // 依赖注入this.payStrategy payStrategy;}public void checkout(double amount) {payStrategy.pay(amount); // 只调用抽象方法}}// 使用OrderService order1 new OrderService(new AliPay());order1.checkout(100);此原则保证了当底层实现变化时高层业务逻辑保持稳定系统可通过扩展灵活适应变化。依赖注入、策略模式、工厂模式是此原则的主要应用。五、接口隔离原则定义客户端不应被迫依赖它不使用的接口方法。解读接口应当职责单一、粒度细小只暴露客户端真正需要的方法避免“胖接口”。反面示例javapublic interface UserService{void addUser(User user);void log(String tag, String message); // 与用户核心业务无关void uploadFile(File file); // 与用户核心业务无关}UserService 接口混杂了日志、文件上传等不相关的职责导致实现类被迫实现所有方法降低了内聚性。遵循ISP的重构javapublic interface UserService{void addUser(User user);void updateUser(User user);User findById(Integer id);void delete(Integer id);}public interface LogService{void log(String tag, String message);}public interface UploadService{void uploadFile(File file);}将不同业务的接口分离使得系统更清晰也提高了接口的复用性。策略模式、装饰器模式、适配器模式都体现了接口隔离的思想。六、迪米特法则最少知识原则定义一个对象应尽可能少地了解其他对象只与“直接的朋友”通信。解读降低类之间的耦合度避免过深的链式调用。违反示例javaclass User {private Address address;public Address getAddress() { return address; }}class Address {private String city;public String getCity() { return city; }}class OrderService {public void printUserCity(User user) {// 深层调用user address citySystem.out.println(user.getAddress().getCity());}}OrderService 不仅依赖 User还间接依赖了 Address 的内部细节。一旦 Address 结构变化OrderService 也可能需要修改。遵循迪米特法则的重构javaclass User {private Address address;public String getCity() { // 封装对Address的访问return address.getCity();}}class OrderService {public void printUserCity(User user) {// 只与User交互不感知Address细节System.out.println(user.getCity());}}此法有效防止了 a.getB().getC().doSomething() 这类深层链式调用降低了模块间的耦合使系统更易维护。外观模式、代理模式是该法则的典型应用。七、合成复用原则定义优先使用对象组合而非类继承来达到复用的目的。解读组合比继承具有更大的灵活性能降低类之间的耦合度。反面示例过度使用继承javaclass Report {public void generatePDF() { System.out.println(生成PDF报表); }public void generateExcel() { System.out.println(生成Excel报表); }}class LoggedReport extends Report { // 通过继承添加日志功能Overridepublic void generatePDF() {System.out.println(记录日志);super.generatePDF();}Overridepublic void generateExcel() {System.out.println(记录日志);super.generateExcel();}}LoggedReport 与 Report 紧密耦合。若 Report 的方法签名或行为改变LoggedReport 必须同步修改且无法灵活地复用其他类型的“增强”功能如加密、压缩等。遵循合成复用原则的重构javaclass Report {public void generatePDF() { / ... / }public void generateExcel() { / ... / }}class Logger { // 独立的日志功能public void log(String msg) { System.out.println(记录日志: msg); }}class ReportService { // 通过组合复用private Report report;private Logger logger;public ReportService(Report report, Logger logger) {this.report report;this.logger logger;}public void generatePDF() {logger.log(生成PDF);report.generatePDF();}public void generateExcel() {logger.log(生成Excel);report.generateExcel();}}通过组合可以更灵活地装配不同功能且 Report 和 Logger 可以独立变化和复用。总结七大设计原则构成了高质量软件设计的基石。在日常开发中时刻以这些原则为指导能够使你的程序结构更清晰、代码更简洁、模块更独立从而显著降低维护成本提升系统的可扩展性与健壮性。掌握这些“内功”远比单纯记忆设计模式“招式”更为重要。来源小程序app开发|ui设计|软件外包|IT技术服务公司-木风未来科技-成都木风未来科技有限公司