因为够懒，所以我严守单一职责

其实想把6大原则放一起说的，但是写开了以后才发现，光一个原则就能扯出一大通东西来，还是分开说吧。

===========

哪里单一？

单一嘛，大家都懂的，只干一个事。

但是，哪里需要单一呢？只有类和接口？ 任何东西都要单一！容我给你从小了慢慢往大了扯~

变量要单一.

啊这个没疑问的吧，一个变量只干一件事，比如一个按钮不能又是播放按钮又是关机键。关机和开机放一起没关系，因为他们都是控制电源的。这里要提一点，既负责播放又负责关机这个设计只能说不好，但并不能说是错的。架构设计没有对与错之分！！！
方法要单一.

方法单一是单一这个原则最容易实现的一块。方法的单一体现在，一个方法干且只干下面类型中的一种事情：初始化的、View显示的、对象获取的、布尔判断的、逻辑分发的等等等。这是非常有利于代码阅读与代码修改的，后面我们详细讲。
接口要单一.

接口的不单一设计体现在：某个实现类不得不以空方法的方式实现一个接口里的方法。接口的一个功能是做隔离和解耦，接口的方法都是public，一个无用的public方法暴露给依赖类，对依赖类来说很容易产生误解的一件事，“你给我的，就是我都能用的，不要口头告诉我不要调用你这个方法。”
类单一？

这个地方就打问号了。为什么呢？因为类的单一太难界定了。连老外的大神都说了：“This is sometimes hard to see”。这个有时很难说。举例子吧：

我设计了一个在ListView为空的时候对用户提示的控件，我想把它设计成自给自足的，所以在这个控件里面做了逻辑判断，是不是为空呀，为什么为空呀。根据不同的判断结果，进行不同的样式展示。老大看了以后说不行了：“你这个东西设计的不单一啊！一个控件应该只负责显示，怎么能做业务逻辑处理呢？”我说：“这是一个单一的功能模块，不只是一个View。它是一个功能单一的东西，不是指责单一的。”

我俩谁对谁错？这个是争论不出来结果的。所以，还是看情况！
包要单一.

包单一有助于项目的开发，没有人愿意维护一个结构乱七八糟的项目。

如何做到单一？

说完了哪里单一，我们讲讲如何做到单一。单一说着很简单，但其实对于新手来说，并不是那么容易，因为实际业务太多样了，一定要讨论这个事情，不亚于哲学家开辩论会！！

大胆写，随便写。写完才能改嘛。

我有一个习惯，代码写完 3 ~ 5 次自Review。说来惭愧，只是担心被现在的同事和未来的同事嫌弃。因为知道自己会Review这么多次，所以不会考虑太多。（真心的，考虑太多就不用写了，计划赶不上变化）。等到写完了，Review之后你会发现很多问题，开始改，这一改，你就知道了，这样写才是更好的，下次就记住了。

而且优化代码是一件成就感爆棚的事情哦~
怎么改？捷径：消除重复。

当你的一段代码重复出现超过两次以后，你就要开始考虑是不是设计上有问题了，因为出现了超过两次，你很难保证，将来不会出现更多次。

对代码有追求的猿，是拒绝重复的！
- 方法级单一实现：将所有重复的代码段按上一节【方法要单一】中讲的类型分门别类的放到不同方法里。这是一件简单粗暴的事情，做完它，你就发现你的代码焕然一新。
- 接口接的单一实现：同样对于初级程序猿来说，接口的设计也是满路荆棘。讲几个经验吧。
  - 当你的某个实现类实现这个接口以后发现有空的无用接口方法，改！拆接口！
  - 在外部类依赖你的实现类时，有无关public方法暴露，用接口进行隔离吧。
  - 可以关注下官方API的接口都在做什么，照着来吧，一般都没错的。
- 类的单一：这个还是像上面的说的：This is sometimes hard to see。但还是有几个雷区是一定要避免的。
  - 珍爱生命，远离业务。抽离所有的业务逻辑，单独管理，这些由产品经理决定的东西~珂珂！
  - 继承是侵入式的，很可能让你类不知不觉多了一些不应该多的东西。
  - 对于View控件来说，ListView是一个比较好借鉴的榜样。ListView本身只负责Item的显示和回收利用，Adapter负责逻辑，决定Item长什么样。

单一后的样子

最后我们讲讲单一以后的样子，看看你能不能交上一份好的成绩单。（话说这个成绩单应该能保证你及格吧？）

没有超过两次以上的重复代码段。（你看有多懒，不愿意重复写）
在你有需求变动的时候，只改一个地方就好了。（你看有多懒，不愿意多改几个地方）
暴露给依赖类的方法，都是可以用的。（你看有多懒，都不想动脑子）
方法代码行不超过一屏。（你看有多懒，都不想上下滚动下屏幕）

（不要较真，某些情况真的是避免不了的。原则，有时也是用来打破的）

因为够懒，所以我严守单一职责相关推荐

理论一：对于单一职责原则，如何判定某个的职责是否够“单一”？
上几节课中,我们介绍了面向对象相关的知识.从今天起,我们开始学习一些经典的设计原则,其中包括,SOLID.KISS.YAGNI.DRY.LOD等. 这些设计原则,从字面上理解,都不难.你一看就感觉懂了 ...
三、单一职责原则、开放-封闭原则、依赖倒转原则
一.单一职责原则 1.定义:就一个类而言,应该仅有一个引起它变化的原因. 2.为什么要?:如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力 ...
嘻哈说：设计模式之单一职责原则
1.定义首先呢,我们来看一下单一职责原则的定义. 就一个类而言,应该只有一个引起它变化的原因这个说法不是很好懂,有一些抽象,不过呢,我们依旧可以尝试着理解一下. 就一个类而言,只有一个引起它变化的 ...
寂然解读设计模式 - 单一职责原则
I walk very slowly, but I never walk backwards 设计模式 - 单一职责原则寂然大家好,我是寂然,本节课呢,我来给大家介绍设计模式原则之单一职责原则 ...
设计模式之禅(读后感悟随笔)-单一职责原则
一直以来,自己读过的技术类书籍也不少了,但是都犯了一个毛病就是没有很好的记录下来,有些东西可能并不是平日开发中时时刻刻用到的,随着时间的延长,学过的东西慢慢也就淡忘了,刚好最近有些时间,也正打算把&l ...
经典设计原则：单一职责原则（SRP）
本文详解设计原则中的单一职责原则,目的还是提高代码的可读性.可扩展性.复用性.可维护性等. 目录 1. 单一职责原则(SRP) 2. 如何理解单一职责原则? 3. 如何判断类的职责是否足够单一? 4. ...
设计模式-02.经典设计原则-第一节-单一职责原则，开闭原则，里式替换，接口隔离【万字长文系列】
文章目录设计模式经典设计原则-第一节单一职责原则(SRP) 如何理解单一职责原则? 如何判断类的职责是否足够单一? 类的职责是否设计得越单一越好? 开闭原则(OCP) 如何理解"对扩展开 ...
六大设计原则-单一职责原则
1.开闭原则 2.接口隔离原则 3.依赖倒置原则 4.迪米特原则 5.里氏替换原则 6.单一职责原则单一职责原则针对的问题类T负责两个不同职责:职责 ...
六大设计原则之单一职责原则（SRG）
在做代码练习或者开发的过程中,我们会发现自己写的类越来越大,该类的功能也越来越多.有一些开发者包括之前的我看到自己写的类够大,功能够多是往往会充满自豪感.但是当某个功能需要做一个小改动时,就会发现整个 ...
设计模式中遵循的原则：单一职责、开发-封闭、依赖倒转
设计模式中遵循的原则:单一职责.开放-封闭.依赖倒转单一职责原则一个类而言,应该仅有一个引起它变化的原因. 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或者抑制这 ...

因为够懒，所以我严守单一职责

因为够懒，所以我严守单一职责

哪里单一？

如何做到单一？

单一后的样子

因为够懒，所以我严守单一职责相关推荐

最新文章

热门文章