【JAVA】Java进阶(一)

注解

什么是注解
        Java 注解(Annotation)又称 Java 标注,是 JDK5.0 引入的一种注释机制。
        Java 语言中的类、方法、变量、参数和包等都可以被标注。Java 标注可以通过反射获取标注内容。在编译器生成类文件时,标注可以被嵌入到字节码中。
        Java 虚拟机可以保留标注内容,在运行时可以获取到标注内容 。 当然它也支持自定义 Java 标注。

内置注解

        Java 语言中已经定义好的注解
        @Override - 检查该方法是否是重写方法。如果发现其父类,或者是引用的接口中并没有该方法时,会报编译错误。
        @Deprecated - 标记过时方法。如果使用该方法,会报编译警告。
        @SuppressWarnings - 指示编译器去忽略注解中声明的警告。
        @FunctionalInterface 用于指示被修饰的接口是函数式接口。

元注解

        元注解是 java API 提供的,是用于修饰注解的注解,通常用在注解的定义上:
                @Retention - 标识这个注解怎么保存,是只在代码中,还是编入 class 文件中,或者是在运行时可以通过反射访问。
                @Documented - 标记这些注解是否包含在用户文档中。
                @Target - 标记这个注解应该是哪种 Java 成员。
                @Inherited - 标记这个注解是继承于哪个注解类(默认注解并没有继承于任何子类)
                @Repeatable - 标识某注解可以在同一个声明上使用多次。
重点掌握
        @Target 用于描述注解的使用范围(即:被描述的注解可以用在什么地方.
        ElementType.TYPE 可以应用于类的任何元素。
        ElementType.CONSTRUCTOR 可以应用于构造函数。
        ElementType.FIELD 可以应用于字段或属性。
        ElementType.LOCAL_VARIABLE 可以应用于局部变量。
        ElementType.METHOD 可以应用于方法级注释。
        ElementType.PACKAGE 可以应用于包声明。
        ElementType.PARAMETER 可以应用于方法的参数。
        @Retention:@Retention 定义了该注解被保留的时间长短:某些注解仅出现在源代码中,而被编译器丢弃;而另一些却被编译在 class 文件中;编译在 class文件中的注解可能会被虚拟机忽略,而另一些在 class 被装载时将被读取(请注意并不影响 class 的执行,因为注解与 class 在使用上是被分离的)。用于描述注解的生命周期(即:被描述的注解在什么范围内有效)取值有:
                1.SOURCE:在源文件中有效(即源文件保留)
                2.CLASS:在 class 文件中有效(即 class 保留)
                3.RUNTIME:在运行时有效(即运行时保留)
此外还有自定义注解

对象克隆

为什么要克隆? 直接 new 一个对象不行吗?
        new 出来的对象的属性都还是初始化时候的值,所以当需要一个新的对象来保存当前对象的“状态”就靠 clone 方法了。

在一个现有的对象基础上,克隆创建出一个新的对象.

浅克隆 在克隆一个对象时,不能将对象中关联的引用类型对象重新创建,只是把引用地址复制过来.

深克隆

在克隆一个对象时,可以将关联对象也一并创建新的对的.

克隆方式:

  1. 类 实现Cloneable接口, 重写Object中的clone方法.(在多级关联时,处理起来比较麻烦)

  2. 使用序列化方式,可以重写创建对象,包含关联的对象

误区:
我们常见的 Student stu1 = new Student ();
                   Student stu2 = stu1 ;
这种形式的代码复制的是引用,即对象在内存中的地址,a 和 b 对象仍然指向了同一个对象。这种只能称为引用复制,两个引用指向的还是同一个对象.
如何实现克隆
        先介绍一下两种不同的克隆方法,浅克隆(ShallowClone)和深克隆 (DeepClone)。
        在 Java 语言中,数据类型分为值类型(基本数据类型)和引用类型,值类型包括 int、double、byte、boolean、char 等简单数据类型,引用类型包括类、接口、数组等复杂类型。基本类型的值可以直接复制,引用类型只能复制引用地址。所以浅克隆和深克隆的主要区别在于是否支持引用类型的成员变量的复制。

浅克隆和深克隆

浅克隆

        在浅克隆中,如果原型对象的成员变量是值类型,将复制一份给克隆对象;
        如果原型对象的成员变量是引用类型,则将引用对象的地址复制一份给克隆对象,也就是说原型对象和克隆对象的成员变量指向相同的内存地址。
        简单来说,在浅克隆中,当对象被复制时只复制它本身和其中包含的值类型的成员变量,而引用类型的成员对象并没有复制。
实现方式:
        1.在 Java 语言中,通过覆盖 Object 类的 clone()方法可以实现浅克隆。
        2.在 spring 框架中提供 BeanUtils.copyProperties(source,target);

深克隆

        在深克隆中,无论原型对象的成员变量是值类型还是引用类型,都将复制一 份给克隆对象,深克隆将原型对象的所有引用对象也复制一份给克隆对象。
        简单来说,在深克隆中,除了对象本身被复制外,对象所包含的所有成员变量也将复制。
        在 Java 语言中,如果需要实现深克隆,可以通过覆盖 Object 类的 clone() 方法实现,也可以通过序列化(Serialization)等方式来实现。
        序列化就是将对象写到流的过程,写到流中的对象是原有对象的一个拷贝,而原对象仍然存在于内存中。通过序列化实现的拷贝不仅可以复制对象本身,而且可以复制其引用的成员对象,因此通过序列化将对象写到一个流中,再从流里将其读出来,可以实现深克隆。需要注意的是能够实现序列化的对象其类必须实现Serializable 接口,否则无法实现序列化操作。
解决多层克隆问题
        如果引用类型里面还包含很多引用类型,或者内层引用类型的类里面又包含引用类型,使用 clone 方法就会很麻烦。这时我们可以用序列化的方式来实现对象的深克隆。

Java 设计模式(java design patterns)

设计模式概念

设计模式产生的背景
        "设计模式"最初并不是出现在软件设计中,而是被用于建筑领域的设计中。
        1977 年美国著名建筑大师、加利福尼亚大学环境结构中心主任克里斯托 夫·亚历山大(Christopher Alexander) 在他的著作《建筑模式语言:城镇、建筑、构造》中描述了一些常见的建筑设计问题,并提出了 253 种关于对城镇、邻里、住宅、花园和房间等进行设计的基本模式。
        1990 年软件工程界开始研讨设计模式的话题,后来召开了多次关于设计模式的研讨会。直到 1995 年,艾瑞克·伽马(ErichGamma)、理査德·海尔姆(Richard Helm)、拉尔夫·约翰森(Ralph Johnson)、约翰·威利斯迪斯(JohnVlissides)等 4 位作者合作出版了《设计模式:可复用面向对象软件的基础》一书,在此书中收录了 23 个设计模式,这是设计模式领域里程碑的事件,导致了软件设计模式的突破。这 4 位作者在软件开发领域里也以他们的“四人组”(Gang of Four,GoF)著称。
软件设计模式的概念
        软件设计模式(Software Design Pattern),又称设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题,以及该问题的解决方案。也就是说,它是解决特定问题的一系列套路,是前辈们的代码设计经验的总结,具有一定的普遍性,可以反复使用。
为什么要学习设计模式
        设计模式的本质是面向对象设计原则的实际运用,是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。
        正确使用设计模式具有以下优点。
                可以提高程序员的思维能力、编程能力和设计能力。
                使程序设计更加标准化、使软件开发效率大大提高。
                使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。
                能够更好的去理解源码架构。
        如果需要设计大型项目架构,我们必须考虑,当增加新的功能,代码变动成本最低;新增加功能不对以前功能进行影响,如果没有很好的设计,那么将会非常糟糕.

建模语言

        统一建模语言(Unified Modeling Language,UML)是一种用于软件系统分析和设计的语言工具,用于帮助软件开发人员进行思考和记录思路的结果.
        UML 图:通过不同的图形和符号,来描述软件模型以及各个元素之间的关系.
        类图(Class diagram)是显示了模型的静态结构,特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。
        在软件工程中,类图是一种静态的结构图,描述了系统的类的集合,类的属性和类之间的关系,可以简化了人们对系统的理解;类图是系统分析和设计阶段的重要产物,是系统编码和测试的重要模型。

        类是指具有相同属性、方法和关系的对象的抽象,它封装了数据和行为,是面向对象程序设计(OOP)的基础,具有封装性、继承性和多态性等三大特性。
        在 UML 中,类使用包含类名、属性和操作且带有分隔线的矩形来表示。
        (1) 类名(Name)是一个字符串,例如,Student。
        (2) 属性(Attribute)是指类的特性,即类的成员变量。UML 按以下格式表示:
                [可见性]属性名:类型[=默认值]
                例如:-name:String
        注意:“可见性”表示该属性对类外的元素是否可见,包括公有(Public)、私有(Private)、受保护(Protected)和朋友(Friendly)4 种,在类图中分别用符号+、-、#、~表示。
        (3) 操作(Operations)是类的任意一个实例对象都可以使用的行为,是类的成员方法。UML 按以下格式表示:
                [可见性]名称(参数列表)[:返回类型]
                例如:+display():void。
        学生类的 UML 表示。

接口

        接口(Interface)是一种特殊的类,它具有类的结构但不可被实例化,只可以被子类实现。它包含抽象操作,但不包含属性。它描述了类或组件对外可见的动作。在 UML 中,接口使用一个带有名称的小圆圈来进行表示。
        图形类接口的 UML 表示。

类之间的关系

        在软件系统中,类不是孤立存在的,类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列,UML 中的类图有以下几种关系:依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等,它们是最强的。

        依赖关系

        依赖关系是一种使用关系,它是对象之间耦合度最弱的一种关联方式,是临时性的关联。在代码中,某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类(被依赖类)中的某些方法来完成一些职责。
        在 UML 类图中,依赖关系使用带箭头的虚线来表示,箭头从使用类指向被依赖的类。下图所示是人与手机的关系图,人通过手机的语音传送方法打电话。

        关联关系

        关联关系是对象之间的一种引用关系,用于表示一类对象与另一类对象之间的联系,如老师和学生、师傅和徒弟等。关联关系是类与类之间最常用的一种关系,分为一般关联关系、聚合关系和组合关系。我们先介绍一般关联。
        关联又可以分为单向关联,双向关联,自关联。
        单向关联
        在 UML 类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址,这通过让 Customer 类持有一个类型为 Address 的成员变量类实现。
        双向关联
        从上图中我们很容易看出,所谓的双向关联就是双方各自持有对方类型的成员变量。
        在 UML 类图中,双向关联用一个不带箭头的直线表示。上图中在 Customer 类中维护一个 List<Product>,表示一个顾客可以购买多个商品;在 Product 类中维护一个 Customer 类型的成员变量表示这个产品被哪个顾客所购买。
        自关联

 

        自关联在 UML 类图中用一个带有箭头且指向自身的线表示。上图的意思就是Node 类包含类型为 Node 的成员变量,也就是“自己包含自己”。

聚合关系

        聚合关系是关联关系的一种,是强关联关系,是整体和部分之间的关系。
        聚合关系也是通过成员对象来实现的,其中成员对象是整体对象的一部分,但是成员对象可以脱离整体对象而独立存在。例如,学校与老师的关系,学校包含老师,但如果学校停办了,老师依然存在。
        在 UML 类图中,聚合关系可以用带空心菱形的实线来表示,菱形指向整体。
        下图所示是大学和教师的关系图:

组合关系

        组合表示类之间的整体与部分的关系,但它是一种更强烈的聚合关系。
        在组合关系中,整体对象可以控制部分对象的生命周期,一旦整体对象不存在,部分对象也将不存在,部分对象不能脱离整体对象而存在。例如,头和嘴的关系,没有了头,嘴也就不存在了。
        在 UML 类图中,组合关系用带实心菱形的实线来表示,菱形指向整体。下图所示是头和嘴的关系图:

继承关系

        继承关系是对象之间耦合度最大的一种关系,表示一般与特殊的关系,是父类与子类之间的关系,是一种继承关系,是 is-a 的关系。
        在 UML 类图中,继承关系用带空心三角箭头的实线来表示,箭头从子类指向父类。在代码实现时,使用面向对象的继承机制来实现继承关系。例如,Student 类和 Teacher 类都是 Person 类的子类,其类图下图所示。

实现关系

        实现关系是接口与实现类之间的关系。在这种关系中,类实现了接口,类中的操作实现了接口中所声明的所有的抽象操作。
        在 UML 类图中,实现关系使用带空心三角箭头的虚线来表示,箭头从实现类指向接口。例如,汽车和船实现了交通工具,其类图如下图所示。

面向对象设计原则

        在面向对象的设计过程中,首先需要考虑的是如何同时提高一个软件系统的可维护性和可复用性。这时,遵从面向对象的设计原则,可以在进行设计方案时减少错误设计的产生,从不同的角度提升一个软件结构的设计水平。

单一职责

        单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小。
        对于单一职责原则,可以理解为一个类只负责一个功能领域中的相应职责,即一个类不要负责太多“杂乱”的工作。
        在软件系统中,如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时设计或遭受到意想不到的破坏。
        以项目开发为例,如果项目组成员每个人的职责都很明确,可以专心开发自己负责的模块,则项目成果的质量往往很高。相反,如果职责不清晰,分工就会混乱。
        优点: 低耦合,高内聚

开闭原则

        开闭原则即对扩展开放,对修改封闭 。在软件系统开发过程中,软件的需求往往会随着时间的推移而发生变化。因此,进行软件设计时需要考虑怎样的设计才能面对需求的改变却可以相对保持稳定,从而使得系统可以在第一个版本以后不断推出新的版本,这时便可以以开闭原则作为指导。
        为了满足开闭原则,需要对系统进行抽象化设计 ,抽象化是开闭原则的关键。
        在进行软件设计时,一般先评估出最有可能发生变化的类,然后构造抽象来隔离那些变化。
        当变化发生时,无须对抽象层进行任何改动,只需要增加新的具体类来实现新的业务功能即可,实现在不修改已有代码的基础上扩展系统的功能,达到开闭原则的要求。
        优点:
                适应性和灵活性;
                稳定性和延续性;
                可复用性与可维护性;

里氏替换原则

        再说继承
                继承优势
                        提高代码的复用性(每个子类有拥有父类的属性和方法)
                        提高代码的可扩展性
                继承劣势
                        继承是侵入性的(只要继承,就必须拥有父类的属性和方法,体系结构复杂)
                        继承机制很大的增加了耦合性(父类被子类继承,父类功能修改会影响子类)
        里氏替换原则的提出1987 年由麻省理工学院计算机科学实验室的里斯科夫(Liskov)女士在“面向对象技术的高峰会议”上发表的一篇文章《数据抽象和层次》里提出来的,她提出:继承必须确保超类所拥有的性质在子类中仍然成立 .
        里氏替换原则主要阐述了有关继承的一些原则,也就是什么时候应该使用继承,什么时候不应该使用继承。里氏替换原是继承复用的基础,它反映了基类与子类之间的关系,是对开闭原则的补充,是对实现抽象化的具体步骤的规范。
        里氏替换原则的定义
                所有使用父类的地方必须能透明地使用其子类的对象。
                里氏替换原则表明,在软件中将一个基类对象替换成它的子类对象时程序将不会产生任何错误和异常。
                通俗地说,对于里氏替换原则,我们可作如下表述:任何基类可以出现的地方,子类一定可以出现。所以,子类可以扩展父类的功能,但不能改变父类原有的功能。换句话说,子类继承父类时除添加新的方法完成新增功能外尽量不要重写父类的方法。
里氏替换原则的主要作用
        里氏替换原则是实现开闭原则的重要方式之一。
        它克服了继承中重写父类方法造成的可复用性变差的缺点。
        它是功能正确性的保证。
        加强程序的健壮性,提高程序的维护性降低需求变更时引入的风险。

依赖倒置

        上层模块不应该依赖底层模块,它们都应该依赖于抽象.
        抽象不应该依赖于细节,细节应该依赖于抽象.
        是程序要依赖于抽象接口,不要依赖于具体实现。简单的说就是要求对抽象进行编程,不要对实现进行编程,这样就降低了客户与实现模块间的耦合。也就是针对抽象层编程,面向接口编程。

接口隔离

        使用多个接口,而不使用单一的总接口,不强迫新功能实现不需要的方法。

迪米特原则

        迪米特原则是1987年秋天在美国东北大学一个叫做迪米特的项目设计提出的,它要求一个对象应该对其他对象有最少的了解 ,所以迪米特法则又叫做最少知识原则.
        只和你的直接朋友交谈,不跟“陌生人”说话(Talk only to your immediate friends and not to strangers)
直接朋友:
        1. 类中的成员属性.
        2. 在类中的方法作为参数使用.
        3. 在类中的方法作为返回值类型.
注意事项:
        迪米特法则的核心是降低类之间的耦合;
        从被依赖者的角度来说,尽量将逻辑封装在类的内部,对外除了提供的public 方法,不泄露任何信息;
        从依赖者的角度来说,只依赖应该依赖的对象;
        切忌不要为了用而用;

组合/聚合复用原则

        优先使用组合,使系统更灵话,其次才考虑继承,达到复用的目的
        一般而言,如果两个类之间是"Has-A"关系应使用组合或聚合,如果是"Is-A"关系可使用继承。
        案例:现在假设有一个 A 类,里面有两个方法,有一个类 B,想要复用这两个方法,请问有几种方案?

总结

  • 开闭原则:要求对扩展开放,对修改关闭
  • 里氏替换原则:不要破坏继承体系
  • 依赖倒置原则:要求面向接口编程
  • 单一职责原则:实现类职责要单一
  • 接口隔离原则:在设计接口的时候要精简单一
  • 迪米特法则:只与直接的朋友的通信
  • 合成复用原则:尽量使用聚合和组合的方式,而不是使用继承
设计原则的核心思想
  • 找出应用中可能需要变化之处,独立出来,不要和不需要变化的代码混在一起
  • 针对接口编程,而坏是针对实现编程
  • 为了交互对象的松耦合设计而努力遵循设计原则:就是为了让程序高内聚,低耦合

猜你喜欢

转载自blog.csdn.net/m0_56492261/article/details/129802817