- 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
- 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
- 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
- 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们。
- 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
- 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
多媒体课件--第一讲课件--OOAD原则(下发)
面向对象的分析与设计 Object 特定 VS2010(c#), eclipse (MyEclipse)(java,c#,c++) OO(Oriented Object) 一切都是对象; 面向接口编程 OO: 1:封装; 2:继承 -- 3:多态 软件 = 对象+消息 OOP 与 面向过程 面向对象编程 class A { 属性;方法; ? public void do() { B bObj = new B(); bObj.doxxx(); } } 过程语言: C++ int main(int argv,char* argv[]) { …} 如何写好一个类 private protected friend public 封装 ?遵循规则 复用 适应变化 需求总是在变 在工作上如何面对? 按类编程 代码审核: CodeView ? 2.5 软件测试 ? 白盒测试 builder ? 编写代码的要求 软件编程要规范 类名: class Student {} class Course {} 变量取名: Student stud = new Student(); 第一个字要不要大写: 取名规则C++/C# szName = “张三”; bYesOrNo = true; Camel取名规则: std ? 见名知意 student, studentGrade; // Linux Unix yesOrNo count 公司软件规定: 1234-name-XXXX.rar 语法规则 if ( a b ) { if ( c ) { if ( ^d ) { } } } ? ★易于阅读 见名知意 缩排结构 其他 Void funx() { // 30行以内(1屏为限) ? } 如何配色: UI上的颜色不要超出4种,色系要一致,少用或不用红色 课程学习的内容 OO设计原则 -- 遵循业内规则 UML设计图及Rose Rational 工具 -- 采用标准图例 OO设计模式 – 23种 -- 采用最优方案 典型项目的分析与设计 学习方法 掌握主要OO原则的原理和应用要点 改变 java, C# 编程习惯 学会设计 Rational工具的使用; 掌握类图、用例图、顺序图、活动图的设计 熟练掌握MVC 设计方法 熟练掌握数据库编程 深化了解API,深化基于API的编程 反复实践典型模式应用于项目的分析和设计 参考书 面向对象软件工程与 UML, 李飞跃, 人民邮电出版社 ( 高职教材 ) UML与软件建模 , 徐宝文,清华大学出版社(重点大学教材) 面向对象设计原理与模式,(美)Dale Skrien著, 清华大学出版社 (国外经典教材) Java设计模式, 耿祥义,清华大学出版社 大话设计模式,程杰,清华大学出版社 考核 基于典型项目的考察: 项目的分析与方案设计 UML典型图 项目代码中基本原则的应用 项目设计中模式的使用 OOP编程要点 实现一个最简单的实例 计算立体型几何体体积 要点: 分析其中的耦合性、 程序的复用性 “脏代码”分析 OO基本原则 单一职责原则(SRP原则) 就一个类而言,应该只有一个引起它变化的原因; 失败的案例: 界面处理类+数据库操作+文件读写+业务流程控制 类比: 多功能手机、集成主板的电脑—坏一处就全坏 经验: 类的设计倾向于越小越好 解释: 如果一个类承担的职责过多,就等于把这些职责耦合在一起。一个职责的变化可能会引起消弱或抑制这个类完成其他职责的功能。这种耦合会导致脆弱的设计。当变化发生时,设计会遭到意想不到的破坏。 开-闭原则(核心原则) 软件实体(类、模块、方法)应该可以扩展,但不可以修改; 换个说法: 类对扩展是开放的, 对修改是封闭的; 用extends 和implements等开放,用private封闭 实际使用: 1.随时准备修改:改变是合理的; 2.原来的代码一般不要改动,合理的方法是 基于原先的代码产生新
文档评论(0)