最近在学习演化一款游戏项目框架时候，框架作者巧妙使用接口中方法的显式实现来变相对接口中方法进行“密封”，增加实现接口的类访问方法的“成本”。
先定义一个接口，接口中有这两个方法。
public interface ICanSingSong
{
void SingJayChow();
void SingOther();
}
接下来我们让InterfaceDesignExample 继承该接口。使用常用的隐式实现方法来实现SingJayChow方法，在Start函数中直接可以调用，而使用显式实现的接口方法SingOther，则需要将类的实力转换为接口类型才可以调用。
这样相当于告诉类，ICanSingSong.SingOther()样式就是表明SIngOther是属于ICanSingSong接口中的“私有方法”。调用时候先要将类类型转换为接口。
public class InterfaceDesignExample : MonoBehaviour,ICanSingSong
{
void Start()
{
//接口的隐式实现 可以直接调用
SingJayChow();
//显示调用则需要 准换成接口 调用
//this.SingOther();
(this as ICanSingSong).SingOther();
}
/// <summary>
/// 接口的隐式实现
/// </summary>
public void SingJayChow()
{
Debug.Log("你说家是唯一的城堡，随着稻香一路奔跑~");
}
/// <summary>
/// 接口的显式实现
/// </summary>
void ICanSingSong.SingOther()
{
Debug.Log("lalalalalalallalaal!");
}
}
我们这样做的目的之一就是为了增加类对接口中的一些方法的调用成本，和使用“private”修饰有类似效果，降低对方法乱用的可能。
同样，我们先声明一个接口：
//接口 Application
public interface IApplication
{
void Start();
void Update();
void Destroy();
void Test();
}
抽象类继承该接口，并对生命周期函数进行显式实现，而供子类继承实现的方法为OnXXX
//抽象类
public abstract class Application : IApplication
{
//不希望子类去访问实现接口的方法
//使用显式调用
void IApplication.Start()
{
OnStart();
}
void IApplication.Update()
{
OnUpdate();
}
void IApplication.Destroy()
{
OnDestroy();
}
public void Test()
{
Debug.Log("我是测试方法，隐式实现接口的方法，子类可以轻松访问我");
}
//希望子类的实现的方法
public abstract void OnStart();
public abstract void OnUpdate();
public abstract void OnDestroy();
}
继承抽象类的子类对生命周期函数进行实现：
//子类
public class SubApplication : Application
{
public override void OnStart()
{
Test();
//Start(); 情况会发生递归调用 造成堆栈溢出 而此方法使用现实实现 所以在子类中无法访问 避免情况发生
Debug.Log("OnStart");
}
public override void OnUpdate()
{
Debug.Log("OnUpdate");
}
public override void OnDestroy()
{
Debug.Log("OnDestroy");
}
}
最后我们调用函数：
//测试调用
//通过接口调用 显示实现的方法
IApplication application = new SubApplication();
application.Start();
application.Update();
application.Destroy();
//通过类 无法调用显示实现的方法 只能访问使用OnXXXX方法
Application application2 = new SubApplication();
application2.OnStart();
application2.OnUpdate();
application2.OnDestroy();
这样我们可以体会到接口作为高抽象层的存在，可以调用子类具体实现的生命周期函数，而子类却无法访问显示实现的接口中“私有”的生命周期函数。
咳咳~故事开始！
作为一个资深Jay迷，我同样认识一个自称曲库的小精灵【SongLibrary】，它最拿手的三首歌曲是晴天、彩虹和说好不哭.
//曲库
public class SongLibrary
{
public void SingSunny()
{
Debug.Log("晴天：刮风这天，我试着握你的手~");
}
//彩虹
public void SingRainbow()
{
Debug.Log("彩虹：你要离开，我知道很简单~");
}
public void SingNoCry()
{
Debug.Log("说好不哭：说好不哭让我走~");
}
}
这个小曲库精灵居住在抽象出的留声机中，我可以通过留声机来和它交流播放对应的歌曲。
public interface ISingAllSong
{
SongLibrary songLibrary { get; }
}
留声机上有三个按钮，对应播放歌曲，
播放晴天的按钮功能：
抽象出子接口来继承曲库接口，通过静态类拓展来调用曲库中对应方法播放歌曲。
public interface ISingSunny : ISingAllSong
{
}
//静态类拓展
public static class SingSunnyExtensions
{
public static void SingSunny(this ISingSunny self)
{
self.songLibrary.SingSunny();
}
}
同样的方式，两个子接口。两个继承子接口的静态类负责调用曲库中的方法：
//彩虹
public interface ISingRainbow : ISingAllSong
{
}
//静态类拓展
public static class SingRainbowExtensions
{
public static void SingRainbow(this ISingRainbow self)
{
self.songLibrary.SingRainbow();
}
}
//说好不哭
public interface ISingNoCry : ISingAllSong
{
}
//静态类拓展
public static class SingNoCryExtensions
{
public static void SingNoCry(this ISingNoCry self)
{
self.songLibrary.SingNoCry();
}
}
这样我们使用三个静态类来调用留声机【interface】中居住的精灵【class】的方法，实现三个按钮功能。
当我想听歌时候，我只需要按照我的需求，搭配继承对应的子接口即可播放对应的歌曲，不用怕我按下去的是晴天歌曲播放按钮而短路到播放其它的歌曲曲目。
这样保证，拿到对应的子按钮，只能播放对应的歌曲，保证曲目播放的有序性。
public class InterfaceRuleExample : MonoBehaviour
{
public class OnlySingSunny : ISingSunny
{
SongLibrary ISingAllSong.songLibrary { get; } = new SongLibrary();
}
public class OnlySingRainbowNoCry : ISingRainbow,ISingNoCry
{
SongLibrary ISingAllSong.songLibrary { get; } = new SongLibrary();
}
void Start()
{
var onlySingSunny = new OnlySingSunny();
onlySingSunny.SingSunny();
//不能访问
//onlySingSunny.SingRainbow()
//onlySingSunny.SingNoCry();
var SingRainbowNoCry = new OnlySingRainbowNoCry();
SingRainbowNoCry.SingRainbow();
SingRainbowNoCry.SingNoCry();
//无法访问
//SingRainbowNoCry.SingSUnny();
}
}
总结一下：
使用显示实现方式来对接口中方法进行实现，子类是无法直接调用的，需要将类转换为接口类型才可以调用。
同时如果接口中的方法不想让子类直接调用，可以让抽象类继承接口原生方法，在抽象类中进行方法声明供子类调用，避免子类对抽象层的直接交互。同时，使用静态类拓展来限制子接口对父接口中存在函数方法的访问，保证类对所需方法的规范使用。
也就是说，尽可能不让表层具象的类轻松的访问到抽象层的其它不需要的功能，即类需要什么就继承对应的子接口，实现对应功能即可，多余的功能不要访问。
当然也建议阅读一下官方社区对显式接口的实现的解释说明。
参考文章：