对下面这篇文章, 我更多的关注的不是该文作者所关注的话题, 而是该文所体现出来的问题: 面向对象给我们带来的帮助的和限制. 最近研究一种自由的编程方式, 暂时叫做"面向概念"吧, 如果能经过实践考验, 会拿出来说说~
精华, 精华 :)
抛砖引玉, 多说几个问题:
1. 现在越来越多的人意识到LZ说的这些问题了. 不过, 所有的ObjInterface.DoSomething(), 其实质都是 DoSomething(ObjInterface obj). 管它叫作Extend也好, Mixin也好, 实际上还是摆脱不了对接口的依赖. 尤其是面向对象的依赖方式, 往往是"厚重的胶合层"的罪魁祸首. 依赖于清晰定义的接口, 是四海一家的解决之道吗?
2. 有的时候, 只是接口的问题, 对于C#这样的, 可以用反射生成子类的方式, Mixin接口, 会比Extend更简洁和漂亮一些;未来还有Dynamic Interface. 可惜如果是添加功能实现, 也就只能Extend了, 因为反射生成子类的方式和Extend起到的效果是一样的. 另外, 鉴于1, Extend的局限性在于, 它并不能在内部改变对象的状态, 这使得它不过是更漂亮的自由函数而已.
3. 本质上是多主语的情况呢? 很多问题的实质是DoSomething(ObjInterface1 obj1, ObjInterface2 obj2), 面向对象语言对于这些情况, 表达能力实在是有限.
4. 关于本文, 还有一点需要考虑的, 就是Strategy和Extend, 很多时候, 其实并不是选这个更好还是选那个更好. Strategy达到的是运行期多态的目的, 而Extend则没有这方面的考虑: 代码一旦写下去, 运行期你不能再更换Extend出来的行为, 虽然可能有一些技巧可以应用, 但这不是本质上的.
个人认为, 在C#, Java上出现的这些问题, 实质上是面向对象的限制. 能用现有手段扩充的, 就用现有手段扩充; 其它的, 我看现在是需要一些新的思维来解决的时候了.
抛砖引玉, 多说几个问题:
1. 现在越来越多的人意识到LZ说的这些问题了. 不过, 所有的ObjInterface.DoSomething(), 其实质都是 DoSomething(ObjInterface obj). 管它叫作Extend也好, Mixin也好, 实际上还是摆脱不了对接口的依赖. 尤其是面向对象的依赖方式, 往往是"厚重的胶合层"的罪魁祸首. 依赖于清晰定义的接口, 是四海一家的解决之道吗?
2. 有的时候, 只是接口的问题, 对于C#这样的, 可以用反射生成子类的方式, Mixin接口, 会比Extend更简洁和漂亮一些;未来还有Dynamic Interface. 可惜如果是添加功能实现, 也就只能Extend了, 因为反射生成子类的方式和Extend起到的效果是一样的. 另外, 鉴于1, Extend的局限性在于, 它并不能在内部改变对象的状态, 这使得它不过是更漂亮的自由函数而已.
3. 本质上是多主语的情况呢? 很多问题的实质是DoSomething(ObjInterface1 obj1, ObjInterface2 obj2), 面向对象语言对于这些情况, 表达能力实在是有限.
4. 关于本文, 还有一点需要考虑的, 就是Strategy和Extend, 很多时候, 其实并不是选这个更好还是选那个更好. Strategy达到的是运行期多态的目的, 而Extend则没有这方面的考虑: 代码一旦写下去, 运行期你不能再更换Extend出来的行为, 虽然可能有一些技巧可以应用, 但这不是本质上的.
个人认为, 在C#, Java上出现的这些问题, 实质上是面向对象的限制. 能用现有手段扩充的, 就用现有手段扩充; 其它的, 我看现在是需要一些新的思维来解决的时候了.