QUOTE:
函数/类写出来是给别人用的, 要从别人使用的角度写, 写的友好一些.在论坛中看到很多篇讲OO的文章, 但都只是在说怎么创建类, 怎么应用抽象类或接口写类.
其实OO的好处是体现在对象的使用上, 也就是类的使用者感受最深, 而不是类的定义者.
这里就是要讲OO设计时, 怎么样使用对象, 才能体现OO的优点.
一个显示当前会员用户名的代码(访客则显示guest), 这里有几种应用情况:
我们在写代码时, 是不是经常要写一些判断, 是不是已经登录像上面的代码:
从OO的角度来写, 应该是:
//取得当前用户
这里可以看出OO设计, 统一接口的好处, 省去了很多判断, 简化了代码, 代码结构且更直观.
但维护上就会有个问题了, 如何保证Member和Guest两个类统一接口呢? 比如现在会员中要添加一个性别方法sex(),
又如何保证添加Member类中的, 不会忘记Guest类中的, 甚至更多的类.
这时, 接口就起作用了, 如定义一个接口类User:
这时, 如果Guest中忘记添加了, PHP在解释Guest类时, 会提示错误, 就可以很快发现问题了.
(其实这个在编译型的语言中优势比较明显, 只要编译一下就知道了)
OO中重要的是统一同一类对象的访问接口, 不要把抽象类和接口单独拿直来谈论OO,
其实总的来说, 这两个东西跟类差不多, 只是有本身的一点特性.
最新回复
没有设计过框架的人很难真正的理解OOP的精髓，也很难理解为什么有封装、继承、多态。
设计类库时不外乎六个基本原则，但其理想就是问题隔离，如现实中的责任制一样。能合适的分配好责任是很不容易的。jdk,.net framework也有很多责任不明的地方。都是在一边使用一边改进的。
幸亏有了以上的三个功能，不然真的不知道会有多少“过时的”、“不建议使用”的东西。
在类的倒置继承树中,一般只有叶子节点才是具体的类,根节点和其它非叶子节点应该都是接口或则抽象类
抽象类代表了一种类型..接口代表了一种角色..
所以在JAVA和PHP这些语言中,
只能从一个类继承--事物属于一种特定类型
可以实现多个接口--事物可以在不同场合担任多个不同角色
QUOTE:
设计类库的六个基本原则是什么？愿闻其详。抽象、接口在OOP中应该是比较高级的用法，要熟练掌握和灵活应用需要相当的功力
displayUsername(new Guest());
在参数中传入一个对象的引用
interface和abstract确实为了统一规范。不接触ZF还不知来龙去脉
以前刚学还觉得接口这东西真是多此一举
谢谢, 欢迎使用, 建议, 反馈, 参与
> 没有设计过框架的人很难真正的理解OOP的精髓，也很难理解为什么有封装、继承、多态。
不一定要框架, 我觉得开发经验很重要, 没有开发经验, 也就不会遇到一些问题, 就不会明白, 为什么要这么做了.
> 设计类库时不外乎六个基本原则，但其理想就是问题隔离，如现实中的责任制一样。能合适的分配好责任是很不容易的。jdk,.net framework也有很多责任不明的地方。都是在一边使用一边改进的。
> 幸亏有了以上的三个功能，不然真的不知道会有多少“过时的”、“不建议使用”的东西。
OO很重要的一点就是责任, 分清责任也就是分清各个类的职责.
而对于类库的设计者设计上就更难了, 因为类库一但发布, 就不好改了, c++的标准类库几年才发布, 也才是一些基础的东西.
对于类设计者一开始并不能考虑所有的东西, 但加上, 设计者的立场, 所以职责的认识可能会不一样, 还要考适用的范围, 复杂性, 易用等等.
有时我觉得类的设计并不都是面向对象的，有些是语言或技术上的东西，过多的面向接口编程是不现实的。
现在框架的盛行对于程序员不见得是什么好事，他们少了些分析与设计大量的类的过程，大多只是机械的组装业务类，而这里面的分析与设计并不多，不利于程序员的成长。
过多的使用接口, 其实也就是过度设计了, 过度的设计只会带来系统的复杂, 这种往往是缺少经验.
我以前也有经历过这样的, 刚学过OO, 心里跃跃预试, 真想把所学的东西都应用上, 这样就会为设计而设计, 不是为应用而设计.
其实经历这个过程也并不是坏事, 呵呵
我现在的方法是, 不要想太多, 从简单的开始, 再根据需要, 调整, 重构, 扩展......
类的设计是OO中的一部分, 面向对象, 还有包括分析等等一些其它的.
> 现在框架的盛行对于程序员不见得是什么好事，他们少了些分析与设计大量的类的过程，大多只是机械的组装业务类，而这里面的分析与设计并不多，不利于程序员的成长。
这个要看框架的类型了, 现在很多人喜欢吃快餐, 目前主流的框架也都是什么快速开发什么的, 当然并不是所有的框架都是这样的.
而我的主要是希望帮助开发者做好设计, 会提供一个发挥设计空间的框架平台.