my questions of C#
语法
关于类属性的访问权限
对于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 不过是对接口的一种实现而已,我们无法保证抽象类是顶层接口,它的若干实现并不一定具有普遍性——普遍性的依然是接口类。