叨逼叨

来源:互联网 发布:阿里云 域名查询 编辑:程序博客网 时间:2024/06/05 16:18

此处记录点零散的小idea,为了避免把csdn当微博,开一篇,都记在这里吧。

  • 感觉服务注册机制,貌似也是一种依赖注入。(虽然我还没完全搞懂依赖注入),理由呢:你需要一个模块的功能,该模块作为一个服务注册上,你就能用,没注册,你的服务请求失败,这样不会出现连build都不过的情况,也达到了解耦的目的,而依赖注入貌似也是帮你完成某个对象的装配,我们可以通过控制依赖注入来灵活的配置装配对象,这样功能的变更不会影响到你的模块,依赖注入配置下就好了,同样目的是解耦。

  • 依赖注入的优势,有时构造一个对象时,很可能这个类的初始化依赖很多其他的类对象,这样一个个都初始化好了,然后再初始化我们需要的类,导致关系复杂,其他不太关心的对象都要了解它的构造过程,而依赖注入可以解决这个问题,不关心具体的组装流程。
    “大多数面向对象编程语言,在调用一个类的时候,先要实例化这个类,生成一个对象。如果你在写一个类,过程中要调用到很多其它类,甚至这里的其它类,也要“依赖”于更多其它的类,那么可以想象,你要进行多少次实例化。这就是“依赖”的意思。依赖注入,全称是“依赖注入到容器”, 容器(IOC容器)是一个设计模式,它也是个对象,你把某个类(不管有多少依赖关系)放入这个容器中,可以“解析”出这个类的实例。所以依赖注入就是把有依赖关系的类放入容器(IOC容器)中,然后解析出这个类的实例。仅此而已。”
    作者:唐思
    链接:https://www.zhihu.com/question/32108444/answer/54773302
    来源:知乎
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

  • builder参数构建:初始化时有很多参数,都通过构造函数设置,有时发现某些参数不需要,也要传递,导致代码写了很长很多,很多参数只能设置是null,不想写null,又要写很多不同参数构造函数,所以通过builder更灵活。

  • 浅谈天猫tangram框架
    天猫开源的tangram框架,十分适合电商平台的商品展示,方便业务的运营,但是它不支持那种卡片内有click button的处理,一般都是一整张卡片一个处理,不适合一些功能性卡片的开发。不过目前没看到有什么好的库和框架,导致recyclerview写的很烦,有个BRVAH(BaseRecyclerViewAdapterHelper)貌似可以简化写recyclerview的烦恼。不够貌似不是很知名,不太敢用。吐槽一下,android app开发都发展的过气了,很多很基础的功能的库竟然还这么不完善,一些逻辑的处理要写的很复杂,层层嵌套的,套用调侃前端的一句话,要感谢这些app(前端)开发人员,在这么混乱的框架下,仍然写出了这么多“优秀”的程序。

  • 我们写代码,究竟是在写什么?
    什么是代码,什么是技术?其实编程只是一门工程,和科学不太搭边,做科学研究的只是在利用编程手段完成一些计算处理。而大部分靠编程吃饭的人,都更关注工程方面,而工程方面,主要的关注点在于对业务的抽象能力,如果将复杂的业务抽象分类成一个个简单的模型。这个应该是考察一个工程师最重要的能力,而其他领域知识,是”技“的范畴,是一个时间,经历的积累过程。

  • 想不通android里面fragment竟然不能处理back pressed事件。
    我是个很tmd能挑刺的人,对于android系统有些接口功能的设计,感到十分“恶心”,比如这个fragment不能处理back pressed事件,比如recyclerview竟然没有官方上拉刷新,没有一个好用的播放器控件(最近封装mediaPlayer都要吐了),很多人可能很坦然的接受,对于这个问题,我的观点:如果在前几年这些都能够接受,而现在android开发已经快”穷途末路“了,竟然很多东西都如此不完善,我并不是存粹的拿来主义,什么都别人做好拿来用,而是希望有良好的分工,基础功能分层,不涉及定制化很多,性能要求很高的基础组件尽量完善,让不同的开发人员处理各自领域的事情。而不是很多东西都从玩泥巴开始。另外对于很多开发者认为研究”底层“原理才牛逼,动不动就分析底层源码的行为,面试时更是动不动喜欢问实现机制的行为,十分不赞同,底层软件就真的高深吗,软件是一个把复杂问题抽象成简单问题的过程,代码是写的简单才牛逼,而不是复杂。不论上层业务还是底层基础软件都是考验抽象,分解,归纳的架构能力。本人之前从事”内核“”驱动“开发,经常遇到很多初生牛犊动不动就想写个操作系统什么的?我一直的观点就是:这个世界上不需要那么多操作系统。如果没有革命性的技术变革,你不过就是copy一份linux,缩小版的。站在巨人的肩膀上构建你的代码,当巨人病了的时候,再去研究巨人。我看过太多自己的业务代码写的一团糟,模块分离不清,各种耦合,重复代码,却整天想着研究底层原理的开发者,先写好自己手头的代码,多看看设计模式吧。

原创粉丝点击