java入门，@interface

一、前言

  在看项目代码的时候，经常会看到@XXXX这样的写法，有的有参数、有的没有参数。

java.lang.annotation.Annotation 接口中有这么一句话，用来描述：所有的注解类型都继承自这个普通的接口（Annotation），注解的本质就是一个继承了 Annotation（注解） 接口的接口。

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.PARAMETER)
public @interface Param {
  /**
   * Returns the parameter name.
   *
   * @return the parameter name
   */
  String value();
}

 二、怎么字定义注解

1、元注解

@Target：注解的作用目标
@Retention：注解的生命周期
@Documented：注解是否应当被包含在 JavaDoc 文档中
@Inherited：是否允许子类继承该注解

@Target：用于指明被修饰的注解最终可以作用的目标是谁，也就是指明，你的注解到底是用来修饰方法的？修饰类的？还是用来修饰字段属性的。语法如下： 

@Target(value = {ElementType.METHOD})

 @Retention： 注解指定了被修饰的注解的生命周期。语法如下：

@Retention(value = RetentionPolicy.RUNTIME）

• @Documented 注解修饰的注解，当我们执行 JavaDoc 文档打包时会被保存进 doc 文档，反之将在打包时丢弃。
• @Inherited 注解修饰的注解是具有可继承性的，也就说我们的注解修饰了一个类，而该类的子类将自动继承父类的该注解。

2、定义个日志注解

​
import java.lang.annotation.ElementType; 
import java.lang.annotation.Retention; 
import java.lang.annotation.RetentionPolicy; 
import java.lang.annotation.Target; 
/** * 接口日志注解 * @see InterfaceLogAspect * */
 @Retention(RetentionPolicy.RUNTIME) 
@Target(ElementType.METHOD) 
public @interface InterfaceLog { String value() default ""; }
 
​

Java中的接口（Interface）和抽象类（Abstract Class）都是用于实现抽象的类型，但它们之间有一些关键的区别和关系。

关系：

接口和抽象类都可以包含抽象方法和常量。这意味着它们都可以被实现或继承，但不能被实例化。

区别：

1. 继承：

   • 抽象类可以被其他类继承。
   • 接口可以被任何类实现，而且一个类可以实现多个接口。

2. 方法：

   • 抽象类可以有非抽象的方法。
   • 接口只能包含抽象方法。

3. 常量：

   • 抽象类可以有常量。
   • 接口可以有常量，但这些常量必须在所有实现该接口的类中都有定义。

4. 设计理念：

   • 抽象类主要用于创建一个通用的超类，定义一些基础的行为和属性，而子类可以添加或覆盖这些方法和属性以实现具体的功能。这更接近于"is-a"关系。
   • 接口主要用于定义一组方法，这些方法可以在任何类中实现，不论这个类与接口有什么关系。这更接近于"can-do"关系。

5. 使用场景：

   • 当你想创建一个通用的超类，但不确定具体需要哪些方法时，可以使用抽象类。
   • 当你想定义一组可能被任何类实现的方法时，或者当你想定义一组方法，但不想这些方法有默认的实现时，可以使用接口。

java中接口的设计原则

在Java中，接口是一种抽象类型，用于定义一组规范或标准。设计接口时，应该遵循以下原则：

1. 单一职责原则（Single Responsibility Principle）：一个接口应该只包含一个职责，即只定义一个功能。这有助于提高代码的可读性和可维护性。
2. 开闭原则（Open/Closed Principle）：软件实体（类、模块、函数等）应该是可扩展的，但不可修改。对于扩展的部分应该是开放的，而对于修改的部分应该是封闭的。这意味着接口的设计应该考虑到未来的变化，以便支持新的实现类扩展。
3. 里氏替换原则（Liskov Substitution Principle）：子类型必须能够替换掉它们的基类型。这意味着如果一个程序使用了一个基类或接口，那么可以使用任何实现了该接口或继承了该基类的子类，而不会产生任何错误或异常。
4. 依赖倒置原则（Dependency Inversion Principle）：抽象不应该依赖于细节，细节应该依赖于抽象。这意味着应该使用抽象类或接口来定义依赖关系，而不是具体实现类。这有助于降低代码的耦合度，提高代码的可测试性和可维护性。
5. 接口隔离原则（Interface Segregation Principle）：不应该强迫客户依赖于他们不使用的接口。接口属于客户，不属于它所在的类层次结构。可以将大的接口拆分成更小、更具体的接口，以便只暴露客户需要的部分。
6. 迪米特法则（Law of Demeter）：一个类只应该知道它直接依赖的类和对象。这意味着在设计接口时，应该避免不必要的耦合度，只暴露必要的属性和方法。
7. 稳定依赖原则（Stable Dependency Principle）：包（类库、DLL）中的所有类对于同一类性质的变化应该是共同封闭的。如果一个包中的类发生了变化，那么所有使用该类的包也应该受到影响。
8. 稳定抽象原则（Stable Abstraction Principle）：包的抽象程度应该和其稳定程度一致。一个稳定的包应该也是抽象的，一个不稳定的包应该是具体的。
9. 共同封闭原则（Common Closure Principle）：包（类库、DLL）中的所有类对于同一类性质的变化应该是共同封闭的。这意味着如果一个包中的类发生了变化，那么所有使用该类的包也应该受到影响。
10. 共同重用原则（Common Reuse Principle）：如果重用了包（类库、DLL）中的一个类，那么就应该重用包（类库、DLL）中的所有类。这有助于保持代码的一致性和可维护性。

遵循这些原则可以帮助设计出更好的接口，提高代码的可读性、可维护性和可扩展性。