nesting interfaces

本文深入探讨了Java中接口的使用,包括私有接口的概念,实现接口时如何强制定义方法而不添加类型信息,以及接口的嵌套特性。通过具体代码示例,展示了不同类型的接口实现方式,以及它们在类中的作用范围限制。

knowledge:

1. interfaces can also be private. (see class A)

2. implementing a private interface is a way to force the definition of the methods in that interface without adding any type information (that is, without allowing any upcasting). (see class A)

3. interfaces can be nested within each other. nested interface can not be private. (see interface E)

4. notice that when we implement an interface, we are not required to implement any interfaces nested within. Also, private interfaces cannot be implemented outside of their defining classes.

for example:

// interfaces/nesting/NestingInterfaces.java
// (c)2017 MindView LLC: see Copyright.txt
// We make no guarantees that this code is fit for any purpose.
// Visit http://OnJava8.com for more book information.
// {java interfaces.nesting.NestingInterfaces}
package interfaces.nesting;

class A {
  interface B {
    void f();
  }

  public class BImp implements B {
    @Override
    public void f() {}
  }

  private class BImp2 implements B {
    @Override
    public void f() {}
  }

  public interface C {
    void f();
  }

  class CImp implements C {
    @Override
    public void f() {}
  }

  private class CImp2 implements C {
    @Override
    public void f() {}
  }

  private interface D {
    void f();
  }

  private class DImp implements D {
    @Override
    public void f() {}
  }

  public class DImp2 implements D {
    @Override
    public void f() {}
  }

  public D getD() {
    return new DImp2();
  }

  private D dRef;

  public void receiveD(D d) {
    dRef = d;
    dRef.f();
  }
}

interface E {
  interface G {
    void f();
  }
  // Redundant "public":
  public interface H {
    void f();
  }

  void g();
  // Cannot be private within an interface:
  // - private interface I {} // error: illegal combination of modifiers: public and private
  private interface I {}
}

public class NestingInterfaces {
  public class BImp implements A.B {
    @Override
    public void f() {}
  }

  class CImp implements A.C {
    @Override
    public void f() {}
  }
  // Cannot implement a private interface except
  // within that interface's defining class:
  // - class DImp implements A.D {
  // -  public void f() {}
  // - }
  class EImp implements E {
    @Override
    public void g() {}
  }

  class EGImp implements E.G {
    @Override
    public void f() {}
  }

  class EImp2 implements E {
    @Override
    public void g() {}

    class EG implements E.G {
      @Override
      public void f() {}
    }
  }

  public static void main(String[] args) {
    A a = new A();
    // Can't access A.D:
    // - A.D ad = a.getD();
    // Doesn't return anything but A.D:
    // - A.DImp2 di2 = a.getD();
    // Cannot access a member of the interface:
    // - a.getD().f();
    // Only another A can do anything with getD():
    A a2 = new A();
    a2.receiveD(a.getD());
  }
}

references:

1. On Java 8 - Bruce Eckel

2. https://github.com/wangbingfeng/OnJava8-Examples/blob/master/interfaces/nesting/NestingInterfaces.java

Below is a short summary of each of the numbered steps shown in the diagram. Each of the blocks in Figure 360 is discussed in further detail in the next subsections. 1. Ingress timestamping: the device measures the ingress time of reception of every incoming packet. This measurement is performed in the MAC unit, and is thus highly accurate. If the packet is later detected as an OAM Delay Measurement (DM) packet, this timestamped is used for the DM mechanism. Otherwise, this timestamp is ignored. 2. Flow classification: An incoming OAM packet is identified either in the TTI or in the IPCL engine. In 802.1ag / Y.1731, typically each Maintenance Entity (ME) is defined as a different flow. For example, an 802.1ag ME can be identified as a TCAM rule that matches: • CFM EtherType • VLAN ID • Physical port The TTI/IPCL action then assigns: • <OAM Processing Enable> - Identifies the packet as an OAM packet, to be later processed by the OAM Engine. • <Flow-ID> - Maps each OAM flow to an entry in the OAM Table (refer to step 2 below). 2. Every packet that has <OAM Processing Enable> enabled triggers the OAM Table lookup. Each OAM flow is assigned a <Flow-ID> mapped to a specific entry in the OAM Table. The OAM Table contains a set of attributes that define how the OAM Engine processes the flow. For example: • The MEG Level of the configured MEP. • Attributes related to keepalive functions, such as Continuity Check Messages (CCM). • Attributes that determine whether Loss Measurement (LM) and Delay Measurement (DM) are enabled for the current MEP. 3. The OAM Engine performs • MEG Level (also known as MD Level) filtering. Each ME (flow) has a MEG Level that defines the nesting level in the OAM hierarchy. The MEG Level value is an attribute in the OAM Table entry. If the MEG Level in an OAM message is higher than the value in the OAM Table, the packet is forwarded without any OAM processing. If the packet’s MEG Level is lower than the one in the OAM Table, the packet is either dropped or trapped to the CPU, depending on a configurable mode. • Source interface filtering. It is possible to configure a source interface for each OAM flow. This filter verifies that the OAM packet arrived from its configured source interface. If the packet’s source interface is different than expected, a Source Interface exception is triggered. 4. The packet command of an OAM packet is determined according to the Opcode field in the CFM header, using an Opcode to Packet command mapping table. This allows different packet commands for different types of OAM packets. 5. Loss Measurement (LM) and Delay Measurement (DM) triggering: If the packet is an LM packet or a DM packet, the OAM engine determines whether it needs to be timestamped, or whether an LM counter needs to be incorporated in the packet. 6. Keepalive processing: the OAM Engine maintains the keepalive status of each flow. For example, in IEEE 802.1ag and Y.1731, flow keepalive is performed by Continuity Check Messages (CCM). The OAM Engine maintains a per-flow status, including the time of reception of the last keepalive message. Each flow has a configurable expiration time, so that if no keepalive is received for a flow during a period equal to the expiration time, the OAM Engine detects a link failure and notifies the application. 翻译解释下整合流程
最新发布
11-19
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值