Spring框架
Spring是分层的JavaSE/JavaEE应用一站式的轻量级开源框架,以IoC/DI和AOP为内核,提供了展现层SpringMVC和持久层SpringJDBC以及业务层事务管理等众多的企业级应用技术,并整合了大量的第三方框架和类库,逐步成为使用最多的JavaEE企业级应用开发框架
Hello Spring
用于总体的管理,主要简化对象的创建和依赖关系的管理,并依靠AOP可以抽离公共的业务逻辑处理
1、添加依赖
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-context-support</artifactId>
<version>5.3.6</version>
</dependency>
2、定义核心配置文件
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">
<!--配置受管bean,id是受管bean的标识名称,class是受管bean的类全名-->
<bean id="now" class="java.util.Date"/>
</beans>
3、编程调用
public class A {
public static void main(String[] args) {
Resource resource=new ClassPathResource("beans.xml");
//Resource接口有2种具体实现
// 1、ClassPathResource在classpath路径下查找核心配置文件
//2、FileSystemResource在指定的路径下查找核心配置文件
//获取IoC容器的引用
BeanFactory facory=new XmlBeanFactory(resource);
//需要使用对象时根据受管bean的名称获取受管bean对象,由容器负责创建对象,并管理对象的生命周期
Object now=facory.getBean("now");
System.out.println(now);
}
}
OOP
设计模式六大原则:单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则
##单一职责原则SRP
一个类只负责一个功能领域中的相应职责。
单一职责原则是实现高内聚、低耦合的指导方针,它是最简单但又最难运用的原则,需要设计人员发现类的不同职责并将其分离,而发现类的多重职责需要设计人员具有较强的分析设计能力和相关实践经验。
开闭原则OCP
一个软件实体应当对扩展开放,对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
为了满足开闭原则,需要对系统进行抽象化设计,抽象化是开闭原则的关键。在Java等编程语言中,可以为系统定义一个相对稳定的抽象层,而将不同的实现行为移至具体的实现层中完成。在很多面向对象编程语言中都提供了接口、抽象类等机制,可以通过它们定义系统的抽象层,再通过具体类来进行扩展。如果需要修改系统的行为,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。
##里氏代换原则LSP
所有引用基类的地方必须能透明地使用其子类的对象。在软件中将一个基类对象替换成它的子类对象,程序将不会产生任何错误和异常,反过来则不成立,如果一个软件实体使用的是一个子类对象的话,那么它不一定能够使用基类对象。
依赖倒转原则DIP
抽象不应该依赖于细节,细节应当依赖于抽象。换言之,要针对接口编程,而不是针对实现编程。
依赖注入是指当一个对象要与其他对象发生依赖关系时,通过抽象来注入所依赖的对象。常用的注入方式有三种,分别是:构造注入,设值注入(Setter注入)和接口注入。
接口隔离原则ISP
使用多个专门的接口,而不使用单一的总接口,即客户端不应该依赖那些它不需要的接口。
迪米特法则LoD
一个软件实体应当尽可能少地与其他实体发生相互作用。迪米特法则可降低系统的耦合度,使类与类之间保持松散的耦合关系。
设计原则的选用
对这六个原则的遵守并不是是和否的问题,而是多和少的问题,也就是说一般不会说有没有遵守,而是说遵守程度的多少。任何事都是过犹不及,设计模式的六个设计原则也是一样,制定这六个原则的目的并不是要刻板的遵守,而需要根据实际情况灵活运用。对遵守程度只要在一个合理的范围内,就算是良好的设计。
JavaSE的设计模式
在1994年由四人合著出版了一本名为Design Patterns - Elements of Reusable Object-Oriented Software(设计模式 - 可复用的面向对象软件元素)的书,该书首次提到了软件开发中设计模式的概念。
GOF总结了JavaSE开发中常见的23种设计模式,可以分为3大类:创建型模式、结构型模式、行为型模式
JavaEE模式目前缺乏统一的说法。
JavaEE设计模式:关注表示层,如MVC模式(MVC Pattern) 数据访问对象模式DAO(Data Access Object Pattern) 前端控制器模式(Front Controller Pattern) … …
单例模式
属于创建型模式,它提供了一种创建对象的最佳方式。
主要解决:保证一个类仅有一个实例,并提供一个访问它的全局访问点。
优点:
1、在内存里只有一个实例,减少了内存的开销,尤其是频繁的创建和销毁实例。
2、避免对资源的多重占用(比如写文件操作)。
缺点:
没有接口,不能继承,与单一职责原则冲突,一个类应该只关心内部逻辑,而不关心外面怎么样来实例化。