敏捷软件开发:原则、模式与实践 一次编程实践 保龄球记分代码

//类Score
package com.java.bowlingscore;
public class Scorer {
public void addThrow(int pins){
itsThrows[itsCurrentThrow++]=pins;
}
public int scoreForFrame(int theFrame){  
int score = 0;
ball = 0;
for(int currentFrame=0;currentFrame<theFrame;
currentFrame++){
if(strike()){
score +=10 + nextTwoBallsForStrike();
ball++;
}else if(spare()){
 score+=10+nextBallForSpare();
 ball+=2;
}else{
score +=twoBallsInFrame();
ball+=2;
}
}
return score;
}
private boolean strike(){
return itsThrows[ball]==10;
}
private boolean spare() {
return (itsThrows[ball]+itsThrows[ball+1]==10);
}
private int nextTwoBallsForStrike(){
return itsThrows[ball+1]+itsThrows[ball+2];
}
private int nextBallForSpare(){
return itsThrows[ball+2];
}
private int twoBallsInFrame(){
return itsThrows[ball]+itsThrows[ball+1];
}
private int ball;
private int[] itsThrows = new int[21];
private int itsCurrentThrow=0;
}

类Game

package com.java.bowlingscore;
public class Game {
public int score(){
return scoreForFrame(itsCurrentFrame);
}
public int getCurrentFrame(){        
return itsCurrentThrow;
}
public void add(int pins){  
 itsScorer.addThrow(pins);
 adjustCurrentFrame(pins);   
}
private void adjustCurrentFrame(int pins) { 
if(lastBallinFrame(pins)){
advanceFrame();
}else{
firstThrowInFrame = false;
}
}
private boolean lastBallinFrame(int pins) {
return strike(pins)||(!firstThrowInFrame);
}
private boolean strike(int pins) {
return (firstThrowInFrame&&pins==10);
}
private void advanceFrame() {
itsCurrentFrame = Math.min(10, itsCurrentFrame+1);
}
public int scoreForFrame(int theFrame){
return itsScorer.scoreForFrame(theFrame);
}
private Scorer itsScorer = new Scorer();
private boolean firstThrowInFrame=true;
private int itsCurrentFrame=1;
private int itsCurrentThrow=0;
}

一个晚上看着书一步一步敲出的,在代码重构方面学习到了不少,明天自己试着写一个.

原文地址:http://blog.51cto.com/10760006/2156983

时间: 2024-10-19 20:35:15

敏捷软件开发:原则、模式与实践 一次编程实践 保龄球记分代码的相关文章

敏捷软件开发:原则、模式与实践(笔记)

一.敏捷软件开发宣言 1.个体和交互 > 过程与工具 a)人是获得成功最为重要的因素: b)合作.沟通以及交互能力要比单纯的编程能力更为重要: c)团队的构建要比环境的构建重要. 2.可以工作的软件 > 面面俱到的文档 a)文档应该短小并突出主题: b)在给新的团队成员传授知识方面,最好的两份文档是代码和团队: c)直到迫切需要并且意义重大时,才来编制文档. 3.客户合作 > 合同谈判 a)成功的项目需要有序.频繁的客户反馈. 4.响应变化 > 遵循计划 a)构建计划时,应该确保计

敏捷软件开发 – STATE模式

地铁旋转门 最直接的实现FSM策略的方式是使用嵌套switch/case语句. public enum State { LOCKED, UNLOCKED }; public enum Event { COIN, PASS }; public class TurnStile { private State state = State.LOCKED; private TurnstileController turnstileController; public TurnStile(Turnstile

敏捷软件开发原则

敏捷软件开发原则 ----<敏捷软件开发原则.模式与实践>学习笔记 最近在系统地学习并且有意地在工作中实践敏捷软件开发,文章乍看起来,都是一些说教性.理论性,比较无聊的东西. 但是如果静下心来结合自己自身的经历.思考地去阅读,可能会发现,有的观点确实很赞同,然而有的可能会有自己的想法. 以下是在<敏捷软件开发 原则.模式与实践>一些读书笔记,斜体字是直接摘录于书本,非斜体字是自己的一些理解.   一.尽早的,持续地交互有价值的软件来使客户满意.初期交付的系统功能越少,最终交付的系统

敏捷软件开发 – FACADE模式和MEDIATOR模式

FACADE模式 Db类使得Application类不需要了解System.Data命名空间中的内部细节.它把System.Data的所有通用性和复杂性隐藏在一个非常简单且特定的接口后面. 像Db这样的FACADE类对System.Data的使用施加了许多规约.它知道如何初始化和关闭数据库连接.它知道如何将ProductData的成员变量转换成数据库字段,或反之.它知道如何去构建合适的查询和命令去操纵数据库.它对用户隐藏了所有的复杂性.在Application看来,System.Data是不存在

[书摘]《敏捷软件开发: 原则、模式与实践》第一部分:敏捷开发

面向对象设计的原则 单一职责 开放-封闭 Liskov替换原则 依赖倒置原则 接口隔离原则 重用发布等价原则 共同封闭原则 共同重用原则 无环依赖原则 稳定以来原则 稳定抽象原则 人的重要性 交付产品的关键因素是人,而不是过程.(敏捷 Agile) 人与人之间的交互式复杂的,并且其效果从来都是难以预期,但却是工作中最为重要的方面. ------ Tom DeMacro 和 Timothy Lister<人件> 有凝聚力的团队将具有最强大的软件开发力量. 敏捷软件开发宣言 我们一直在实践中探寻更

读书笔记-敏捷软件开发 原则,模式与实践

看了一下夹在书中的发票,2010年在当当网购买的. 断断续续的也看过几次,一直没有看完过. 这次试着写写读书笔记.看看能不能坚持住.

敏捷软件开发 – OCP 开放-封闭原则

软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改的. 如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就具有僵化性的臭味.OCP建议我们应该对系统进行重构,这样以后对系统再进行这样那样的改动时,就不会导致更多的修改.如果正确地应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码. OCP概述 遵循开放-封闭原则设计出的模块具有两个主要的特征.它们是: 对于扩展是开放的(open for extension).这意味着模块的行

敏捷软件开发 – SRP 单一职责原则

SRP:单一职责原则  一个类应该只有一个发生变化的原因. 为何把两个职责分离到单独的类中很重要呢?因为每一个职责都有变化的一个轴线.当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个. 如果一个类承担的职责过多,就等于把这些职责耦合在了一起.一个职责发生变化可能会削弱或抑制这个类完成其他职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏. 有两个不同的应用程序使用Rectangle类.一个应用程序是有关计算几何

敏捷软件开发 – ABSTRACT SERVER模式、ADAPTER模式和BRIDGE模式

设计运行在简易台灯中的软件.台灯由一个开关和一盏灯组成.可以询问开关是开着还是关着,也可以让灯打开或者关闭. 下面设计了一个简易的模型.Switch对象可以轮询实际开关的状态,并且可以发送相应的turnOn和turnOff消息给Light. 这个设计违反了两个设计原则:依赖倒置(DIP)和开放-封闭(OCP).对DIP的违反是明显的,Switch依赖了具体类Light.DIP告诉我们要优先依赖于抽象类.对OCP的违反虽然没有那么明显,但是更加切中要害.我们之所以不喜欢这个设计是因为它迫使我们在任

敏捷软件开发 – ISP 接口隔离原则

如果类的接口不是内聚的,就表示该类具有“胖”接口.换句话说,类的“胖”接口可以分解成多组方法.每一组方法服务于一组不同的客户程序. ISP承认有一些对象确实需要有非内聚的接口,但是ISP建议客户程序不应该看到它们作为单一的类存在.相反,客户程序看到的应该是多个具有内聚接口的抽象基类. 接口污染 考虑一个安全系统.在这个系统中,有一些Door对象,可以被加锁和解锁,并且Door对象知道自己是开着还是关着.这个Door编码成一个接口,这样客户程序就可以使用那些符合Door接口的对象,而不需要依赖于D