当前位置:Gxlcms > PHP教程 > 如何评价“约定优于配置”的编程模式?

如何评价“约定优于配置”的编程模式?

时间:2021-07-01 10:21:17 帮助过:15人阅读

回复内容:

这是框架的设计理念,没见过哪个语言是这样的。 语言的语法就可以看做是一种约定
编译器或解释器的参数如果能影响语法的含义或支持,就算配置。 用心智空间换打字速度 人都是很懒的,能既省时间又省精力干嘛要重复做那些麻烦的事 我想到了lavavel,你倒是举个例子啊~~ 作为一个可悲的java开发者,我说一下感性的东西。
多组件配合的时候,你可以去配置,100个配置点你就有写100遍,因为你不可能知道这些配置点默认值是什么,是否必填项。
那么,约定就好像java的getter和setter,name属性,它的setter必然是setName,getter必然是getName,我不需要去配置中指定,用反射直接可以拿到setName和getName。
这是一种设计理念,一个团队中约定条件1 2 3,比如,dao的底层sql查询用add_表示增、del_开头表示删除,那么配置事务时候就直接add_* 指定一个策略就行了,这是约定。减少你出错的可能性,这是工程层面的东西,那么扩展到一种语言,就好像java的getter和setter,也算一种约定,但是为了语言的灵活性,这样的约定会比较少,不像框架中约定使用的这么随意。 就好像和熟人合作优于陌生人,但现实是残酷的 约定重于配置会造成熟的人上手很快,不熟的人学习成本上升。
约定重于配置会导致扩展性下降,为了弥补配置的不足会产生很重的实现,最终又体现在学习成本的增加上。
约定重于配置能够让熟手在熟悉的领域快速开发,长远来看不一定是好事。 约定大于配置,只要记住约定的,就少写了配置文件 没见过哪个语言?go语言的函数首字母大写表示public、小写表示private算不算?

人气教程排行