【原创&交流】有关public接口和友元类的讨论

链接：有关public接口和友元类的讨论

  今天在公司的内部网和同事进行了一场有关public接口和友元类的讨论。

我：有时类接口要提供给外部类使用，但把它定义为public接口并不好，因为我觉得好的设计原则是一个类的public接口尽可能少。如果某一接口确实需要被外部的类调用。这时我认为把外部使用类声明为接口提供类的友元类是一个较好的做法。

同事王（下面简称王）：我感觉友元还不如公开接口。

我：友元就意味着对局部范围公开。

我：quote：我感觉友元还不如公开接口。怎么理解？

王：你能确定仅有一个类需要这样，以后不会有其它的类变成它的友元吗？就是说，宁愿使用public，而不是friend class。

我：为什么？如果照这样，pulic接口将会越来越多。

王：也不是，这个要具体分析。总体原则我是这样理解的。

我：我是说遇到我说的那种情况，我觉得使用友元类比使用public接口要好。如果某一接口只被另一个类使用的话。

同事李（下面简称李）：你能确定以后不会有其它的类也会用这个类吗？还是接口好些吧。

我：那以后有需要再变成public接口也可以的。

我：quote：还是接口好些吧。怎么个好法。

李：不是有句话叫：“针对接口编程，不针对实现编程”

我：我感觉有必要尽量避免public接口的膨胀。

李：不是吧，接口多没有关系呀，说明外面有需求，还有就是说明这个对象有这种行为。

我：接口多意味着一些问题。首先这个类的设计功能是不是单一；其次接口一多意味着外部使用的难度增大。

李：类是一个对象，某些对象它就有这么多的功能。成员变量不要公开就行的。

我：功能接口的访问权限有差别的。

李：什么意思？

我：比如private接口只能自己使用，protected接口在自己的继承体系内使用，public接口则无限制。

李：这我知道。这跟声明public有什么关系呀？如果只有自己使用，当然声明为private接口。关键是要把接口写好，写得方便使用。

我：我是说public接口不宜变多，如果它只是一个类使用的话，我感觉声明为友元类更好。

李：只要有其它类用最好用接口。这样减少耦合。因为这个对象里面的其它东西可能对另外的类用不到。

我：我不过是说是这个接口限制在友元类使用罢了。不知你们怎么理解的？

李：友元本来就是一种不好的设计关系。

我：不好在哪里？

李：把两个东西混到一起了。

我：不知道怎么混了。你声明和不把它声明，二者有耦合关系吗？

李：好了，不讨论了。

我：刚才激动了，等会上网查查友元的使用坏处。

李：没有事儿的，解决问题是王道。

我：嗯，是的，感觉这个问题讨论的意义不大，呵呵。

同事马：quote：友元就意味着对局部范围公开。A是B的友元，另一个类C：：fun(A&) 在C中也可以访问B的私有成员了。

我：C和A、B是什么关系？

同事马：没有关系。

我：quote：A是B的友元，另一个类C：：fun(A&) 在C中也可以访问B的私有成员了。
可以这样做吗？我得测试下。

同事张：友元是一个有争议的东西，可以用来提高封装，也可以用来破坏封装。

我的天呢，友元是尽量避免的C++effective上说的很清楚，增加了耦合性，
C：：fun(A&)就像这个例子，如果A是B得友元，你想想在函数内部，就可以通过A的接口来访问B的私有成员了，而这个接口是C得接口
所以友元是导致耦合最大的弊病，用户的用法千奇百怪，你能保证用户会老实的遵守你的意愿吗？我说的用户就是使用你设计的类的人，当然如果这整个方案都是你做的，你可以这样搞

  受教了，当时没想到这一层呢。

这个问题你是错的。试图通过友元去减少暴露的接口，恕我直言，这个想法有点幼稚。

友元类属于应当尽力避免的软件架构，它削弱了信息隐藏，破坏了封装，最致命的是与软件架构所追求的松散耦合度背道而驰。

类暴露的接口应当尽可能少，这是对的，是一个比较好的架构设计原则。但什么是少？什么是多？并不是只有1个接口的类就比有3个接口的类好，这得看具体的需求，不能满足需求的类，接口再少也没有用。

想法是好的，只是用错了方法。

学习了