0

先问一个先前的做法

function me(){
}

假设每个网页开头都引入这个功能
但明明大部分网页是不需要这个功能,但还是被引入了

跟我将函数都写成类+ namespace去使用
但每一页都还是需要引入每个类的功能

class get {
     public static function me(){
    }
}

以及我最近看的mvc是根据路由器来决定要引入哪些类
请问这三种的优劣势在哪里?
是不是非得只有mvc的撰写方式才有办法用最不多余的方式引入需要的功能?
或是有没有其他类似的方式也能做到相同的效果?

補充

想問一下這樣的做法是不是文件數會越來越多?
如果每個文件只做一兩件事?
這是不是開發趨勢?

asys0512 2.7k
2018-11-28 提问
4 个回答
3

已采纳
  • 首先纠正一点,MVC只是大部分WEB应用的一种结构(算是设计框架的一种指导性的原则),它本身与你所说的命名空间namespace(确切地说它属于一种新的技术,新的特性)就是两个维度的东西,所以两者并不能对等地去比较。换句话说,当前大部分的框架会采用MVC的原则去设计代码架构,而namespace是当前PHP开发过程中普遍使用的一种技术。
  • 你所描述的第一种方式按我的理解应该算OPP的开发(上来就是function,那么应该没有封装在类内)。而用类进行了封装可以算是OOP的开发方式。而要达到你所说的“用最不多余的方式引入需要的功能”其实也跟这两者没有太大的关系。。当你以适当的方式对方法(函数)进行拆分和组合之后总会找到你所想要达到的效果。。OPP的方式下你只能采用require或者include之类的方式去加载你需要的文件和函数,文件之间的依赖关系需要你手动去维护。而一般的OOP下,类之间的依赖关系也还是需要你手动维护,所以它们之间并没有质的区别,所以也就说不上具体的优劣。
  • 接下来呢,分析一下你具体的疑惑,你所抛出来的问题其实很庞大,庞大到这可以算是一个可以研究的课题。。以“最不多余的方式引入需要的功能”其实反过来说何尝不是“找到最优的方式提高代码的复用度,降低冗余”。很多的设计模式都需要与实际问题相结合来实现这样的目标。你所描述的“根据路由器来决定要引入哪些类”似乎传达的是依赖注入(Denpdency Injection, DI)。依赖注入本质上它还是类的调用,但是它将类的依赖关系交给依赖注入容器来管理。你可以自己详细看一下DIPIoC还有DI,应该就能理解了。另外你还可以自己尝试设计Interfaceabstract之类的再辅以trait正向地初步实现你需要的效果。。
2

很明显,直接引用的话,写的代码少,而且内存消耗,执行效率肯定是最好的。
但是带来的最大的坏处就是,你写了1000个function后你会发现,你的项目已经不能维护了,因为你要想出1000个函数名,
其实对于php来说,不用框架,php的运行效率是最高的,但是不用框架,代码可维护性太差了,这个就是运行效率和开发效率的考量了

2

维护性、可扩展性并不高,出现bug后原因查找也非常困难。

没有“银弹”,设计模式是这些年来资深开发者通过实现不同需求自我总结出来的。类的概念即是其中之一。

1

直接函数编程是PHP最原始的编写方式:
优点:是简单直接
缺点:中大型项目维护成本很高,不利于扩展

以类的方式+include方式是面向对象开发的结果:

优点:类可以隔离变量以及方法
缺点:不管是否需要都会include文件,浪费资源,且引入第三方库的情况下,无法保证类名是否重复

类+命名空间+自动导入:推荐的开发方式,自动加载类可完全不用自己include文件,方便中大型项目开发和维护。

撰写答案

推广链接