• 《自己动手写框架7》:关于框架体系与战术的思考


    什么是框架?

    这个问题实际上许多“做框架”的人也不明白。 框架和库的本质不同在于:

    • 框架考虑的是机制的复用,而库主要考虑的是代码的复用
    • 框架考虑的是在机制不变的情况下进行扩展,而库则基本不考虑扩展方面的问题
    • 框架本身是不完整的,在大多数的情况下它自己是干不了啥事情的,而库自身是完整的,可以解决某个领域的问题。
    • 框架是活的,通过不断的扩展与衍生,它就更加强大,而库而是死的,发布时是怎样,就是怎样。

    当然,关于这两货之间的比较,还有许多个角度,但我个人觉得本质是我上面举的这些。

    设计的时候应该考虑哪些问题?这个问题的答案,如果用一句话来解符号,那答案就是:要仔细考虑使用这个框架的人感受,要考虑如何让使用者感觉爽的问题。当然如果是三天两天说不清楚的方式,那就得从方法论,问题领域,设计原则等待进行阐述了。

    怎样才是一个及格的框架?这个问题,用一句话解释,就是在满足上一个问题的情况下不违背基本设计原则,那么就可以算是一个及格的框架。如果用三天两天说明,那就要把所有的基本设计原则拿出来,一个个讲讲清楚,一个个说说明白。 

    如果满足了第一个条件,使用者是满意的,从使用来说是不错的;如果满足了第二个条件来说,从设计及实现来说是不错的。如果两个都满足了那说明,最起码是可用的及格的框架,当然也可能得分更多。

    开源框架的体系与战术

    顺便,今天还谈谈框架的体系与战术性角度,一家之言,说得不对还请海涵。

    从军事上来说,战术性的战斗就是具体的一块无关紧要的战斗,胜就胜了,败就败了,局部互有长短,但是就全局来说没有本质的影响;而体系性的则是影响双方势力对比的重要关键点,是个死去活来的问题,是西风压倒东风还是东风压倒西风的问题。

    做框架也是有同样的问题的,如果框架只能解决一个局部部分,或者说具体问题,那么就是战术性框架;比如一个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框架做了许多体系性的工作,可能不能直接实现某个功能,但是它的作为体系在开发、协作、维护、支持各个阶段。

    当然,我们正在设计的框架中也包含了大量的解决实际问题的库和框架,同时也不拒绝各种开源框架的集成与使用。

    因此,大的开发框架是个体系性的工程。所以,做开源框架之前,先要定位准确,是做战术性的还是体系性的框架,这样只做自己擅长,可控的事情,才得心应手,轻松愉快,同时又可以获得最大回报。

  • 相关阅读:
    RxJava简要分析
    okHttp3源码简要分析
    Android 内存优化浅析
    用暴走漫画写使用手册
    简单的JavaScript互斥锁
    为jQuery添加Webkit的触摸方法支持
    去年做了什么?OA。
    简单地总结下双十一对“老婆”的评价
    麦当劳送薯条活动坑薯条设想,实践被失败
    用.NET MVC实现长轮询,与jQuery.AJAX即时双向通信
  • 原文地址:https://www.cnblogs.com/j2eetop/p/4612588.html
Copyright © 2020-2023  润新知