什么是框架?
这个问题实际上许多“做框架”的人也不明白。 框架和库的本质不同在于:
- 框架考虑的是机制的复用,而库主要考虑的是代码的复用
- 框架考虑的是在机制不变的情况下进行扩展,而库则基本不考虑扩展方面的问题
- 框架本身是不完整的,在大多数的情况下它自己是干不了啥事情的,而库自身是完整的,可以解决某个领域的问题。
- 框架是活的,通过不断的扩展与衍生,它就更加强大,而库而是死的,发布时是怎样,就是怎样。
当然,关于这两货之间的比较,还有许多个角度,但我个人觉得本质是我上面举的这些。
设计的时候应该考虑哪些问题?这个问题的答案,如果用一句话来解符号,那答案就是:要仔细考虑使用这个框架的人感受,要考虑如何让使用者感觉爽的问题。当然如果是三天两天说不清楚的方式,那就得从方法论,问题领域,设计原则等待进行阐述了。
怎样才是一个及格的框架?这个问题,用一句话解释,就是在满足上一个问题的情况下不违背基本设计原则,那么就可以算是一个及格的框架。如果用三天两天说明,那就要把所有的基本设计原则拿出来,一个个讲讲清楚,一个个说说明白。
如果满足了第一个条件,使用者是满意的,从使用来说是不错的;如果满足了第二个条件来说,从设计及实现来说是不错的。如果两个都满足了那说明,最起码是可用的及格的框架,当然也可能得分更多。
开源框架的体系与战术
顺便,今天还谈谈框架的体系与战术性角度,一家之言,说得不对还请海涵。
从军事上来说,战术性的战斗就是具体的一块无关紧要的战斗,胜就胜了,败就败了,局部互有长短,但是就全局来说没有本质的影响;而体系性的则是影响双方势力对比的重要关键点,是个死去活来的问题,是西风压倒东风还是东风压倒西风的问题。
做框架也是有同样的问题的,如果框架只能解决一个局部部分,或者说具体问题,那么就是战术性框架;比如一个Xml解析器,一个网络爬虫框架等等,都是解决具体问题的,因此不管做得怎么到位,怎么好,都是一个战术性的问题。
那么我再拿人们常说SSH框架来说,很明显Hibernate和Struts是属于战术性框架的。但是Spring则明显不同,表面上Spring本身只是提供了一系列的机制和体系,但是它本身并不做具体的某个方面的问题,他解决IOC,AOP之类的比较虚的问题,但是正因为如此,它占据了整个开源框架的核心位置,许许多多的别的框架都是非常容易被替换及剔除的,但是唯一的要剔除Spring就比较困难--或者说,剔除Spring,就需要找一个比Spring更好的方案来替代,没有找到之前,就很难真正剔除它。
偶也看了OSC上一些同学的框架的源代码,从解决具体的问题来说,技巧、慎密性、前卫性都不错,但是看来看去,感觉还是在战术性问题上打转转,也就是解决具体问题方面做得非常不错,但是在体系性方面就比较弱了。
在此,我也把自己对框架(Framework)的理解和大家交流,我的理解Framework一定是Framework框架者构建的结构性、体系性、机制性的部分,而让使用者提供实际的、业务的、具体的实现的部分;当然Framework构建者也可以提供一些实际的、业务的、具体的实现的部分,但是这只可以作为默认的、基本的实现,它在大多数的情况下都是够用的,但是在特殊情况下是可以被拿掉的,是可以被替换的。
也就是说,如果你达到上面要求,你才可以说是一个框架(Framework),否则,你只是个Library,只是一个代码库,不能称之为一个框架。
可能有的同学们又说了,你呼扯海说了半天,你现在设计的框架怎么就是有体系性的了??这正是我下面要解释的问题:
1.通过大量的体系性上思考,它不仅立足于解决开发问题,还考虑集成、发布、维护方面的问题。
2.构建了许多子框架,比如:流程框架,插件框架、UI框架等等,这些框架只有体系和机制及规范方面的内容,本身是不提供具体功能的,但是业务开发人员可以基于其之上进行扩展,来达成各种目标。
3.在在实现方面大都考虑有侵入性及无侵入性,也就是说如果你可以接受侵入性,那你就做起来更方便;如果你不接受侵入性,那么也可以使用Tiny框架的许多功能。
4.在集成方面下的功夫是最大的,可以方便实现自组装,也就是扔进去不用管的模式。
5.在模块化方面也是投入大量的力量,所有的资源都可以打入Jar包,不必修改web.xml就可以进行各种Web模板的加载等待。
6.战略性目标是构建一个生态圈,做UI的,做逻辑的,做业务的能够做自己擅长的事情,通力协作。
所以,正因为Tiny框架做了许多体系性的工作,可能不能直接实现某个功能,但是它的作为体系在开发、协作、维护、支持各个阶段。
当然,我们正在设计的框架中也包含了大量的解决实际问题的库和框架,同时也不拒绝各种开源框架的集成与使用。
因此,大的开发框架是个体系性的工程。所以,做开源框架之前,先要定位准确,是做战术性的还是体系性的框架,这样只做自己擅长,可控的事情,才得心应手,轻松愉快,同时又可以获得最大回报。
什么是框架?
这个问题实际上许多“做框架”的人也不明白。 框架和库的本质不同在于:
- 框架考虑的是机制的复用,而库主要考虑的是代码的复用
- 框架考虑的是在机制不变的情况下进行扩展,而库则基本不考虑扩展方面的问题
- 框架本身是不完整的,在大多数的情况下它自己是干不了啥事情的,而库自身是完整的,可以解决某个领域的问题。
- 框架是活的,通过不断的扩展与衍生,它就更加强大,而库而是死的,发布时是怎样,就是怎样。
当然,关于这两货之间的比较,还有许多个角度,但我个人觉得本质是我上面举的这些。
设计的时候应该考虑哪些问题?这个问题的答案,如果用一句话来解符号,那答案就是:要仔细考虑使用这个框架的人感受,要考虑如何让使用者感觉爽的问题。当然如果是三天两天说不清楚的方式,那就得从方法论,问题领域,设计原则等待进行阐述了。
怎样才是一个及格的框架?这个问题,用一句话解释,就是在满足上一个问题的情况下不违背基本设计原则,那么就可以算是一个及格的框架。如果用三天两天说明,那就要把所有的基本设计原则拿出来,一个个讲讲清楚,一个个说说明白。
如果满足了第一个条件,使用者是满意的,从使用来说是不错的;如果满足了第二个条件来说,从设计及实现来说是不错的。如果两个都满足了那说明,最起码是可用的及格的框架,当然也可能得分更多。
开源框架的体系与战术
顺便,今天还谈谈框架的体系与战术性角度,一家之言,说得不对还请海涵。
从军事上来说,战术性的战斗就是具体的一块无关紧要的战斗,胜就胜了,败就败了,局部互有长短,但是就全局来说没有本质的影响;而体系性的则是影响双方势力对比的重要关键点,是个死去活来的问题,是西风压倒东风还是东风压倒西风的问题。
做框架也是有同样的问题的,如果框架只能解决一个局部部分,或者说具体问题,那么就是战术性框架;比如一个Xml解析器,一个网络爬虫框架等等,都是解决具体问题的,因此不管做得怎么到位,怎么好,都是一个战术性的问题。
那么我再拿人们常说SSH框架来说,很明显Hibernate和Struts是属于战术性框架的。但是Spring则明显不同,表面上Spring本身只是提供了一系列的机制和体系,但是它本身并不做具体的某个方面的问题,他解决IOC,AOP之类的比较虚的问题,但是正因为如此,它占据了整个开源框架的核心位置,许许多多的别的框架都是非常容易被替换及剔除的,但是唯一的要剔除Spring就比较困难--或者说,剔除Spring,就需要找一个比Spring更好的方案来替代,没有找到之前,就很难真正剔除它。
偶也看了OSC上一些同学的框架的源代码,从解决具体的问题来说,技巧、慎密性、前卫性都不错,但是看来看去,感觉还是在战术性问题上打转转,也就是解决具体问题方面做得非常不错,但是在体系性方面就比较弱了。
在此,我也把自己对框架(Framework)的理解和大家交流,我的理解Framework一定是Framework框架者构建的结构性、体系性、机制性的部分,而让使用者提供实际的、业务的、具体的实现的部分;当然Framework构建者也可以提供一些实际的、业务的、具体的实现的部分,但是这只可以作为默认的、基本的实现,它在大多数的情况下都是够用的,但是在特殊情况下是可以被拿掉的,是可以被替换的。
也就是说,如果你达到上面要求,你才可以说是一个框架(Framework),否则,你只是个Library,只是一个代码库,不能称之为一个框架。
可能有的同学们又说了,你呼扯海说了半天,你现在设计的框架怎么就是有体系性的了??这正是我下面要解释的问题:
1.通过大量的体系性上思考,它不仅立足于解决开发问题,还考虑集成、发布、维护方面的问题。
2.构建了许多子框架,比如:流程框架,插件框架、UI框架等等,这些框架只有体系和机制及规范方面的内容,本身是不提供具体功能的,但是业务开发人员可以基于其之上进行扩展,来达成各种目标。
3.在在实现方面大都考虑有侵入性及无侵入性,也就是说如果你可以接受侵入性,那你就做起来更方便;如果你不接受侵入性,那么也可以使用Tiny框架的许多功能。
4.在集成方面下的功夫是最大的,可以方便实现自组装,也就是扔进去不用管的模式。
5.在模块化方面也是投入大量的力量,所有的资源都可以打入Jar包,不必修改web.xml就可以进行各种Web模板的加载等待。
6.战略性目标是构建一个生态圈,做UI的,做逻辑的,做业务的能够做自己擅长的事情,通力协作。
所以,正因为Tiny框架做了许多体系性的工作,可能不能直接实现某个功能,但是它的作为体系在开发、协作、维护、支持各个阶段。
当然,我们正在设计的框架中也包含了大量的解决实际问题的库和框架,同时也不拒绝各种开源框架的集成与使用。
因此,大的开发框架是个体系性的工程。所以,做开源框架之前,先要定位准确,是做战术性的还是体系性的框架,这样只做自己擅长,可控的事情,才得心应手,轻松愉快,同时又可以获得最大回报。
欢迎入住我们的框架生态圈:http://bbs.tinygroup.org。我的QQ:2119184384。本例涉及的代码和框架资料,将会在论坛分享。《自己动手写框架》成员:228977971,让我们一起动手,了解框架的奥秘!
相关推荐
自己动手写框架,完整的过程指导,非常适合初学者。
自己动手写Web自动化测试框架,很不错的书籍
程序代码 博文链接:https://ielts0909.iteye.com/blog/1515045
自己动手画CPU实验框架 自己动手画CPU实验框架 自己动手画CPU实验框架 自己动手画CPU实验框架 自己动手画CPU实验框架 自己动手画CPU实验框架 自己动手画CPU实验框架 自己动手画CPU实验框架 自己动手画CPU...
自己动手写框架,基于Koa2
自己动手做框架——ORM,MVC,IOC框架及整合视频教程 源码
前言为什么写这本书2016年是属千TensorFlow的一年,凭借谷歌的大力推广,TensorFlow占据了各大媒体的头条。2017年年初,PyTorch的横空
能源开采行业专题研究:动力煤框架之二:运输通道和定价体系(2022)(14页).pdf
《自己动手写前端框架》电子书
PHP MVC 说明文档
GUI框架:消息队列的设计与实现。 GUI框架:消息队列的设计与实现。 GUI框架:消息队列的设计与实现。
深度学习框架PyTorch:入门与实践.陈云,90M高清,带标签
自己动手写基于Spring Boot的注解版MyBatis框架项目源代码,更多详情请查看相关博客:https://blog.csdn.net/qq_31142553/article/details/86655951
自己动手写SpringMVC框架项目源代码,更多详情请查看相关博客:https://blog.csdn.net/qq_31142553/article/details/86582066
本书旨在通过一些案例教授读者怎样自己来开发Struts框架
自己写的微框架,框架学习,PHP框架,需要的老铁们拿去
全球哈佛分析框架:文献综述与研究展望
本系列文章来自 Building Your Own Plugin Framework,主要内容是讨论使用 C/C++ 语言开发跨平台的插件框架所需要的架构、开发方法以及部署。我们将从分析现有插件/组件系统开始,一步步深入了解如何开发插件框架,...
《自己动手写前端框架》电子书.pdf 1. Tiny框架 2. 算法感想 3. 悠然乱弹 4. 未分类
20210709-申万宏源-货币政策分析框架:货币政策,战略目标与战术选择.pdf