设计模式完结感言

作者分享了自己花费一年时间深入理解和实现23种GoF设计模式的心路历程,从畏惧到理解再到掌握,不仅详细记录了实现过程中的感受,还对设计模式的价值进行了深入探讨。文章强调设计模式并非万能,应根据实际场景灵活应用,避免盲目套用。同时,作者反思了模式学习过程中的挑战和收获,提供了个人对于设计模式的独到见解。

截止到今天终于把23种GoF设计模式和部分未收录在内的模式实现了一遍,设计模式的学习就告一段落了,在以后的时间如果有新的感悟会定期维护相应的博文。

时间跨度为2014-07-01到2015-10-11,经历了一年多的时间。从畏惧模式到理解模式再到真正懂得模式,这个过程的确是无法言传的体验。虽然经历的时间比较长,虽然博文会有瑕疵,但是还是有点成就感。因为除了那个我比较不感冒的解释器模式,所有的实现代码都是我一行行敲出来的,在敲得过程中会真切的认识理解每一个模式。

从入行的时候,带我的老大给我一个demo项目让我开发东西,然后跟我说这套实现方法叫Facade模式。我当时没有编程语言基础,基本啥开发经验都没有,对模式,就是感觉很高深,隐隐有点不敢触碰的样子。后来慢慢的代码写多了,看的也多了,对一些模式就有了解了,去年就心血来潮写了第一篇关于设计模式的博文,最终断断续续完成。

对设计模式的话题现在貌似没有以前那么火了,几年前的技术社区如果没有模式方面的内容似乎都显得不够逼格,人们也热衷于讨论模式之间的不同,模式的应用场景,模式的实现等等。

最近有听人说模式无用,觉得挺有用的。一个功能实现方式可以五花八门,久经考验的设计模式可以提供一些参考。当然硬套模式、为模式而模式这类行为很2,不莽撞、不自私也显得很重要。

做个稍微正式点的总结:

1、设计模式,是一系列思想抽象,它告诉开发人员在某一类场景有哪些最佳实践,也能为以后的代码架构设计提供重要的参考。

2、模式不是银弹,不要一切皆模式,一个简单的方法能搞定,就没有必要多建几个类而模式。工程上下文场景是使用什么模式的依据。

以上是一家之言,若有不妥之处欢迎指正。

转载于:https://www.cnblogs.com/liushijie/p/4870503.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值