美文网首页
android SOLID 代码整洁之道的知识点总结

android SOLID 代码整洁之道的知识点总结

作者: ahking17 | 来源:发表于2024-08-22 09:43 被阅读0次

    SOLID 首字母缩写

    S:single responsibility
    O: Open Close principle. open for extension but close for modification.
    L: liskov substitution
    I: Interface Segregation /ˌseɡrɪˈɡeɪʃ(ə)n/
    D: Dependency Inversion should depend on abstraction and not on concretion

    举例说明 S

    RecyclerView的adapter类中

    在onBindViewHolder()方法中, 从bean中取数据给view设值. 但很多代理中, 都会在onBindViewHolder()方法中, 对数据进行再次加工, 进行逻辑判断处理, 这就违反了S原则, 应该把数据加工部分单独拿到其他类中去完成.

    方法中的功能中, 有一部分子功能在项目的其他位置也存在复用的可能性

    例如下面的方法, 把字符串保存为文件这个子功能, 就应该单独抽离出来作为单独的类.


    image.png

    改造后:


    image.png image.png

    也可以这么理解S原则, 我们将功能定义为“改变的理由”。如果你在修改一个类的时候有多个动机,那么这个类就有多个功能。
    以上面这个例子为例, 我们可能改变登录方式的实现, 也可能会去改log文件的名称. 因此就有了2个可能要改变的理由, 这时候就应该把其中一个功能做抽离出来作为单独的类去实现.

    举例说明 O

    以上面的FileLogger类为例, 项目中可能有某个模块需要把log存储在单独的一个文件中, 这时候如果简单把errors.txt改为errors2.txt会影响其他模块的log存储. 如果改FileLogger类, 新加个方法logError2()那其实就是违反了这条Open Close principle.
    因此可以做下面这样的修改, 把FileLogger改为抽象类.


    image.png

    举例说明 L liskov substitution 里氏替换原则

    就是说子类不能把破坏父类已经定义好的功能. 这里有2层意思, 1是子类在override父类的方法时, 不能把方法实现的功能做完全概念上的改变. 2是父类已经对某个功能做了方法上的实现, 子类需要重写这个功能, 只能override父类的这个方法来实现, 而不能去新添加一个其他名称的方法去实现, 因为这么做的话, 作为类的调用者来说, 会很迷惑很容易调用错方法名称.
    下面是一个错误案例, 应该通过override父类的logError()去实现这个功能.


    image.png

    举例说明 I 接口分离原则

    该原则指出一旦一个接口变得很臃肿,那么就有必要将它拆分成更小的接口,这样客户端只需要了解和它相关的方法。
    下面是典型案例, Android中View类的OnClickListener接口.

    public interface OnClickListener {
        void onClick(View v);
        void onLongClick(View v);
        void onTouch(View v, MotionEvent event);
    }
    

    作为调用者来说, 可能只需要处理onClick()事件, 但却不得不去给onLongClick()和onTouch()一个空的实现体. 这时候就需要把一个大接口拆分为多个小接口去使用, 方便调用者的使用.

    // Fix of Interface Segregation principlepublic.
    public interface OnClickListener {
        void onClick(View v);
    }
    public interface OnLongClickListener {
        void onLongClick(View v);
    }
    
    public interface OnTouchListener {
        void onTouch(View v, MotionEvent event);
    }
    
    

    D: Dependency Inversion 依赖反转规则

    Dependency Inversion should depend on abstraction and not on concretion.
    是指上层的模块不应该依赖于底层的模块, 而是应该依赖于抽象。
    以上面的auth登录为例, 如果直接依赖FirebaseAuth实例, 以后可能use our own backend, 再做替换就需要修改很多代码. 这时候需要把依赖具体实现类改为依赖接口的方式.


    image.png

    这样改还有一个好处是今后使用依赖注入hilt的时候会特别的方便.


    image.png

    refer to:
    https://blog.csdn.net/weixin_42509931/article/details/117598128
    https://www.youtube.com/watch?v=t8VTLxMsufU

    --- done.

    相关文章

      网友评论

          本文标题:android SOLID 代码整洁之道的知识点总结

          本文链接:https://www.haomeiwen.com/subject/gwbikjtx.html