语法
关于类属性的访问权限
对于Python来说，并不存在私有属性——虽然提供了一个双下划线的“人为定义”，这使得你在直接访问时获取到Exception，但这只是提示你，访问该属性是一个危险操作，应该规避这种访问方式——你还是可以获取到该内存。
如果只是开发一个exe程序，这个方式简单而高效——我们仅需要编译器告诉我们哪些访问是危险的。因为绝大多数情况下，我们既然设计了某个属性，就意味着它作为变量，是允许读写的——至于错误的读写，是用户使用不当的问题！
当然库（广义概念的库，包括统一程序中的辅助类、基类等）的开发就是另一码事儿了。当某一个对象与外界交互时，外界并不需要知道你的所有细节——接口就够了，包括接口函数和接口属性。其他的，是你内部设计的问题，与外界无关。
这里的外界，还包括两部分——纯粹的外部系统，以及拓展子类。
C# 中，关于属性，有以下几种形式：
- Filed
- Property
- Index
- Attribute
Field，应该作为内部的变量，仅供类内使用（包括protected继承给子类）。所以一般定义为 protected string _abc;
Property 只读接口：
- public string abc => _abc，表示提供 _abc 的访问接口，但不提供改写接口。
- public string abc{get;} ，创建一个属性，并且只提供访问（且子类无权限set），相当于 private string _abc; pulic string abc => abc;
Property 读写接口： publi string abc{get; set;}，这与定义一个Filed: public string abc 作用相同。不同的是，我们可以重写get/set访问器，来实现自定义的读写操作，如控制写入参数的范围。
注意，一般的Property都是public修饰，因为如果不需要外部访问或仅仅对子类开放，定义为 protected Filed 即可。
总结：C# 访问是按照外部访问权限定义关键字的，一般的，对于Filed，多定义为protected（除非严格禁止子类继承时，使用private），其作用是存储数据；而对于Property，一般定义为public，其作用是 存储数据+外部交互，使用时更像一个接口（函数）。
关于C#多态的思考
https://www.cnblogs.com/brt3/p/9744070.html
架构与模式
抽象类实现接口类的类型冲突（未解决）
在《设计模式：示例与思考》里介绍桥接模式时，遇到一个问题：最初我的设计是面向接口的：
public interface ISoftWare{ void run(); } public interface IHardWare{ void drive(); void software_install(ISoftWare software); void software_execute(); }
接着，我发现 ISoftWare 和 IHardWare 可以进一步实现：
public abstract class SoftWare: ISoftWare{ public HardWare env{get;set;} protected abstract void function(); // 软件功能代码（我们假设功能代码与环境无关，也就是Java跨平台特性） public void run(){ // run() 就是一个 Template Method. this.env.drive(); // 软件运行需要载入系统运行时 this.function(); } }
但在实现 HardWare 的抽象类时，遇到了问题：
public abstract class HardWare: IHardWare{ public SoftWare software{get;set;} public abstract void drive(); public void software_install(SoftWare software){ // we need change the ISoftWare to Abstract SoftWare this.software = software; this.software.env = this; } public void software_execute(){ this.software.run(); } }
由于 software_install 方法在实现时，需要定义属性 software 的属性值，但对于 IHardWare，它并不知道 software 属性的存在。
那么要想编译成功，我们就需要将接口改成 SoftWare 对象。但 interface 去依赖 ConcreteClass？这个并不合理。
没办法，只能选择了 HardWare 不再实现接口——但这个实现在逻辑上是有意义的：我们面向接口编程，而 HardWare 不过是对接口的一种实现而已，我们无法保证抽象类是顶层接口，它的若干实现并不一定具有普遍性——普遍性的依然是接口类。