public class FooAmusementPark {
private FooZoo zoo;
private FooAquarium aquarium;
public void enjoy(FooFamily family) {
zoo.enjoy();
}
public void enjoy(FooCouple couple) {
aquarium.enjoy();
}
}
FooAPI fooAPI = new FooAPI(lat, lng);
FooPlace place = new FooPlace();
place.setAddress(fooAPI.getPostalCode() + " " + fooAPI.getAddress()); // 邮编 **市**区
place.setStation(
new StringJoiner(",")
.add(fooAPI.getStation1())
.add(fooAPI.getStation2())
.add(fooAPI.getStation3())
.toString()); //A车站，B车站，C车站
上面代码是API返回信息整形用例。这里只使用了FooAPI,未来如果返回信息的整形方式不变的话，倒也没有什么问题。但从易维护的角度思考，这称不上一个好的设计。
Continue reading
关于设计模式可以理解为，那些经常会遇到的问题以及如何解决所洗练出来的总结。所以我们在考虑进行设计时，首先要做的就是查询当前所面临的问题，是否已经有很好的解决方案，而不是闭门造车。身边有些同事喜欢需求来了，直接上来就撸代码，认为为了迎合设计模式而设计的工作，会有过度设计的嫌疑。什么时候是导入新工具，新技术的最佳时机？当一个事物让人难以忍受的时候，这时改变所带来的团队收益远大于痛苦程度，就可以很平缓地推进。反之，强推工具反而引来的不是技术上的问题，而是人为的抵制。是不是很奇妙！
本文主要通过问题配合设计模式，来说明设计模式所带来的前后效果，加深大家各种模式的印象。