我一直遵循使用访问修饰符和封装的流行约定，以确保一个类在实现错误时不会中断。但是，我注意到 OOP 确实不需要封装，使用访问修饰符实际上带来的麻烦多于好处。此外，通过不使用访问修饰符，您更像是一个 OO 程序员。我的推理如下。
Python 支持 OOP，但它不使用访问修饰符或封装。表明在 OOP 语言中访问修饰符不是强制性的。
尽管编译器更先进，但使用访问器方法与变量访问之间仍然存在纳秒级差异。在这样的受限系统中，
Android会极大地影响游戏的 FPS。（尽管在大多数情况下对方法使用 final 修饰符会显着减少纳秒差异）通过不使用私有或包修饰符，原始编码器的编码变得更简单、更快。该类的未来用户仍然可以使用公共接口，而不会破坏或使用类实现。此外，如果他希望修改或升级类，他仍然可以这样做并访问私有修饰符。打个比方，当您决定改装汽车时，您知道可能会破坏某些东西，但如果您愿意承担风险并知道自己在做什么，那么您就可以打开一个清晰的锁标志上写着（打开风险自负）比必须更换牢不可破的锁，锁定您要修改的部分要好。
我现在做的是混合用于公共接口的公共修饰符和用于实现细节的受保护修饰符，以便用户可以通过子类化来冒险。有什么理由我应该重新考虑这样做而不是传统的封装？