实例介绍
【实例简介】
Uncle Bob写的Agile Software Development, Principles, Patterns, and Practices，推荐看一下
trademarks, nor does the use of such trademarks imply any affi PEARSON ISBN10:1-292-02594-8 ISBN13:978-1-292-02594-0 PE O N CUS千OM ABRAR Y Table of contents Section I Agile Development Robert c, martin Chapter I. Agile Practices Robert c. martin Chapter 2. Overview of Extreme Programming Robert c. martin Chapter 3. Planning Robert c, martin 19 Chapter 4. Testing Robert c, martin 23 Chapter 5 Refactoring Robert c. martin Chapter 6. A Programming Episode Robert c. martin 43 Section 2. Agile design Robert c. martin 85 Chapter 7. What Is Agile Design? Robert c. martin 87 Chapter 8. SRP: The Single-Responsibility Principle Robert c. martin 95 Chapter 9. OCP: The Open-Closed principle Robert c. martin 99 Chapter 10. LSP: The Liskov Substitution Principle Robert c. martin 111 hapter I l. DIP: The Dependency-Inversion Principle Robert c. martin 127 Chapter 12. ISP: The Interface-Segregation Principle Robert c. martin 135 Section 3. The Payroll Case Study Robert c. martin 147 Chapter 13. Command and active object Robert c. martin 151 Chapter 14. Template Method Strategy: Inheritance VS. Delegation Robert c. martin 161 Chapter 15. Facade and mediator Robert c. martin 173 Chapter 6. singleton and monostate Robert c. martin 177 Chapter I7 Null Object Robert c. martin 189 Chapter 18. The Payroll Case Study: Iteration One Begins Robert c. martin 193 Chapter 19. The Payroll Case Study: Implementation Robert c. martin 205 Section 4. Packaging the payroll system Robert c. martin 251 Chapter 20. Principles of Package Design Robert c. martin 253 Chapter 21.Factory Robert c. martin 269 Chapter 22. The Payroll Case Study( Part 2) Robert c. martin 275 Section 5. The Weather Station Case Study Robert c, martin 291 Chapter 23. Composite Robert c. martin 293 Chapter 24. Observer-Backing into a pattern Robert c. martin 297 Chapter 25. Abstract Server, Adapter, and bridge Robert c. martin 317 Chapter 26. Proxy and stairway to Heaven Managing Third Party APls Robert c. martin 327 Chapter 27. Case Study: Weather Station Robert c. martin 355 Section 6. The ETS Case Study Robert c. martin 385 Chapter 28. Visitor Robert c. martin 387 Chapter 29. State Robert c. martin 419 Chapter 30. The ets Framework Robert c. martin 443 Appendix A UML Notation I: The CGI Example Robert c. martin 467 Appendix B: UML Notation II: The Statmux Robert c. martin 489 Appendix C: A Satire of Two Companies Robert c. martin 507 Index 517 SECTION 1 Agile Development Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work - Tom de marco and Timothy lister Peopleware, p 5 Principles, patterns, and practices are important, but it's the people that make them work. As Alistair Cockburn says,"Process and technology are a second-order effect on the outcome of a project. The first-order effect is the people We cannot manage teams of programmers as if they were systems made up of components driven by a pro- cess. People are not"plug-compatible programming units. - If our projects are to succeed, we are going to have to build collaborative and self-organizing teams Those companies that encourage the formation of such teams will have a huge competitive advantage over those who hold the view that a software-development organization is nothing more than a pile of twisty little peo ple all alike. A gelled software team is the most powerful software-development force there is Private communication 2. A term coined by Kent Beck From Section 1 of Agile software Development, Principles, Patterns, and Practices, First Edition. Robert C. Martin CopyrightC 2003 by Pearson Education, Inc. All rights reserved 2 Agile practices The weather-cock on the church spire, though made of iron would soon be broken by the storm-wind if it did not understand the noble art of turning to every wind Heinrich heine Many of us have lived through the nightmare of a project with no practices to guide it. The lack of effective prac- ices leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping schedules growing budgets, and poor quality. Developers are disheartened by working ever longer hours to produce ever poorer software. Once we have experienced such a fiasco. we become afraid of repeating the experience. Our fears motivate us to create a process that constrains our activities and demands certain outputs and artifacts. We draw these con- straints and outputs from past experience, choosing things that appeared to work well in previous projects. Our hope is that they will work again and take away our fears However, projects are not so simple that a few constraints and artifacts can reliably prevent error. As errors continue to be made, we diagnose those errors and put in place even more constraints and artifacts in order to pre vent those errors in the future. After many, projects we may find ourselves overloaded with a huge cumbersome process that greatly impedes our ability to get anything done. a big cumbersome process can create the very problems that it is designed to prevent It can slow the team to the extent that schedules slip and budgets bloat. It can reduce responsiveness of the team to the point where they From Chapter l of Agile Software Development, Principles, Patterns, and Practices, First Edition. Robert C. Martin Copyright C 2003 by Pearson Education, Inc. All rights reserved 【实例截图】
【核心代码】
Uncle Bob写的Agile Software Development, Principles, Patterns, and Practices，推荐看一下
trademarks, nor does the use of such trademarks imply any affi PEARSON ISBN10:1-292-02594-8 ISBN13:978-1-292-02594-0 PE O N CUS千OM ABRAR Y Table of contents Section I Agile Development Robert c, martin Chapter I. Agile Practices Robert c. martin Chapter 2. Overview of Extreme Programming Robert c. martin Chapter 3. Planning Robert c, martin 19 Chapter 4. Testing Robert c, martin 23 Chapter 5 Refactoring Robert c. martin Chapter 6. A Programming Episode Robert c. martin 43 Section 2. Agile design Robert c. martin 85 Chapter 7. What Is Agile Design? Robert c. martin 87 Chapter 8. SRP: The Single-Responsibility Principle Robert c. martin 95 Chapter 9. OCP: The Open-Closed principle Robert c. martin 99 Chapter 10. LSP: The Liskov Substitution Principle Robert c. martin 111 hapter I l. DIP: The Dependency-Inversion Principle Robert c. martin 127 Chapter 12. ISP: The Interface-Segregation Principle Robert c. martin 135 Section 3. The Payroll Case Study Robert c. martin 147 Chapter 13. Command and active object Robert c. martin 151 Chapter 14. Template Method Strategy: Inheritance VS. Delegation Robert c. martin 161 Chapter 15. Facade and mediator Robert c. martin 173 Chapter 6. singleton and monostate Robert c. martin 177 Chapter I7 Null Object Robert c. martin 189 Chapter 18. The Payroll Case Study: Iteration One Begins Robert c. martin 193 Chapter 19. The Payroll Case Study: Implementation Robert c. martin 205 Section 4. Packaging the payroll system Robert c. martin 251 Chapter 20. Principles of Package Design Robert c. martin 253 Chapter 21.Factory Robert c. martin 269 Chapter 22. The Payroll Case Study( Part 2) Robert c. martin 275 Section 5. The Weather Station Case Study Robert c, martin 291 Chapter 23. Composite Robert c. martin 293 Chapter 24. Observer-Backing into a pattern Robert c. martin 297 Chapter 25. Abstract Server, Adapter, and bridge Robert c. martin 317 Chapter 26. Proxy and stairway to Heaven Managing Third Party APls Robert c. martin 327 Chapter 27. Case Study: Weather Station Robert c. martin 355 Section 6. The ETS Case Study Robert c. martin 385 Chapter 28. Visitor Robert c. martin 387 Chapter 29. State Robert c. martin 419 Chapter 30. The ets Framework Robert c. martin 443 Appendix A UML Notation I: The CGI Example Robert c. martin 467 Appendix B: UML Notation II: The Statmux Robert c. martin 489 Appendix C: A Satire of Two Companies Robert c. martin 507 Index 517 SECTION 1 Agile Development Human interactions are complicated and never very crisp and clean in their effects, but they matter more than any other aspect of the work - Tom de marco and Timothy lister Peopleware, p 5 Principles, patterns, and practices are important, but it's the people that make them work. As Alistair Cockburn says,"Process and technology are a second-order effect on the outcome of a project. The first-order effect is the people We cannot manage teams of programmers as if they were systems made up of components driven by a pro- cess. People are not"plug-compatible programming units. - If our projects are to succeed, we are going to have to build collaborative and self-organizing teams Those companies that encourage the formation of such teams will have a huge competitive advantage over those who hold the view that a software-development organization is nothing more than a pile of twisty little peo ple all alike. A gelled software team is the most powerful software-development force there is Private communication 2. A term coined by Kent Beck From Section 1 of Agile software Development, Principles, Patterns, and Practices, First Edition. Robert C. Martin CopyrightC 2003 by Pearson Education, Inc. All rights reserved 2 Agile practices The weather-cock on the church spire, though made of iron would soon be broken by the storm-wind if it did not understand the noble art of turning to every wind Heinrich heine Many of us have lived through the nightmare of a project with no practices to guide it. The lack of effective prac- ices leads to unpredictability, repeated error, and wasted effort. Customers are disappointed by slipping schedules growing budgets, and poor quality. Developers are disheartened by working ever longer hours to produce ever poorer software. Once we have experienced such a fiasco. we become afraid of repeating the experience. Our fears motivate us to create a process that constrains our activities and demands certain outputs and artifacts. We draw these con- straints and outputs from past experience, choosing things that appeared to work well in previous projects. Our hope is that they will work again and take away our fears However, projects are not so simple that a few constraints and artifacts can reliably prevent error. As errors continue to be made, we diagnose those errors and put in place even more constraints and artifacts in order to pre vent those errors in the future. After many, projects we may find ourselves overloaded with a huge cumbersome process that greatly impedes our ability to get anything done. a big cumbersome process can create the very problems that it is designed to prevent It can slow the team to the extent that schedules slip and budgets bloat. It can reduce responsiveness of the team to the point where they From Chapter l of Agile Software Development, Principles, Patterns, and Practices, First Edition. Robert C. Martin Copyright C 2003 by Pearson Education, Inc. All rights reserved 【实例截图】
【核心代码】
标签：
好例子网口号：伸出你的我的手 — 分享！
小贴士
感谢您为本站写下的评论，您的评论对其它用户来说具有重要的参考价值，所以请认真填写。
- 类似“顶”、“沙发”之类没有营养的文字，对勤劳贡献的楼主来说是令人沮丧的反馈信息。
- 相信您也不想看到一排文字/表情墙，所以请不要反馈意义不大的重复字符，也请尽量不要纯表情的回复。
- 提问之前请再仔细看一遍楼主的说明，或许是您遗漏了。
- 请勿到处挖坑绊人、招贴广告。既占空间让人厌烦，又没人会搭理，于人于己都无利。
关于好例子网
本站旨在为广大IT学习爱好者提供一个非营利性互相学习交流分享平台。本站所有资源都可以被免费获取学习研究。本站资源来自网友分享，对搜索内容的合法性不具有预见性、识别性、控制性，仅供学习研究，请务必在下载后24小时内给予删除，不得用于其他任何用途，否则后果自负。基于互联网的特殊性，平台无法对用户传输的作品、信息、内容的权属或合法性、安全性、合规性、真实性、科学性、完整权、有效性等进行实质审查；无论平台是否已进行审查，用户均应自行承担因其传输的作品、信息、内容而可能或已经产生的侵权或权属纠纷等法律责任。本站所有资源不代表本站的观点或立场，基于网友分享，根据中国法律《信息网络传播权保护条例》第二十二与二十三条之规定，若资源存在侵权或相关问题请联系本站客服人员，点此联系我们。关于更多版权及免责申明参见 版权及免责申明
网友评论
我要评论