昨天去面试遇到一道java设计机试题，让写出最优设计代码，我用接口实现的，结果被鄙视
题目是这样的，市场上所有商品都要交销售税10%，除了书籍、食品和药品，进口商品还有交5%的进口税，税种和商品种类以后都要变化
给出了一份商品名单表，计算出本商品单总价和总共要交的税
设计出最优的代码，体现面向对象和多态设计，使代码有很好的扩展性
商品种类&&& 单价&&& 数量&& 是否进口
book&&&&&& 12.10&&& 50&&&& 否
music CD&& 11.10&&& 10&&& 是
请各位大神说说自己的设计思路，相互学习。
《重构改善现有代码设计》一书开篇就类似例子，建议去看看
一堆map加一个完了,没有设计模式的模式是最好的模式.
明显规则引擎，呵呵我博客写一篇Bizzwhizz的博客，你看看改改，呵呵他一定满意，喜欢。
我的想法是用装饰者模式，将税收当成装饰，以后不管有多少种税收，只要在原有对象上装饰多一个税收类就能适应变化了，改动也只是多写一个税收类而已。 然后具体的税收标准还可以在计算税收的方法里去实现。又因为需求说明种类是变化的，所以就不太好实现为继承的形式，我想到的是用聚合的方法，这样种类的变化就与商品分离开来了。
class Goods{
//商品类型
private GoodsT
//是否进口
public Goods(){}
public Goods(String name,double price,boolean inlet,GoodsType type){
this.name =
this.price =
this.inlet =
this.type =
public boolean isInlet(){
public String getName(){
public double getPrice(){
public double moneyPayForTax(){
class GoodsType{
public int typeC
public String typeN
public GoodsType(String typeName,int typeCode){
this.typeCode = typeC
this.typeName = typeN
abstract class GoodsTaxDecroter extends Goods{
public GoodsTaxDecroter(Goods goods){
this.goods =
public boolean isInlet(){
return goods.isInlet();
public String getName(){
return goods.getName();
public double getPrice(){
return goods.getPrice();
//根据不同税收，编写税收函数，这样就可以瞒住税收多样的条件要求
public abstract double moneyPayForTax();
class SellTax extends GoodsTaxDecroter{
//税收比例
private double percent = 0.1;
public SellTax(Goods goods){
super(goods);
public double moneyPayForTax(){
return goods.getPrice() * percent + goods.moneyPayForTax();
class InletTax extends GoodsTaxDecroter{
//税收比例
private double percent = 0.2;
public InletTax(Goods goods){
super(goods);
public double moneyPayForTax(){
if(goods.isInlet()){
return goods.getPrice() * percent + goods.moneyPayForTax();
return goods.moneyPayForTax();
public class Test{
public static void main(String[] args){
Goods book = new SellTax(new Goods(&设计模式&,56.0,false,new GoodsType(&书籍&,1)));
Goods musicCD = new InletTax(new SellTax(new Goods(&音乐CD&,11.0,true,new GoodsType(&影音&,2))));
System.out.println(book.getName()
税收 : & + book.moneyPayForTax());
System.out.println(musicCD.getName()
税收 : & + musicCD.moneyPayForTax());
....向对象和多态设计 这个我不懂，野路子出身。
加一个免进口税的商品种类配置表... 然后写个sql.....
是不是想太多了，一个抽象的商品类+N个具体的商品，各个商品实现自己的计算价格不就行了么？
税种和商品种类以后都要变化，变化的东西应该抽象，所以商品、税种都应该继承或者是接口。税种和商品都在变化，所以计算税金的方法也应该抽象，是一个接口，用策略模式实现税金计算比较合理。
--- 共有 1 条评论 ---
我刚开始设计时就忽略了商品，定义了个商品基本类，税金计算用了接口和策略模式，如果商品采用抽象继承的话，抽象类还有实现接口吗？各个子类还用实现接口吗，我有点迷糊，搞不太清楚
接口，或者类。
标准的策略模式场景吧？？
我觉得接口比较好，继承或者实现一下，定义点关键属性 就OK了。。。不懂什么设计模式。。。& & 搞java的同学们可能对无副作用这个概念比较陌生，这是函数式编程中的一个概念，无副作用的意思就是： 一个函数（java里是方法）的多次调用中，只要输入参数的值相同，输出结果的值也必然相同，并且在这个函数执行过程中不会改变程序的任何外部状态（比如全局变量，对象中的属性，都属于外部状态），也不依赖于程序的任何外部状态。& & 比如下面的两个方法，就可以认为是无副作用的。/** *
* @author leo * */public class NoSideEffect {
public static int add(int a, int b) {
return a+b;
public boolean isEmpty(String s) {
if (s == null || s.trim().length() == 0) {
return true;
return false;
}}下面是有副作用的例子：/** *
* @author leo * */public class HasSideEffect {
public int baseV
public int getCount(int addtion) {
return baseValue +
}}& & 无副作用的要求可以很严格，在Fp（functional programing）的语言如lisp clojure中，无副作用的方法中连print都不能有，因为他们认为连屏幕也是外部状态，我个人觉得在写java的无副作用代码时，可以放宽一点，这个度可以自己把握，自己用着爽就ok。& & &线程安全&是java中一个比较常见的概念，线程安全的类，是说不管多少个线程并发访问这个对象，都不会发生不可预期的错误，他们的表现跟单线程访问时一样，是安全可靠的。 无副作用和线程安全的概念有相似之处，无副作用的方法，一定是线程安全的，这两个概念都能够帮助写出并发友好的代码，无副作用的编程还有一个好处，代码会很清爽，因为这个方法里的代码只跟输入输出有关系， 习惯了写无副作用的代码，能够设计出更稳健的程序。 大家可以想象，如果一个系统的代码，到处是状态，到处有千丝万缕的联系，这个系统的可维护性会是怎么样的，写过几年代码的人，可能都会碰到过这种让人头疼的项目。下面介绍几点我个人积累的关于java无副作用编程的经验：1. 使用静态方法& & 我经常把一些常用的工具方法，甚至小项目中的业务方法写成utils类的静态方法，这些方法尽量写成无副作用的，这样的结果是，数据和操作分开，我感觉用起来比较好。
1 public class AgentUtils {
private static long lastMsgIdTime = 0L;
public static synchronized String createNewMsgId(String clientId) {
long now = System.currentTimeMillis();
if (now &= lastMsgIdTime) {
now = lastMsgIdTime + 1;
Date nowTime = new Date(now); 11
String timeStr = DateFormatUtils.format(nowTime, "yyyyMMddHHmmssSSS"); 12
lastMsgIdTime = 13
return clientId + "_" + timeS 14
public static TASK_REPORT_req createTaskReportAndUpdateLocalState(TASK_ASSIGN_req task, WorkItemState workItemState) { 17
TASK_REPORT_req req = new TASK_REPORT_req(MsgType.TASK_REPORT); 18
req.imei = task. 19
req.taskId = task.taskId; 20
req.testType = task.testT 21
req.workItemState = workItemS 22
TaskQueue.updateLocalTestWorkState(req.taskId, req.imei, workItemState); 23
private static Gson gson = new GsonBuilder().setDateFormat("yyyy-MM-dd HH:mm:ss:SSS").create(); 27
public static Meta getMeta(String message) { 29
Gson gson = new GsonBuilder().setDateFormat("yyyy-MM-dd HH:mm:ss:SSS").create(); 30
BaseMsg warp = gson.fromJson(message, BaseMsg.class); 31
return warp. 32
public static Gson getGson() { 35
Gson gson = new GsonBuilder().setDateFormat("yyyy-MM-dd HH:mm:ss:SSS").create(); 36
* @param LocalOrRemote 0 :local 1:remote 41
* @param serverApkPath 42
* @return 43
public static String downloadAPK(int LocalOrRemote, String serverApkPath, String taskId) throws IOException { 45
File src = new File(serverApkPath); 46
String localFileName = buildFullPath(AgentConf.i.apk_file_base_dir, taskId + "_" + src.getName()); 47
//使用scp实现下载 49
if (LocalOrRemote == 0) { 50
FileUtils.copyFileToDirectory(src, new File(AgentConf.i.apk_file_base_dir)); 51
return localFileN 52
//remote 使用scp实现下载 54
boolean isShellSuccess = false; 55
String shell = AgentConf.i.apk_download_cmd + " " + AgentConf.i.server_ip + " " + serverApkPath + " " + localFileN 57
("exec shell:" + shell); 58
returncode = Runtime.getRuntime().exec(shell).waitFor(); 61
} catch (InterruptedException e) { 62
e.printStackTrace(); 63
return null; 64
("shell returncode:" + returncode); 66
isShellSuccess = returncode == 0; 68
// 检查是否成功，修改queue中状态 70
if (isShellSuccess) { 71
return localFileN 72
} else { 73
return null; 74
* @param LocalOrRemote
0 :local 1:remote 79
* @param localReprotPaht 80
* @param serverReportPath 81
* @throws IOException 82
public static void uploadReport(int LocalOrRemote, String localReprotPaht, String serverReportPath) throws IOException { 85
//使用scp实现下载 86
if (LocalOrRemote == 0) { 87
FileUtils.copyFile(new File(localReprotPaht), new File(serverReportPath)); 88
return; 89
//remote 使用scp实现下载 91
String shell = AgentConf.i.report_upload_cmd + " " + AgentConf.i.server_ip + " " + localReprotPaht + " " + serverReportP 93
("exec shell:" + shell); 94
returncode = Runtime.getRuntime().exec(shell).waitFor(); 97
} catch (InterruptedException e) { 98
throw new IOException(e.getMessage(), e); 99
("shell returncode:" + returncode);101
return;102
}103 }View Code 这种做法破坏了面向对象编程的原则，不过我觉得面向对象和面向过程，函数式编程都是工具，不是宗教，不需要严格的遵守，如果发现了更适合自己的工具，不用去死守原则。&2. 不可变对象& & 所有字段都设置成final的，只许赋值一次，保证对象不会被改变 1 /** 2
* @author leo 4
*/ 6 public class TaskData { 7
public TaskData(long taskId, String pkgName,Date updatedAt) { 8
this.taskId = taskId; 9
this.pkgName = pkgN10
if (updatedAt == null) {11
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");12
updatedAt =
sdf.parse(" 01:01:01");14
} catch (ParseException e) {15
Main.log.error(e);16
this.updatedAt = updatedAt;19
public final long taskId;22
public final String pkgN23
/**最后一次处理的时间*/24
public final Date updatedAt;25
public final Date now = new Date();26
@Override28
public String toString() {29
return "TaskData[taskId:" + this.taskId + ",pkgName:" + this.pkgName + "]";30
}31 }View Code & & 这是一种极端的防止副作用出现的做法，实际应用中可以做些妥协，自己意识到就好了。3. 考究的设计，克制的写代码& & 呵呵，这一条好像跟废话一样。不管是面向什么编程模式，软件设计本身更重要，没有好的设计抽象，不可能写出好代码，架构代码和业务代码要有清晰的划分，业务和业务之间的代码尽量的减少耦合，不要写出有千丝万缕联系的代码， 这些都是设计的原则， 无副作用编程 也一样，只是一个帮助做出好设计的编程原则， 我一直觉得，设计就是约束， 好的设计，就是要不断的给整个系统的代码添加约束，某个地方，不能做什么，某个地方，只能做什么， 如果没有约束，谁谁都可以上天入地，这不可能是一个好维护的软件。&& & 关于设计，我给不出具体的代码，对自己代码有追求的人，会不断提高自己做设计的能力，没有追求的人，你手把手教他他都会觉得你烦。& & 关于无副作用编程，感觉想说的不少，能说清楚的不多，建议写java的同学们能学一门动态语言或者函数式编程的语言，比如ruby python clojure，有挺多值得我们借鉴，瞎写瞎看吧 呵呵，欢迎拍砖，等有新想法了我再来完善。
最新教程周点击榜
微信扫一扫1111人阅读
java（30）
一、不要使用魔法数字，尽量定义枚举、常量、宏：&
我常常见到表示各种状态的数字，0，1，2....，我真的不知道这表示什么含义，如果&
你在不在文档中说明的话，这个东东过几天连你自己都不知道个一二三了。&
二、命名要具有描述力，尽量使用全名而不是自创的缩写，除非地球人都这么用这个缩写：&
我常常看到一些自创的缩写，这个缩写或许只有你自己知道，类名，方法名，参数名&
尤其要有好的描述里，局部变量尚可容忍。我宁可容忍超过40个字符的命令，也不愿意&
看到只有一两个字母的命名，当然迭代用的i,j除外。当然命名不要太长，太长说明你的类和&
方法要做的事情太多，请你拆分出更多细粒度功能单一的类和方法。&
三、同一类东东命名方式尽可能统一，比如类名使用大写字母开头的单词，变量使用&
下划线分割开来的小写字母单词，常量使用下滑线分割的开来的大写字母单词。不要&
交替使用。&
四、函数、类功能尽可能单一，不要试图写一个万能/超级函数或者类。&
一个类和方法要有单一的职责，这样的类和方法只做一件事，并且容易把他做好。&
1、不要试图写一个强大无比的方法。&
我常常看到一些试图写的多么“精妙”无比多么“强大”的函数，事实上不是什么精妙，而是&
代码的臭味道。精妙强大无比万能的方法往往你耗费大量精力去设计算法，试图覆盖现在的各&
种可能，而无法面对将来新的需求，随着新的需求，你的这个精妙的方法需要的修改并且改起来&
极其痛苦。在一次次的痛苦与精妙的演化中，你的方法越来越复杂，并且每一次修改你都会面&
临影响以前功能的风险。这个方法使用者需要小心的处理你的精妙之处，如果没有精妙传递好参&
数，那么这个方法再也不精妙了，而是直接废掉了。&
KISS（keep it simple and stupid）原理就是这个道理，你要使你的代码尽可能简单，让人&
看到有一目了然的清爽，而不是因为设计了一个精妙无比的万能方法而沾沾自喜。这里的简单不是&
简洁的代名字。有时候简洁是那种传说的“精妙”的代码。&
2、不要写做多件事情的方法和类，你做一件事情，你就写一个对应的方法，不要试图通过参数来判定各种情况，然后做事情，并且做的事情和你方法描述的不一致。当你发现你的方法名字想不出来好的名字了，或者要加or和and了，那么请你拆分出更多单一的方法。&
不要举一些linux完成多种功能系统调用，这是被迫的，因为系统调用的数量是有限制的，它只有有限的空间来描述系统调用号和系统调用的映射表，不要在应用程序开发中效仿而误以为优雅强大。我最恶心根据参数，然后一大堆的if..else 和switch..case判断。&
五、不要修改已有的类和方法而是扩展它。&
这是程序设计的一个重要原则，开闭原则，在面向对象的语言中尤为重要。在面向过程中主要表现在，不要在一个函数要应对和这个函数相似的一个需求了，就在这个加个if，来修改这个方法，试图重用和避免重复。而是要把公用的部分抽出来成一个小的功能函数，然后增加一个应对新的类似这个需求的处理方法。在面向对象中，例如使用策略模式、访问者模式、Extend
Object模式。&
六、不要重复你自己（DRY）：&
程序最怕的是copy,paste，到处是重复的代码。copy，paste经常被误以为快速完成需要用的功能的高效方式而被到处使用。你每重复一次，你就得负责保持他们的一致性，你就得在一处增加新的功能时，你就的把这个的功能加到其他地方。还在我刚会写代码的时候去了一个小公司，他们的代码到处是copy，paste的痕迹，当要在现有的功能增加审计功能是，他们开始下命令了，每个人加几行代码来做审计，真不知道那么多人写的审计版本，分散到那么多处，这个审计功能是否可信有用。&
避免DRY的方法就是抽象，分离变化。不管是面向对象还是面向过程，分离变化并抽象之是最主要的设计原则。设计模式中的模板方法，我们常用的回调都是我们常用的方法。&
我发现越是提供更多回调处理的语言和框架，就越具有灵活性和易用性。ruby语言之所以有如此的威力，主要是因为它提供了更多的回调处理。它可以在动态的给一个类增加方法，这样可以在超类中定义增加方法的方法，然后再子类调用，子类就具有无比的能力。它的block提供了强大的回调机制，我只要不知道如何处理了我就yield出来，method
missing机制更是神秘无比，你可以写出像find_by_name_and_age,2.days.ago这样像自然语言一样易读的代码。&
七、不要跨越边界，在适合的地方写代码。&
在分层的架构中，不要跨越层的边界。例如web开发的三层架构:&
数据访问层（DAO)、业务层(Service)、表现层。&
不要在业务层裸写SQL来做事情，不要在业务层掺和进来表现层的东东，不要在表现层/控制器中写业务的东东。既然已经分层了，那么就要好好的遵守它，如果到处跨越边界的话，那么和不分层没有什么区别，使得每一层都不伦不类。例如你应该在业务层进行事务管理，而你的控制器到处是业务代码，那将无法控制。如果你的业务层到处是SQL，我不知道你的DAO存在的意义了。&
八、分层的web架构：&
DAO层最好按照模型来划分dao类，如果业务很简单，也可以将相关的模型合并为一个DAO。&
Service层，不要按照DAO和Service一一对应的方式划分，而是要按照业务的类别和实际情况来划分。事实上Service层通常是用来处理涉及到多个模型的业务，而涉及到一个模型的业务，常常被放在模型中，这是一种自然而更面向对象的设计方法。只有数据的模型被称为贫血型模型，这种模型被认为是对面向对象的一种背离，而在模型中放置专有的业务方法，不仅有利于公用，而且模型更具有描述力。&
九、关于MVC:&
MVC是一种松耦合的设计方案，最容易误用的就是控制器（c）。控制器只负责调用业务方法，准备好数据供View去展现。而不要把业务和如何展示的东东放在里面。我常常看到有人在控制器中拼html片段和写一些业务相关的代码。
十、顺便说一下异常的使用。&
如果你是使用语言支持异常机制，那么尽可能的使用异常机制和定义好与自己业务相关的异常，而不是通过返回值表示正确和错误。如果你使用的语言支持异常机制，请不要写类linux下c似的代码形式，每写一个函数，我就写一个判断返回值调用是否成功，严重分离了我对核心业务的关注。异常提供了优雅的处理错误的方法。&
总之，你在写代码的时候，你尽量考虑使用你接口的人和阅读你代码的人，不要让他们不爽。&
先写到这里，希望对大家有所帮助
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：24916次
排名：千里之外
原创：35篇
转载：24篇
(1)(1)(2)(3)(1)(1)(1)(4)(2)(3)(1)(1)(16)(12)(4)(4)(1)(1)}