上一篇写了关于下单优惠的计算,项目迭代了几期,产品又提出要在下单后支付前还要有新的优惠措施,以一种不同面值的代币形式.买家可以选择不同面值的组合减免支付金额.

问题描述

当用户下单后进入支付页面,系统优先计算出最划算的组合,供给用户选择.故实际付款金额=下单金额-代币组合值,代币不限数量,所以组合会有很多组合.例如有10,10,45,50,100的面值的代币,下单金额为75,最优组合为10,10,50.

在电商平台通常会有一些优惠措施,比如以优惠券、定金或者代币之类的形式在下单时给予用户直观的减免金额.一般用户领取店铺优惠券,优惠券有不同的使用条件,满足条件时方可使用.定金为用户自己向店铺购买的形式,定金在特定的时间或者针对某个商品可以膨胀使用,膨胀出多余的部分相当商家让利,可以优惠购买.代币为商家以不同面值发放给用户,以抵扣下单金额.

问题描述

假设某个店铺有好多不同使用条件的优惠券比如满20减去5,满20减10,每满20减5,每满20减21(其实我也不知道这个的意义什么,但是产品说就要发这样的券),然后用户还分别购买了20,30,60的定金,当用户下单金额为200元时,用户自己就难以选择,无法立即计算出支付最少的钱购买此单商品,所以需要我们计算匹配出一个最划算的组合给用户.当然优惠券和定金只能各选一个.

解决思路

作为用户来讲,当然优先使用优惠券,因为优惠券为商家赠与而定金时自己购买,故支付金额=订单金额-优惠券的优惠金额(因为包含每满类型,所以不一是优惠券面值)-定金.那么大概思路就是定金和优惠券的组合,相当于两层for循环,然后按照这个公式算出支付金额大于等于零的那个值就可以了.思路时挺简单,但是优惠券的逻辑就有点复杂,以为优惠券自身就有好多种组合,例如满10减5,满10减8,每满10减8,满5减8,每满5减8,所以优惠券的顺序应该根据是否每满、优惠满足金额、优惠金额排序.

选择头像、图片时经常使用拍照和相册功能,但是由于 Android 碎片化问题,不同版本 API 有差异,并且在不同页面处理 onActivityResult 感觉太麻烦,所以就想着可以通过链式调用,将这些逻辑封装起来,让整个代码写起来简洁清晰明了,不至于好多类似代码重复,提高开发效率.

选择图片存在的问题

Android 6.0 运行时权限

在 Android 6.0 中严格限制App的权限授予,读取 SD 卡、拍照、录音、定位、短信、通讯录等关键权限需要在代码中申请这些权限,否则会抛出异常导致程序奔溃,当 App 申请权限被拒绝后我们应该给用户弹出提示框,引导用户去设置页开启此权限,然后在 onRequestPermissionsResult 中处理回调结果.

Android 7.0 StrictMode 问题

在 Android 7.0 中强制启用了被称作 StrictMode 的策略，带来的影响就是你的App对外无法暴露 file:// 类型的 URI,否则会出现 FileUriExposedException 异常,进程间应使用 FileProvider 共享文件.

三星机型图片选择问题

在三星机型中,当我们调用相机拍照后,获取的图片发现被旋转90度,所以需要获取图片的 ExifInterface 信息,然后根据 orientation 进行图片的角度旋转,使之方向正确.

解决方式

针对以上问题写一个 library 就显得很有必要.方便在不用页面调用选择图片.在一个透明背景的 Activity 中处理以上问题,让调用方无感知以上问题,只用传入必要的设置条件最后拿到图片文件就可以,然后针对文件进行自己的业务逻辑操作即可.

在日常开发中会分测试、预发、生产等环境,不同环境下请求 Host 不一致,原来的解决方案是通过定制不同的 Flavors,通过添加 applicationIdSuffix 可以让多个 App 同时安装在手机方便测试,但是又产生新的问题,每次都要打包上传不同的 App 让测试安装,这样感觉略显麻烦,所以就想到能不能 App 内部做环境切换,这样切换自如,无需重新打包.

面向对象的六大原则

• 单一职责原则(SRP):一个类应该仅有一个引起它变化的原因。
• 开闭原则(OCP):软件中的对象应该对于扩展是开放的，对于修改是封闭的。
• 里氏替换原则(LSP):所有引用基类的地方必须能透明的使用其子类。
• 依赖倒置原则(DIP):模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的。
• 接口隔离原则(ISP):客户端不应该依赖它不需要的接口。
• 迪米特原则(LOD):一个对象应该对其他对象有最少的了解。

在开发过程中把握平衡点，使系统可以具有高稳定性、高可扩展性并且高内聚、低耦合，在不断迭代中完善架构。

系统

• 将系统的构造与使用分开，如依赖注入(DI)、控制反转(IoC)
• 保证系统良好的的扩容性，使用面向切面编程(AOP)方式编程

对于系统这章不能透彻理解，平时对于架构没有深入理解，系统应该是随着业务的变化而变化，没必要先做大设计而限制后续设计思路，保证大概可工作的最简单方案即最合适。

读的技术书、社科书，现在想想总感觉能回忆起来的太少，看过也就当看过了，没有内化为自己的内容。所以这本书起开始做读书笔记，也便于以后查阅。看了下上篇博文距离现在竟然有一年多了，真是快废了，还好现在拾起来。

整洁代码：

外表或举止上令人愉悦的优美和雅观；令人愉悦的精致和简单 –Bjarne Stroustrup

如果每个例程都让你感到深合己意，那就是整洁代码。如果代码让编程语言看起来像是专为解决那个问题而存在，就可以称之为漂亮的代码。 –Ward Cunningham

这便是书写代码的最高境界，在实践过程中确实不易,唯有持之以恒的坚持自省，正如不易确实需要一个军规让营地比你来时更干净，在每次修改时心里默念这句，对看到繁琐的代码及时梳理使其变得简洁、清晰、明了，或许仅仅重命名就可以有这样的效果。