• 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 不过是对接口的一种实现而已,我们无法保证抽象类是顶层接口,它的若干实现并不一定具有普遍性——普遍性的依然是接口类。

  • 相关阅读:
    gray-code——找规律
    [LeetCode] Decode Ways 解码方法个数、动态规划
    操作系统之面试常考(转)
    国内90%以上的 iOS 开发者,对 APNs 的认识都是错的
    vim配置为IDE环境(超详细,极力推荐 git)
    curl的使用(from 阮一峰)
    图片鉴黄服务提供商
    转: 【理念篇】关于数据驱动运维的几点认识
    业务调度链的染色数据上报和关联
    ITIL的考核管理体系
  • 原文地址:https://www.cnblogs.com/brt3/p/9739197.html
Copyright © 2020-2023  润新知