校长说的话,不是很懂但觉得很有道理的样子,记录下来
从抽象的角度来看,访问控制划分了抽象的边界。
一方面从语义上明确抽象的层次化:越公开的成员越接近抽象接口,越远离具体实现(我不是很懂)
另一方面从语法上施行双向保护 —— 既保护实现代码不受客户代码侵入,也保护客户代码不受实现代码变更的影响
从软件应变的角度来看,访问控制划分了代码修改的边界。
具体到Java上,
- 如果修改仅仅涉及private成员,那只要检查该类的源代码即可;
- 如果修改涉及package成员,只须检查该类所在的package内的所有类。虽然这些类可能很多,但仍可控制,毕竟package是封闭的;
- 如果修改涉及protected成员,则不仅要检查该类所在的package内的所有类,还须检查该类的子类,如果该类本身是public,涉及的类可以超出该package的范围,已难以真正掌控;
- 如果修改涉及public类的public成员,那就意味着任何类都可能调用该接口,也就可能因此而无法编译、运行和工作。
由此观之,访问控制越松的成员,辐射范围越广,软件重用的效率越高,承担的责任越大,修改的代价也越大,因而变化的可能性应该越小。
成熟的程序员对public和protected接口的设计一定是慎之又慎,往往在其上花的功夫更甚于具体代码的编写。