概述
在面向对象的程序设计语言中，类的设计对软件的整体架构而言影响非常深远。类的封装作为面向对象的三大基石之首，几乎所有的主流 OOP 程序设计语言都为其提供了诸如 private、protected 和 public 这三种访问限定修饰符，其目的无非是为了帮助类更方便地与外界进行一些必要的交流和沟通。可是，对于类的数据成员而言，一旦你为其声明了 public/protected 的访问限定，那么这一举措对你的中大型程序构建而言将是灾难性的。
一、数据的安全性引人忧虑
要深刻理解为什么 public/protected 如何可怕，就要首先明白封装的意义何在。
在曾经主流的面向过程的程序开发当中，代码的复用是函数级的，而在每一个函数当中所实行的都是过程式编码，这也就意味着在主函数当中的函数调用式编程亦是过程式的。在作用域的约束之下，为了使得不同的函数域都能够访问同一个变量，达到函数职能效益的最大化，往往将其声明为全局变量。这直接导致了任何的函数都将能够对其进行读和写的操作，对于数据的安全性而言这简直是当头一棒！在小型程序开发者的眼里，这点风险根本不足为惧，可是对于大型程序开发者来说，变量值的修改将完全不再受到开发者的掌控，值异常现象将有可能由庞大代码量中的任何一个操作该变量的默默无闻的小角落中产生。如此一来，大型程序的开发与维护变得举步维艰。
二、封装与 private 带来曙光
幸运的是，面向对象的编程范式应运而生了，类的封装不仅使得程序开发逻辑更加符合人的自然思考方式，代码也变得更加简洁、更具可读性了。更加重要的是，面向对象编程语言为我们提供了丰富的访问限定标识，数据的暴露与否终于不再非黑即白，而是变得更加可控了。开发人员终于可以在安全性与功能性之间找到平衡，男默女泪。
对于 private 而言，它绝对是帮助程序员编写稳固代码的最佳帮手。一旦你将类的某个数据成员声明为 private，也就对外宣布了主权：这个成员是我的私藏品，只有我才能够访问它！于此同时，你也可以通过为某一私有数据成员编写公有的 get/set 方法将其选择性地对外暴露，如此一来，你可以为你的数据成员对外创造出”不准访问“、”只读访问“和”读写访问“，你甚至还可以对外创造出一个”只写访问“的奇葩数据成员。
终于，你可以籍由 private 访问限定符随心所欲地将具有相关需求的数据成员对外暴露并且不必过分忧虑其安全问题，因为在访问限定的“继承体制”加持下，你的数据成员将一直保持着一个有所保留的矜持者形象，绝不允许被某些好心办坏事或是图谋不轨的不明代码肆意篡改。由此一来，每当你为你的数据成员显式地敲下私有的访问限定符，都是为将来维护阶段中无数个修 bug 的加班日夜争取了一些享受生活的美好时光。珍爱生命，我用 private。
三、public/protected 是复辟者
但是注意！不要因为 private 为我们带来一片利好，就不暇思索地也对其它访问限定符付出真心并委以重任，若如此你便身处险境了。事实上，在所有的访问限定修饰符当中，唯有 private 才是帮助开发人员维护代码稳定与数据安全的正规军，其它诸如 public 与 protected 等皆是旧制度下风险派的邪恶复辟者！这些囚徒们妄想冲出封装的牢笼，将你构建安全、稳定、低耦合代码的美梦砸个粉碎，并籍由编译器发声，在未来的某一天向你抛出一堆鲜红的 Errors 得意示威。
试想一下，如果你将一个数据成员的访问限定符声明为了 protected，这将意味着什么？这将意味着在未来，以这个类作为父类的所有派生类都将具有直接读写该成员的至高权利！你或许觉得“对啊，这正是我想要的，这对于我的开发而言应该是有利的吧“，因为你认为具有父子关系的两个类不再需要为安全性问题而夙夜忧患了，构建 get/set 围墙的工作好像失去了必要性。然而你所不知道的是，你的项目在你做出 protected 这一决定的时候已然搭上了贴有“维护困难”标签的班车，并且随着你敲下越来越多的 protected 关键字，你的项目也哼着小曲儿，随着你一起在驶向终点站 “无法维护” 的道路上所向睥睨。
在未来的某一天里，由于某些原因，被你指定为 protected 的那些数据成员需要转型为 private 时，所有继承并操作了这一成员的派生类就要喜提 Errors 了，因为它们无法再像以前一样直接操作这些数据，你需要将所有相关代码全部重写为以 get/set 的方式进行访问，甚至当这些数据成员被取消使用时，所有的访问代码都失去了意义。你看到了，一个基类 protected 数据成员的变更将破坏所有相关的派生类。而若你的数据成员声明的不是 protected 而是 public，又将有多少代码受到伤害？
对于数据成员而言，public/protected 在表面上光鲜亮丽，好像是”自由“与”开放“的崇尚者，然而实际上确实另一维度上的 “const”。可以说，它们不仅大大增加了代码修改与维护的难度，将数据与多个类使用胶水一般粘在了一起，还具有极其隐蔽的风险性，而规避这些问题最好的办法便是拒绝使用它们。
