设计模式总结

简单工厂模式

通过简单的工厂类将对象实例的构建工作统一交给工厂类处理,从而避免在客户端因为构建实例而产生过于负责的逻辑代码.

优点:

判断逻辑提取到了工厂类中,减轻了客户端的工作,减少了客户端对具体产品的依赖.

缺点:

工厂模式类中需要逻辑判断(switch-case),新添加逻辑的时候需要更改工厂类,违反了开闭原则.switch可以通过反射的方式去除

工厂方法模式(Factory Method)

工厂方法模式,定义一个用于创建对象的接口,让子类决定实例化哪一个类.工厂方法使一个类的实例化延迟到其子类.

优点:

相比于简单工厂模式,工厂方法模式通过对多态的应用成功的分解了”生成哪个类”的逻辑判断,拆解了switch的判断语句,使得代码有更高的可读性同时也更容易进行修改.

缺点:

工厂方法模式虽然使得代码可读性更高,但是判断重新抛给了客户端,增加了客户端的复杂度.同时,如果有新的逻辑依然需要对客户端进行修改,违反开闭原则.

抽象工厂模式(Abstract Factory)

抽象工厂模式(Abstract Factory),提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类.

优点:

• 易于交换产品系列,由于具体工厂类在一个应用中只需要在初始化的时候出现一次,使得改变具体工厂变得非常容易,它只需要改变具体工厂即可使用不同的产品配置.
• 它让具体的创建实例过程与客户端分离,客户端是通过他们的抽象接口操纵实例,产品的具体类名也被具体工厂分离,不会出现在客户端代码中.

缺点:

增加新产品的时候需要同时增加一个抽象产品和数个具体产品,以及修改抽象工厂和具体工厂,涉及到改动太多,不利于维护.

改进:

利用发射将抽象工厂模式的工厂部分修改为简单工厂模式,通过反射来生成具体的产品.

策略模式

策略模式定义了算法家族,分别封装起来,让他们之间可以相互替换,此模式让算法的变化,不会影响使用算法的客户.

场景:

商场活动打折计费/类似的不同时间对应不同业务规则的业务场景

优点:

1.策略模式的算法的多个算法继承父类的时候,可以将各个算法公共的逻辑上提到父类,通过继承复用.

2.减少了算法类之间的耦合

3.方便算分类各自进行单元测试.

缺点:

单一的应用策略模式依然无法在做算法选择的时候避免switch条件判断,基本策略模式只是简单的把判断剥离了客户端,添加新的算法的时候依然违背开闭原则.需要与抽象工厂模式进行一起使用才能避免这种情况.

装饰者模式

装饰者模式,动态地给一个对象添加一些额外的职责,就增加功能来说,装饰者模式比生成子类更加灵活.

场景:

英雄联盟红蓝buff/系统添加新功能,需要向旧类添加新的代码以对原有类的核心职责或主要行为进行装饰(扩展).

优点:

将装饰代码从原有类中搬移出去,简化了原有类,避免原有类的业务逻辑过于复杂.
有效的把类的核心职责和装饰功能区分开,而且可以去除相关类中重复的装饰逻辑.

缺点:

部分情况下需要注意装饰顺序,尽量在使用装饰类相互独立的情况下使用装饰者模式.

代理模式(proxy)

代理模式(proxy),为其他对象提供一种代理以控制这个对象的访问.

场景:

1.远程代理,也就是为一个对象在不同的地址空间提供局部代表.这样可以隐藏一个对象存在于不同地址空间的事实(??)

2.虚拟代理,是根据需要创建开销很大的对象.通过它来存放实例化需要很长时间的真是对象.

3.安全代理,迎来控制真实对象访问时的权限.

4.智能指引,是指调用真实的对象时,代理处理另外一些事.

原型模式(Prototype)

原型模式(Prototype),用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象.

场景:

需要处理”复制”对象功能的场景,对象的所有信息都不需要改变,这时候”克隆”原型能共隐藏新对象的创建细节.

优点:

隐藏了具体的”创建”细节,对客户端友好.合理设计可能会降低对象初始化的资源消耗.

缺点:

对象内部有引用类型的时候,需要考虑深拷贝与浅拷贝的问题.

模板方法模式(TempleteMethod)

模板方法模式,定义一个操作中的算法骨架,而将一些步骤推迟到子类中.模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定模式.

场景:

项目增删改查架构搭建

优点:

1.模板方法很好的体现了继承方式的应用.相同的情况父类处理,不同的情况子类特殊处理.提高了代码的复用又兼顾到特殊情况特殊处理.

2.在日常开发中可以通过模板方法管理架构,技术负责人定义公共的骨架,开发人员根据不同的业务逻辑来处理自己特殊的逻辑.

缺点:

因为父类一些方法采用了abstract修饰,使得子类即使没有特殊逻辑也必须重写这些方法.如果在业务逻辑特殊情况不是很多的时候,可以考虑不使用模板方法,而是子类单纯的重写父类的方法,通过单纯的继承来处理.

外观模式(Facade)

外观模式(Facade),为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用.

场景:

• 在设计初期阶段,应该要有意识的将不同的两个层分离.
• 开发阶段,子系统往往因为不断的重构演化变得越来越复杂,只是会增加外观Facade可以提供一个简单的接口,减少他们之间的依赖.
• 在维护一个遗留的大型系统时,可能这个系统已经非常难以维护和扩展了,为新系统开发一个外观Facade类,用来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口,让新系统和Facade对象交互,Facade与遗留代码交互所有复杂的工作.

建造者模式(Builder)

建造者模式(Builder),又称为生成器模式,将一个复杂对象的构建与他的表示分离,使得同样的构建过程可以创建不同的表示.

场景:

• 例如麦当劳汉堡的制作.客户作为客户端只需要告知服务员(指挥者)需要什么类型的汉堡,服务员按照流程组装各流水线员工(具体创建者)生产的汉堡组成部分(具体产品产品)
• 床架这模式是在(当创建复杂对象的算法(指挥者负责)应该独立于该对象的组成部分(具体产品)和以及他们的装配方法(具体建造者实现的抽象建造者定义的抽象方法))时使用的模式.

观察者模式(Observer)

观察者模式(Observer)又叫做发布-订阅模式(Publish/Subscribe)模式,定义了一种一对多的依赖关系,让多个观察者对象同时监听一个主题对象.这个主题对象在状态发生变化时,会通知所有观察者对象,是他们能够自动更新自己.

场景:

• 当一个对象改变的时候需要改变其他对象,但是它并不知道具体需要改变多少个对象的时候应该考虑用观察者模式.
• 当一个抽象模型有两个方面,其中一个方面依赖于另一个方面,这时可以用观察者模式将这两者封装在独立的对象中,使他们各自独立的改变和复用.

优点:

观察者模式让耦合的双方都依赖于抽象,而不是依赖于具体,从而使各自的变化都不会影响另一边的变化.遵循了依赖倒转原则.

状态模式(State)

状态模式(State),当一个对象的内在状态改变时允许改变其行为,这个对象看起来对象是改变了其类.

场景:

审批流程/当一个对象的行为取决于它的状态,并且它必须在运行时刻根据状态改变它的行为时,就可以考虑使用状态模式.

优点:

• 当控制一个对象状态转换的条件表达式过于负责的时候,把状态的判断逻辑转移到表示不同状态的一系列类当中,将复杂的判断逻辑简化.
• 将与特定状态的相关行为局部化,并且将不同状态的行为分割开来.
• 由于各个状态的逻辑分布到state的子类之间,减少了相互间的依赖.

适配器模式(Adapter)

适配器模式(Adapter),将一个类的接口转换成客户希望的另一个类的接口.Adapter模式使得原本由于接口不兼容而不能一起工作的类可以一起工作.

场景:

• 系统的数据和行为都正确,但接口不符时,可以考虑使用是适配器,目的是使控制范围之外的一个原有对象与某个接口匹配.
• 用于希望服用一些现存的类,但是接口又与复用环境要求不一致的情况.
• 使用一个已经存在的类,但是它的接口,也就是它的方法和你的要求不相同时
• 两个类所做的事情相同或相似,但是具有不同的接口.
• 双方都不太容易修改的时候.

适配器模式应该在无法重构或者重构代价太大的时候一如使用.在重构很容易的时候,重构优于引入适配器模式.

备忘录模式(Memento)

备忘录(Memento),在不破坏封装性的前提下,不活一个对象的内部状态,并在该对象之外保存这个状态.这样以后可以将该对象恢复到原先保存的状态.

场景:

• 游戏存档
• Memento 模式比较适用于功能比较复杂,但是需要维护或记录属性历史的类,或者是需要保存的属性只是众多属性众多一部分时,Originator 可以根据保存的Memento信息还原到前一状态.

优点:

备忘录可以把复杂的对象内部信息对其他的对象屏蔽起来.

组合模式(Composite)

组合模式(Composite),将对象组合成树形结构以表示’部分-整体’的层次结构.组合模式使得用户对单个对象和组合对象的使用具有一致性.

场景:

• 总公司子公司问题/父子菜单问题.
• 需求中是体现部分与整体层次的结构
• 希望用户可以忽略组合对象与单个对象的不同,统一的使用组合结构中的所有对象

优点:

组合模式让客户可以一致地使用组合机构和单个对象.

迭代器模式(Iterator)

迭代器模式(Iterator),提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露该对象的内部表示.

场景:

 当前java的所有容器类基本都实现了这种设计模式.

优点:

分离了集合对象的遍历行为,抽象出一个迭代器来负责,既可以做到不暴露集合内部结构,又可以让外部代码透明的访问集合内部的数据.

java的foreach循环最后就是通过迭代器实现的,foreach的写法只是语法糖.

单例模式(Singleton)

单例模式(Singleton),保证一个类仅有一个实例,并提供一个访问它的全局访问点.

桥接模式(Bridge)

桥接模式(Bridge),将抽象部分与它的实现部分分离,使它们都可以独立地变化.这里的抽象和实现分离,并不是指让抽象类与其派生类分离,而是指的是抽象类和它的派生类用来实现自己的对象

命令模式(Command)

命令模式(Command),将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化,对请求进行排队或者请求日志,以及支持可撤销操作.

优点:

• 很容易设计一个命令队列
• 在需要的情况下,可以较容易的将命令记入日志
• 允许接收请求的一方决定是否要否决请求
• 可以容易地实现对请求的撤销和重做
• 由于新建的具体命令类不影响其他类,因此增加新的具体命令类很容易.

职责链模式(Chain of Responsibility)

职责链模式(Chain of Responsibility),使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系.将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象出处理它为止.

场景:

审批权限

优点:

• 接受者和发送者都没有对方的明确信息,且链中的对象自己也并不知道链的结构.结果是职责链可以简化对象的相互连接,它们仅需要保持一个指向其后继者的引用,而不需要保持它们所有的候选接受者引用.大大降低了耦合度.
• 可以随时地增加或者修改处理一个请求的结构,增强了给对象指派责任的灵活性.

缺点:

一个请求极有可能到了链的末端都得不到处理,或者因为没有正确的配置而得不到处理.

中介者模式(Mediator)

中介者模式(Mediator),用一个中介对象来封装一系列的对象交互.中介者使各对象不需要显示的相互引用,从而使其耦合松散,而且可以独立的改变它们之间的交互.

场景:

• 一组对象以定义良好但是复杂的方式进行通信的场合
• 想定制一个分布在对个类中的行为,而又不想生成太多的类.

优点:

• Mediator(中介者类)的出现减少了各个Colleague(同事类)的耦合,可以独立的改变和复用各个Colleague类和Mediator类.
• 由于把对象如何进行协作进行了抽象,将中介作为一个独立的概念并将其封装在一个对象中,这样关注的对象就从对象各自自身行为转移到它们之间的交互上来,也就是站在一个更宏观的角度去看待系统.

缺点:

由于ConcreteMediator控制了集中化,于是就吧交互的复杂性变成了中介者的复杂性,这就使得中介者变得比任何一个ConcreteColleague都复杂.

解释器模式(Interpreter)

解释器模式(Interpreter),定义一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子.

场景:

• 自定义语法的语法解释.
• 如果一种特定类型的问题发生的频率足够高,那么可能就值得将该问题的各个实例表述为一个简单语言中的句子.这样就可以构建一个解释器,该解释器通过解释这些句子来解释该问题.
• 当一个语言需要解释执行,并且你可将该语言中的句子表示为一个抽象语法树

优点:

容易的改变和扩展文法,因为该模式使用类来表示文法规则,你可使用继承来改变或者扩展该文法.也比较容易实现文法,因为定义抽象语法树中的各个节点的类实现大体类似,这些类都易于直接编写.

缺点:

解释器模式为文法中的每一条规则至少定义了一个类,因此包含许多规则的文法可能难以管理和维护.建议当文法非常复杂时,使用其他的技术如语法分析程序或者编译器生成器来处理.

访问者模式(Visitor)

访问者模式(Visitor),表示一个作用域某对象结构中的各元素的操作.它使你可以在不改变各元素的类的前提下定义作用与这些元素的新操作.

场景:

访问者模式适用于数据结构相对稳定,又有易于变化的算法的系统.

优点:

• 访问者模式把数据结构和作用于结构上的操作(算法)之间的耦合解脱开,使得操作集合可以相对自由的演化.
• 访问者模式使得增减新的操作相对容易,因为增加新的操作就意味着增加一个新的访问者.
• 访问者将有关的行为集中到一个访问者对象中.

缺点:

访问者模式使得增加新的数据结构变得困难.

“大多数时候你并不需要访问者模式,但当你需要访问者模式时,那就是真的需要它了.”

享元模式(Flyweight)

享元模式(Flyweight),运用共享技术有效地支持大量细粒度的对象.

没搞明白.

关于年初的坑

• java编程思想线程部分放弃了.java虚拟机也看完了,另外看完了重构和大话设计模式.
• 对mac系统基本熟练应用
• 算是攒了三万块钱.
• 一年工作没有考虑换工作,但是没有多少积累.
• 每个月存了1000给父母的钱,已经给了7000,剩下的不出意外过年给家里.
• 想法有改变,依然在用信用卡,但是没有之前的压力了,能够控制好,今后一般使用信用卡是常态.
• 还了银行的一屁股债

其余年初挖的坑,均没有填上,主要是自控力差以及由自控力差引出来的这种那种的接口.

18年的其他回顾

勉强拼凑的收获

• 虽然一年都在混,好在年底两三个月看了点书.
• 在知识付费上花了几百块钱.通过stormzhang的公众号和星球改变了一些看世界的认知.
• 在理财上有所行动.
• 借钱黑名单加了人.以后的日子,非特殊情况,尽量不借钱给别人了.
• 买了台新台式机.

不足

• 游戏上花费的时间,精力和钱都太多.特别的钱是小事,魔兽花费的精力严重透支了身体健康.
• 工作上划水严重,被环境影响的太过拖沓.
• 知识付费上花了钱,但是并没有很好的利用.
• 读书太少/技术成长太少.
• 刷社交网站或者软件时间太长.
• 制定计划的可行性不足,执行力不足.
• 睡得太晚,起的太晚.
• 身体终于坚持不住,出现了异常.慢性肝损伤和高尿酸.
• 活动不足,没有吧减肥这件事坚持出一个月.
• 联系父母太少/回家次数太少
• 交际圈萎缩.

关于工作.

• 18年工作划水太多,节奏严重变得拖沓起来.没有坚持番茄工作法.
• 工作时间空闲的试试没有充分利用,浪费了大把时间在刷知乎等社交平台上.
• 工作应用的技术上也没有什么新的突破.当然也感觉个人到达了一个天花板,基本上是通常的业务需求和技术框架改变的问题都能够解决,所以在日常工作中的提升会变得很少.
• 并没有接触大数据相关的东西,跟自己当初来公司的目的相悖.
• 依然下班直接走.跟年初的想法有些区别,不再有强制自己加班的想法了.

关于游戏

• 18年游戏占据了自己大量的时间精力和金钱,引以为戒.
• 魔兽世界的粘性太大,今后完全不能考虑认真去玩了.
• 虽然并不排斥游戏上花钱,但是18年花的钱太多了,以后一定要控制.
• 还是玩了几款不错的游戏.
• 玩游戏的态度有问题,花费大量时间精力以后游戏开始变成逃避负罪感的方式,形成恶性循环.

关于学习

• 学习时间太少,方法有问题.企图通过思想控制身体学习,结果总是失败.应该让身体先进入学习的状态,然后让思想去适应.
• 在知识付费的方面开始有部分投入,但是并没有很好的利用.
• 虽然有点晚,但是还是在年底进入了学习装填,希望到2019的春节能够一直保持.
• 并没有完成18年积累技术的期望,可以说是荒废了一年.

关于身体和健康

• 一整年生活严重不规律,太不正常了.
• 没有坚持减肥.
• 依然管不住嘴和腿/比17年更差劲.惰性更重.
• 身体终于撑不住了,估计在医院花了三千了.
• 医生说必须要减肥了,生死攸关.

关于父母和姐姐

• 今年跟父母的联系太少,19年必须更改.
• 回家的次数太少.
• 每个月给父母存了1000块钱.之前有考虑过要不要给父母,后来想了下18年年初的计划,还是执行到底吧.剩下的5000过年也取出来给父母.
• 年初希望通过互联网让父母的精神生活更好一些.但是因为联系太少,没有更好的让他们熟悉互联网.
• 跟姐姐的联系太少.

关于经济

• 整体比较满意.还了17年的外债,能够有盈余,能够给父母钱也交上了保险.
• 交保险的五月份依然是一个痛苦的资金周转时间段.
• 关于理财,比17年更了解了那么一丢丢.
• 有很多不应该的冲动消费.
• 虽然给了父母钱,但是平常日子换的钱还是有点少.
• 知识上的冲动消费允许有,但是游戏和娱乐上的冲动消费要控制一下.

关于其他

• 肥都没减,谈什么女朋友.
• 买了个阿里云服务器,年末在搞备案.
• 七牛云测试域名被收回,导致博客的图片都挂掉了.
• 闲书读的太少,电影太少.读书笔记好久没有维护了.
• 动漫看了不少,如了动漫的坑,看过好多不错的番.

2019年挖坑.

硬性坑

• 减肥(进行中,105->87)
• 作息规律,晚上23点以前必须关灯睡觉.(最近状态较差)
• 需要跟父母敞开心扉畅谈一次,把彼此间的事情说明白了.
• 给父母养老钱. 跟父母多联系/多回家几次(进行中,联系比较少)
• 捣鼓自己的公众号,不用去写程序,只做简单的信息流,写写文章之类的.(写的东西太少)
• 每周回来看一次这个2019的挖坑,督促自己来完成工作.(最完美执行的计划)
• 买个电竞椅.(伪需求,已经放弃)
• 金三银四面试一下,不跳槽,跳槽在交了保险以后再作考虑.

软性坑

• 贯彻身体带动思想的方法.
• 每个月在网上给父母买点生活用品.
• 工作上要利利索索,不能再被环境影响养成拖沓的毛病.
• 减少游戏上的经济消费.控制游戏时间
• 把知识付费的英语和算法的坑填上.
• 催债程序
• 五篇blog
• 五本技术类书籍.高性能mysql/敏捷开发/cleancode
• java核心编程多线程(顺便把编程思想剩下的搞定)/程序员的自我修养.
• 多跟姐姐联系看看能不能抽时间一起回家.
• 春节前后集中解决下数据结构的问题.
• 阿里云的钱还要丢.争取在上边搞点东西.
• 去店里买点衣服.
• 攒5w块钱.

写坑的时候考虑了一下把学习放到了低于健康一级,也就是明年的主要目标是减肥和健康,顺便改善与父母的状态.减肥和改善父母的关系并不冲突,但是减肥和学习有时间上的冲突.重要性摆开,减肥和健康>经济问题>与家人的改善状态>学习>工作>游戏和其他.
如果完成了硬坑的一般,20年元旦出去转转.
如果提前完成了减肥,就提前出去转转.
我想休息一下.
我很缺钱.

总结一下

2018年过的十分安逸.并不想用一个积极的词来总结,用过消极的词吧—虚度.
没有生活的压力,整个人的精神状态很萎靡和消极,自制力差,懊恼,熬夜,工作拖沓,生病.简而言之是非常失败的一年.
往事不可谏,来者犹可追.
希望自己在19年能够做出足够的改变.经常回来看看这篇文章,看好以下自己以前的状态惊醒下.提醒下自己19年的目标.

java中的classpath路径问题

最近项目中有个调别的同事接口的地址频繁变更,就修改到配置文件中,方便部署以后修改.
config文件放在项目的resource文件夹下,resource文件夹下的文件在打包的时候会自动copy到项目的classPath目录下.

写完以后在在单元测试中测试:

1
2
3
4
5
6

@Test
   public void  testGetProperty(){
       String value=FileUtil.getPropertyByName("rest.url","","config" +
               ".properties");
       System.out.println(value);
   }

提示找不到配置文件.
查了一下想起来,maven管理的项目,单元测试的时候文件也需要放到test文件夹下的resource里
于是把resource文件夹copy到了test下.

测试,还是提示找不到配置文件,不得其姐,于是google一下,看到了如下病理解释:

stackoverflow原问题地址

按照回答的阐述,getResourceAsStream(“config.xml”)会在文件所处包内查找配置文件,如果要找到classpath下的文件的话,应该加上”/“才能定位到classpath根目录,于是修改了一下单元测试方法,加上了”/“,

1
2
3
4
5
6
7

@Test
   public void  testGetProperty(){
       String value=FileUtil.getPropertyByName("rest.url","","/config" +
               ".properties");
       System.out.println(value);
   }

测试通过.

出于怀疑精神,决定去查一下是否真像回答中的一样没有”/“的时候会在包下找文件路径,于是把配置文件copy到了编译后的class所在包的文件夹下,并把”/“去掉:

运行测试

通过,歪果仁诚不欺我

2017年常总结

写下这个总结的时候,已然是正月初六,马上回京开始新的一年的工作了.离家前夕无所事事,想起了这个被我拖延症拖了很多时日的总结.
2017年都干了什么

• 离开慧萌
• 找工作的一个月,借信用卡,学习
• 加入云宝
• 交保险,借信用卡
• 新工作,无所事事的玩游戏,以及还信用卡
• 与云宝不愉快的分手,学习了劳动法
• 学习和找工作,给爸妈买了手机,借信用卡
• 开始自己做饭
• 找到新工作,外派到信工所
• 信用卡买了mbp,借钱给朋友
• 日常工作与捣鼓mbp,游戏,还信用卡
• 房子到期,借信用卡续租
• 意外的发现助学贷款到期,借钱还贷款
• 与慧萌原同事聚会,有些意外
• 催债与回家过年.
• 日常随份子,日常跟老朋友扯淡聊天,日常玩游戏充钱.

嗯,一年大概就这些事情了.

关于离开慧萌

现在回头想想,当初的决定确实草率了一下.纵观全年,经济一直很拮据,总是在借信用卡和还信用卡之间来来去去.而且2017的两份工作都不是自己满意的两份工作,都是在断了经济来源以后手头拮据而不得不去的工作.
所以回头看看的话,继续在慧萌呆半年把合同期呆满显然是一个更成熟的做法,不但可以在简历上写上两年工作经验而不是尴尬的一年半,更重要的是,能够多攒一些钱,一定要有了足够的积蓄再选择跳槽

虽然一年的动荡确实是有点出乎意料,但是也不是不能接受.年初的时候在第一次跳槽的时候就想过万一出现不顺利的话,就当是熟悉跳槽了.现在在考虑跳槽的事情上,明显在注意事项上自己要考虑充分的多.

关于找工作

• 一定要有足够的积蓄再去找工作
• 至少在近三五年内,不要考虑创业公司
• 签合同的时候一定要把有疑问的地方弄明白,不合理的地方坚决不签,先小人后君子.
• 理论知识是打开理想工作的钥匙
• 加班严重的公司可以选择不去,但是不要把不接受加班之类的话放在你简历和面试里.
• 谈的薪资在你的预期上加20%,哪怕你肯定不值这些钱
• 如果有纠纷,一定要懂劳动法

关于工作

• 17年的自己在工作中太自我,缺少团队配合,热衷于做完自己的事情回家休息
• 热衷于不加班,并且以高效率为借口,但是没干完活而不加班的情况总是有的
• 番茄工作法的习惯还是比较不错的
• 先想后做的习惯继续保持
• 不为了加班而加班的想法虽然可能让自己有点别扭,但是这是正确的
• 人一天的注意力是有限的—这个忘了从哪里看来的结论,应该是一个正确的科学依据.
• 依然懒于处理人情世故.虽然说人情世故这件事确实是工作关系中不可或缺的一部分,但是”与计算机交流更省事”当初自己选择程序员职业的重要理由,至少在还没有栽大跟头的情况下,希望自己不要刻意去处理人情世故的事情.
• 兜兜转转依然回到了前后台都写的苦逼工作

  关于技术

• 对Linux日渐熟悉
• 开始玩github并搭建了自己的技术博客
• 对spring更加熟悉,并且坚持了”测试驱动开发”的工作模式,虽然并不规范
• 对引用框架更加熟练,引用了n次新框架
• java方面基础夯实了一些
• 理论知识依然不足以应对面试

  关于游戏和学习

  17年玩游戏的时间要远大于学习的时间,逃避困难的心理也让自己很多的学习计划流产.
  游戏的消费直线上升.
  游戏带给我的应该是放松心情而非消磨时间.
  相比游戏学习总是一件痛苦的事情.希望18年在没有windows的情况下能够多点时间在学习上.

  关于17年的其他

• 把互联网带进了父母的生活里,虽然他们有点网瘾的样子,但是总得来说是一件非常正确的事情
• 个人动荡的一年,经济依然没有盈余,反而是欠了银行一屁股债
• 年底思考了一下一分钱没给家里.
• 5月份的保险依然是一大经济难处,太多的人都觉得那个保险入的不对,但是自己依然觉得这个保险应该买
• 体重直线上升…
• 部分人员拉入借钱黑名单
• 学习了劳动法,懂得了书面合同的重要性,建立了对口头协议的正当的怀疑心理.
• 工资一下来先还信用卡的日子太难过了

  关于18年

• 不考虑跳槽,安安心心在现在的地方工作积累一年
• 尽量不用信用卡,每个月整理一下账单
• 年底之前不考虑买新电脑,今年只用剩下的这台mbp
• 每个月都去北京或者周边转转
• 工资现在先存1000块钱,年底交家里
• 最晚二月份工资下来以后买个跑步机和体重秤,减肥
• 每个周至少加班一天,周末或者平常的晚上
• 抽出陪朋友与陪家人的时间

写完看一眼,贯穿了17年的两件事,工作与钱….关于朋友和家人的事情,仿佛没有注意太多,于是在18年计划里加上了陪朋友与陪家人.
感谢17年
感谢家人对我依然不减的关心与爱,让我有了面对生活的勇气和责任
感谢朋友的帮助与关怀,让我在偌大的帝都也没有感到太孤独
感谢慧萌的领导和同事,在慧萌的工作让我有了良好的习惯,并且相信同事的关系可以简单与愉快的,不存在电视剧中的办公室政治,也愿慧萌能越来越好,员工福利能越来越好
感谢自己,虽然又胖了,虽然欠了一屁股债,虽然17年拮据而动荡,但是还是走过来了,不是太累.
用一个积极的词总结2017–尝试
向着18年前行吧,我要减肥!

2018挖坑填坑系列

新年挖新坑,计划总是要有的,万一真能填上呢.能完成一半,明年这个时候就换台新电脑.

• 填上2017年的坑包括java编程思想的线程部分和java虚拟机
• 新增做个web项目统计班里人的情况,安排聚会事宜等
• 个人项目tasklist的启动
• 尝试python写点东西
• 往深层次接触一下mysql,尝试mysql优化的知识.
• 接触大数据方向的东西,包括es,kafka,spark.kafka和spark的能够入门;es相关的能够尝试配置集群的东西.
• 尝试引用radis
• 了解ngnix的相关知识,自己的服务器上引用ngnix
• 通过mac系统多熟悉linux系统,记录笔记
• 零碎知识点的博客整理,暂时包括:
  • mybatis的mapper.xml相互之间的引用关系
  • 在上一条的基础上的底层增删改查的抽象
  • log4j的配置信息整理
  • springAOP的整体知识整理
  • java的代理机制
  • jdk9
  • 阅读一些jdk源码分析的文章
• 攒三万块钱,好心酸呀.

哦,还有减了20多年的肥,希望今年不是停留在嘴上,能坚持下来(需要买个跑步机和体重秤,嗯,我是买来占卧室地界的)

一月份计划

今天是11号,一月份暂定是把java编程思想的线程部分大体看完,然后总结一下java编程思想的大体内容.

如果时间充裕的话,做一下tasklist的功能设计,写一下文档;把各个模块设计清楚,方便日后做数据库设计和实现功能;分清楚功能是第一次开发需要完成的,那些功能推后开发.

二月份和三月份游戏里过去了…

三月底和四月份计划

3月26.前三个月一直懒懒散散,拖延症严重.四月份两件事情:

• 把2017年一直拖欠的java编程思想看完.主要是多线程和IO
• 统计聚会的程序写完.

数据库

mysql

close update safe model

1

SET SQL_SAFE_UPDATES = 0;

linux

命令相关

scp传送文件

1

scp -P27580  ROOT.war  root@192.168.111.23:/root

如果需要对应端口 使用-P参数 P要大写

查看系统版本

1

lsb_release -a

结果

1
2
3
4
5

LSB Version:	:base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch
Distributor ID:	CentOS
Description:	CentOS release 6.9 (Final)
Release:	6.9
Codename:	Final

重启

1

shutdown -r now

文件相关

环境变量设置文件:/etc/profile

mac命令

开启sshd服务

1

/usr/sbin/sshd -f /etc/ssh/sshd_config

基于自定义注解的springAOP配置

SpringMVC项目需要做一下登陆日志操作日志,愚蠢的我居然最先想到的在Controller基类中添加一个方法大家来调用,转而一想日志操作不就是AOP的典型应用场景么,随即一边google一边踩坑填坑,终于是完成了第一次的SpringAOP配置.

自定义注解annotation类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

package iie.df.analysis.misc;

import java.lang.annotation.*;

/**
 * 操作日志AOP注解
 * @author cheyantao
 */
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ActionMethod {
     String modal() default "";
     String method() default "";
}

AOP切面类

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package iie.df.analysis.misc;

import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.*;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import org.springframework.util.StopWatch;

@Component
@Aspect
public class AopLogging {
  private static final Logger LOG = LoggerFactory.getLogger(AopLogging.class);

  @Pointcut(value = "@annotation(actionMethod)",argNames = "actionMethod")
  public void actionMethodPointCut(ActionMethod actionMethod){

  }
  @Around(value = "actionMethodPointCut(actionMethod)")
  public Object afterActionMethod(ProceedingJoinPoint point,ActionMethod actionMethod) throws Throwable {
      System.out.println("执行目标方法之前，模拟开始事务...");
      Object obj=point.proceed();
      System.out.println(actionMethod.modal()+"--"+actionMethod.method());
      return  obj;//记得返回
  }
}

应用类

1
2
3
4
5
6
7

@RequestMapping(value = "/post-signin", method = RequestMethod.POST)
@ActionMethod(modal = "登录日志",method = "用户登录")
public ModelAndView signinPostDispatch(...)
    throws UnsupportedEncodingException {
    ...
    return new ModelAndView("redirect:/");
}

spring配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context"
  xmlns:mvc="http://www.springframework.org/schema/mvc"
  xmlns:aop="http://www.springframework.org/schema/aop"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
  http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
  http://www.springframework.org/schema/context
  http://www.springframework.org/schema/context/spring-context-3.0.xsd
  http://www.springframework.org/schema/aop
  http://www.springframework.org/schema/aop/spring-aop-3.0.xsd
  http://www.springframework.org/schema/mvc
  http://www.springframework.org/schema/mvc/spring-mvc-3.0.xsd">
  <description>Page Dispatch Config</description>
  <!--不相关的配置都删掉了,主要是下面两个 以及bean schema中的aop和context支持.-->
  <context:component-scan base-package="iie.df.analysis"/>
  <aop:aspectj-autoproxy proxy-target-class="true"/>
</beans>

这里有一个坑,平常我们都会把spring的相关配置在application-context.xml中配置,但是在springMVC项目中把这些配置放到application-context中的时候可能会出现无法进如切面方法情况,我就比较倒霉碰见了.具体解决方案是把以上的配置放到了dispatcher-servlet.xml配置文件中,多谢大神无私的回答:八楼大神造福大家.
如果你也遇到了这种问题,项目中又找不到dispatcher-servlet.xml这个文件,你应该可以再web.xml中找到相关的配置文件

1
2
3
4
5
6
7
8
9
10

<servlet>
   <servlet-name>Analysis</servlet-name>
   <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
   <init-param>
     <param-name>contextConfigLocation</param-name>
     <!--藏在这里-->
     <param-value>classpath*:config/servlet-context.xml</param-value>
   </init-param>
   <load-on-startup>1</load-on-startup>
 </servlet>

几处坑

1. 上文springMVC配置的坑.

2. aop切面两个依赖类确实,附上他们的maven地址,如果maven更新失败,请自行下载jar包maven install

   1 2 3 4 5 6 7 8 9 10 11

   <!-- https://mvnrepository.com/artifact/cglib/cglib --> <dependency> <groupId>cglib</groupId> <artifactId>cglib</artifactId> <version>2.2.2</version> </dependency> <dependency> <groupId>asm</groupId> <artifactId>asm</artifactId> <version>3.3.1</version> </dependency>

   3.切面类的注解问题.
   开始参照网上一些例子,大部分没有将注解作为参数传进@Around方法中,造成了获取注解属性必须通过发射获取,代码显得非常臃肿和丑陋.所以大概可以参照一下我的切面类的相关注解.另外这里爬坑的关键文章是stackoverflow专治疑难杂症,另外挖一个坑日后填整理一下AOP相关注解的知识
   4.切面类的@around方法记得把ProceedingJoinPoint执行后的结果返回.

   其他几个用得到的连接

• 详细的spring schema配置信息,但是按照这篇文章里的切面类注解,代码无法通过编译
• 一个简洁清楚的@Around方法例子
• 一个用反射获取注解属性的反例,但是可以参考这篇文章里的HttpRequest获取.
• 一个简单但是全面的切面类方法注解例子

其他

大约耗费了我一晚上的时间来搞定这个问题,虽然磕磕绊绊,最后总算是把这个东西配置出来了.最近确确实实感受到了自己两年工作经验跟一年工作经验时候的差别,一年前面对这些繁琐的配置问题大概就是无从下口,找公司的同事帮忙了.如今回过头来看看不知道什么时候自己也就习惯了这些配置问题了,并且能共一点点借助google把问题解决.突然想起大学那个在实验室呆了一个大学,写了无数文档,就是徘徊在编程门口入不了门的少年了.可惜如今已经奔三,不过庆幸的是,还好,总算可以独当一面了.