Laravel使用phpstorm时，提示“这是通过魔术方法访问字段”，有什么不好么？见如下截图红框中：
如果这样不好，那应该怎么才好？
小伙看你根骨奇佳，潜力无限，来学PHP伐。
不知道这个问题为何被关闭, 我重新打开了来说两句吧
没错, PHP确实提供了一系列魔术方法可以让你在__set, __get, __call等等中实现一个未定义的调用, 但个人愚见这些是PHP为了弥补本身的缺陷而添加进来的设计
__set
__get
__call
至于该不该用, 什么时候用, 取决于你的业务场景, 但个人仍然认为这个特性使用要节制, 毕竟这是"魔术"
优点是:
一定程度上的方便, 你会在很多DAL层的库中发现运用了这个特性
一定程度上你可以用这个特性实现代理模式, 函数重载等PHP本身没有在语言层面支持的特性
缺点是:
开发不够友好, IDE自动完成缺失, 无法生成文档(phpdoc)
如果你广泛采用魔术方法, 那很有可能随着你的业务逻辑的复杂, 你的魔术方法将会非常臃肿和难以阅读
也许有性能问题(未验证)
提高团队合作的理解和沟通成本, 本来$obj->getName()扫一眼就知道大概是什么功能的函数, 现在却要猜行不行, 有没有在背后实现魔术方法支持这个$obj->name调用
$obj->getName()
$obj->name
不知道这个问题为何被关闭, 我重新打开了来说两句吧
没错, PHP确实提供了一系列魔术方法可以让你在
__set,__get,__call等等中实现一个未定义的调用, 但个人愚见这些是PHP为了弥补本身的缺陷而添加进来的设计至于该不该用, 什么时候用, 取决于你的业务场景, 但个人仍然认为这个特性使用要节制, 毕竟这是"魔术"
优点是:
一定程度上的方便, 你会在很多DAL层的库中发现运用了这个特性
一定程度上你可以用这个特性实现代理模式, 函数重载等PHP本身没有在语言层面支持的特性
缺点是:
开发不够友好, IDE自动完成缺失, 无法生成文档(phpdoc)
如果你广泛采用魔术方法, 那很有可能随着你的业务逻辑的复杂, 你的魔术方法将会非常臃肿和难以阅读
也许有性能问题(未验证)
提高团队合作的理解和沟通成本, 本来
$obj->getName()扫一眼就知道大概是什么功能的函数, 现在却要猜行不行, 有没有在背后实现魔术方法支持这个$obj->name调用