给我馍馍/文
引言
作为技术开发人员,我们无法保证我们写出来的代码的可用时间和保质期,也许今天刚上线的一个功能,等到明天就因为需求变动不得不进行更改。
为什么会不断的变化
作为技术人员,我们当然希望需求能循序渐进地平稳过度,但往往事与愿违,对于其原因我简单总结为以下几点。
-
用户导向,用户和市场是风向标,它们变了,你的代码就得变。
-
写不出来自适应需求变动的代码,只得快速响应快速应对变化。
-
开发人员无法保证跟你搭伙的产品经理的专业素养和业务能力。
典型的对话
聪明的产品经理跑到Apple官网研究最新款的苹果手机,看着看着脑袋里面就蹦出来了个需求,立刻向你提出他宝贵的idea。
1.我想看看颜色是深空灰色的手机有哪些?
这个功能很简单,你很快就给他开发完了,并且部署上线,双方都很满意。
但是第二天,他又冒出来另外一个想法。
2.我又想看看颜色是金色的手机有哪些?
第三天,又出来另外的想法。
3.价格大于8k的手机有哪些?
通过这个例子我们知道了,不要对产品经理抱有任何的幻想,在代码设计上我应该从需求层面进行更宏观的角度进行考量,对行为进行抽象,进行标准化建模。
行为参数化
下面就让我们一起探究一下行为参数化吧
初始化手机列表
public static List<Phone> initPhoneList() {
List<Phone> phones = new ArrayList<>();
Phone phone1 = new Phone(1, "iPhone 11 Pro", "深空灰色", "64GB", 8699);
Phone phone2 = new Phone(2, "iPhone 11 Pro", "金色", "64GB", 8700);
Phone phone3 = new Phone(3, "iPhone 11 Pro Max", "银色", "64GB", 8900);
phones.add(phone1);
phones.add(phone2);
phones.add(phone3);
return phones;
}
傻白甜式应对需求变化产品说列出深空灰颜色的手机:
public static List<Phone> filterGrayPhoneList(List<Phone> phoneList) {
List<Phone> filteredPhones = new ArrayList<>();
for (Phone phone : phoneList) {
if ("深空灰色".equals(phone.getColor())) {
filteredPhones.add(phone);
}
}
return filteredPhones;
}
产品说列出金色的手机:
public static List<Phone> filterGoldenPhoneList(List<Phone> phoneList) {
List<Phone> filteredPhones = new ArrayList<>();
for (Phone phone : phoneList) {
if ("金色".equals(phone.getColor())) {
filteredPhones.add(phone);
}
}
return filteredPhones;
}
产品又换了另外一个颜色,要你过滤,于是你终于受不了了对颜色这个属性进行提炼写下了下面的方法。
public static List<Phone> filterPhoneListByColor(List<Phone> phoneList, String color) {
List<Phone> filteredPhones = new ArrayList<>();
for (Phone phone : phoneList) {
if (Objects.equals(color, phone.getColor())) {
filteredPhones.add(phone);
}
}
return filteredPhones;
}
如果说,需要要按照价格进行过滤找过大于某个价格的手机,你又会怎么做呢,是不是又再拷贝一份上面的代码,然后把过滤条件替换一下?
public static List<Phone> filterPhoneListByColor(List<Phone> phoneList, int price) {
List<Phone> filteredPhones = new ArrayList<>();
for (Phone phone : phoneList) {
if (phone.getPrice() > price) {
filteredPhones.add(phone);
}
}
return filteredPhones;
}
显然这种抽象方式有它的局限性,我们需要站在更高的层次再进行一次抽象。
经验老手的代码
让我们来想象一下“策略设计模式”,我们定义一个算法族,把它们封装起来(称为“策略”),然后在运行时选择一个算法。
过滤策略的算法族
策略接口:PhonePredicatepublic interface PhonePredicate {
boolean test(Phone phone);
}
按颜色过滤的策略实现:PhoneColorPredicate按价格过滤的策略实现:PhonePricePredicate
然后我们需要创建一个filter方法接受PhonePredicate对象,在filter内部执行test()方法。public class PhoneColorPredicate implements PhonePredicate {
@Override
public boolean test(Phone phone) {
return "深空灰色".equals(phone.getColor());
}
}
public class PhonePricePredicate implements PhonePredicate {
@Override
public boolean test(Phone phone) {
return phone.getPrice() > 8000;
}
}
上面的这个方法,就完成了行为参数化要做的事情,把过滤这个动作看做一个行为,把这个行为用接口的形式进行参数化传递。public static List<Phone> userPredicateImpl(List<Phone> phoneList, PhonePredicate phonePredicate) {
List<Phone> filteredPhones = new ArrayList<>();
for (Phone phone : phoneList) {
if (phonePredicate.test(phone)) {
filteredPhones.add(phone);
}
}
return filteredPhones;
}
用行为参数化的方式传递代码可以让我们的代码更加的清晰专业,更能适应快速变化的需求。public static void main(String[] args) {
System.out.println("filter By Predicate : " + userPredicateImpl(initPhoneList(), new PhonePricePredicate()));
System.out.println("filter By 匿名类 : " + userPredicateImpl(initPhoneList(), new PhonePredicate() {
@Override
public boolean test(Phone phone) {
return "暗夜绿色".equals(phone.getColor());
}
}));
System.out.println("filter By Lambda : " +
userPredicateImpl(initPhoneList(),
(Phone phone) -> "暗夜绿色".equals(phone.getColor())
));
}
总结
-
行为参数化,就是一个方法接受多个不同的行为作为参数,并在内部使用它们,完成不同行为的能力。
-
行为参数化可让代码更好地适应不断变化的要求,减轻开发的工作量。
作者:给我馍馍
博客:https://www.cnblogs.com/givemomo/
本篇文章如有帮助到您,请给「给我馍馍」点个赞,感谢您的支持。
标签:Phone,filteredPhones,代码,List,public,phone,new,Dating,Java8 From: https://www.cnblogs.com/givemomo/p/17961791