2024年最全程序员必看！代码写得好，工资涨的早。四步教你写出漂亮代码。，2024年最新华为ios面试题_@mappings({ @mapping(target = "genderlabel", expre-CSDN博客

本文链接：https://blog.csdn.net/2301_82244158/article/details/138989255

如何成为Android高级架构师！

架构师必须具备抽象思维和分析的能力，这是你进行系统分析和系统分解的基本素质。只有具备这样的能力，架构师才能看清系统的整体，掌控全局，这也是架构师大局观的形成基础。 你如何具备这种能力呢？一是来自于经验，二是来自于学习。

架构师不仅要具备在问题领域上的经验，也需要具备在软件工程领域内的经验。也就是说，架构师必须能够准确得理解需求，然后用软件工程的思想，把需求转化和分解成可用计算机语言实现的程度。经验的积累是需要一个时间过程的，这个过程谁也帮不了你，是需要你去经历的。

但是，如果你有意识地去培养，不断吸取前人的经验的话，还是可以缩短这个周期的。这也是我整理架构师进阶此系列的始动力之一。

成为Android架构师必备知识技能

对应导图的学习笔记(由阿里P8大牛手写，我负责整理成PDF笔记）

部分内容展示

《设计思想解读开源框架》

目录
热修复设计
插件化框架设计

《360°全方面性能优化》
设计思想与代码质量优化
程序性能优化

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化学习资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

SalesCouponNameErrorCode.COUPON_NAME_ES_QUERY_ERROR.getMessage(),
searchCouponNameDTO);
}
if (searchResult != null && searchResult.getHits().getHits().length > 0) {
List idList = getIdListFromEsSearchResult(searchResult);
List salesCouponNamePOList = salesCouponNameMapper.selectByIdList(idList);
List couponNameBOList = SalesCouponNameConvert.INSTANCE
.convertCouponNameBOList(salesCouponNamePOList);
searchCouponNameBO.setList(couponNameBOList);
searchCouponNameBO.setTotal((int) searchResult.getTotalHits());
}
return searchCouponNameBO;
}

在该Service入口方法中，需要根据从ES查询的分页ID去真实的MySQL中进行数据获取（ES数据存储不全，只是为了进行优化性能将分页逻辑放入ES），而在处理ES数据时，需要从ES数据结果集中抽象ID列表，对于这部分逻辑出于代码量的考虑，这里我们抽象一个Service层私有方法，如：

private List getIdListFromEsSearchResult( SearchResult searchResult )
{
SearchHit[] searchHits = searchResult.getHits().getHits();
List idList = Arrays.asList( searchHits ).stream().map( SearchHit: : getSourceAsMap )
.map( o - > Integer.parseInt( String.valueOf( o.get( “id” ) ) ) )
.collect( Collectors.toList() );
return(idList);
}

以上代码示例，本质上是一种最简单的方法抽象（别的语言叫函数），如果在代码量略大，但是逻辑本身复杂度还不是特别高的情况下，这种方式是最常用的！也是在你不知道怎么拆分，让代码不那么难以维护的一种非常有效的手段。

而工厂+责任链等也是业务层拆分常用的手段，此时需要基于Service层业务入口方法进行代码结构的二次拆分，在分层结构上这部分介于Service层和Dao层之间的代码称之为通用业务处理层（Manager）。关于这部分由于可以发挥空间非常大，很难有一套标准的答案，但作为一名优秀的程序设计者要时刻有抽象的思维，不管拆分得是否足够合理，至少要让你的代码不至于过于臃肿！这里我们将Service层拆分层次定义为以下三个等级：

等级1：私有方法拆分；
等级2：工厂+责任链运用（有效的类的拆分）；
等级3：高级设计模式（优雅的类的拆分）；

分层领域模型约定

聊完分层结构接下来我们说一下分层领域数据模型的约定，注意这里的分层领域并不是指“DDD（领域驱动设计）模式”，而是对以上分层结构中各层之间交互数据对象的定义约定。在上述分层结构图中已经标识了DTO、BO、PO的使用范围（本规范只约定三种领域对象，事实上已经足够，并不需要搞的太复杂）。具体如下：在Controller层接收网络请求数据后，由于Controller层并不需要处理额外的逻辑，所以大部分情况下直接将DTO对象传送给Service层；而Service层如果逻辑不复杂只是需要根据DTO的数据进行数据库操作，那么此时根据需要将DTO转换为PO进行操作，完成后由于大部分场景下Service的输出参数与输入DTO对象都存在差异，因此为了区分我们将Service层的输出数据对象统一定义为BO。而Service层拆分时对于Manager层方法的输入/输出对象则统一为BO，包括Manager层操作第三方数据接口的数据对象转换也统一为BO。以上划分并没有什么特别的强制约定，而过分人为的去揣摩其含义本质上也没什么意义，只是大家共同遵守一个约定，这样代码风格看起来会更加统一一点。

三、如何保持代码的简洁性

作为一名对代码有追求的程序员，能少些一行代码就绝对不要啰嗦，而Java丰富的开源生态体系也给了我们这种懒惰很多便利，所以在编程的过程中其实是有很多工具可以帮助节省代码的。这里给大家分别介绍三种方式：

MapStruct

在前面介绍的分层结构中，无论是DTO到BO，还是BO到PO亦或BO到BO，都会有很多的数据对象转换的逻辑，传统的方法是需要通过一堆Setter方法来完成的，而高级一点的lombok包提供的@Builder注解也是需要你写一堆".build()"来完成数据的转换，这样的代码写到Service层中显然很浪费很多代码行，而MapStruct是一种更优雅的完成这件事的工具，使用方法如下：

项目pom.xml中引入依赖：

也需要在pom.xml引入一下Maven插件：

之后编写数据对象映射转换接口：

package com.mafengwo.sales.sp.coupon.convert;

import com.mafengwo.sales.sp.coupon.client.bo.SalesCouponChannelBO;
import com.mafengwo.sales.sp.coupon.client.dto.SalesCouponChannelsDTO;
import com.mafengwo.sales.sp.coupon.dao.model.SalesCouponChannelsPO;
import java.util.List;
import org.mapstruct.Mapper;
import org.mapstruct.Mapping;
import org.mapstruct.Mappings;
import org.mapstruct.factory.Mappers;

/**

@author qiaojiang
*/
@Mapper
public interface SalesCouponChannelsConvert {

SalesCouponChannelsConvert INSTANCE = Mappers.getMapper(SalesCouponChannelsConvert.class);

@Mappings({
@Mapping(target = “flag”, expression = “java(java.lang.Integer.valueOf(“0”))”),
@Mapping(target = “ctime”, expression = “java(com.mafengwo.sales.sp.coupon.util.DateUtils.getCurrentTimestamp())”),
@Mapping(target = “mtime”, expression = “java(com.mafengwo.sales.sp.coupon.util.DateUtils.getCurrentTimestamp())”)
})
SalesCouponChannelsPO convertSalesCouponChannelsPO(SalesCouponChannelsDTO salesCouponChannelsDTO);

@Mappings({})
List convertCouponChannelBOList(List salesCouponChannelsPO);
}

以上方法的入参为源数据对象，而返回对象则为目标数据对象，如果两个对象的字段名称完成一致，那么其实是不需要进行任何单独映射的，直接 @Mappings({})即可；而如果映射对象之间字段名称有差异则可以通过@Mappings({@Mapping(target = “ctime”, source =“createTime”)})进行指定映射。而在业务层方法具体操作时使用方法如下：

这样对象数据之间的拷贝将变得非常容易，从某种层面上看无论代码层次结构多么绕，至少数据对象之间的拷贝将不再是一件麻烦的事！

lambada表达式

在Java8种提供了lambada表达式，在Java8中如果操作List相关数据结构，如果能够使用lambada表达式也可以省一些代码，例如：

有关lambada表达式更多的用法，大家有时间可以多看看相关语法知识，这里就不再赘述！

tk.mybatis

在使用Mybatis框架作为数据库开发框架时，相比较于Hibernate或其他JPA框架，Mybatis具有较强的对原生SQL的支持能力，因而会显得比较灵活。但在大部分互联网系统中，对数据库的操作很多时候都是单表的操作，在这种情况下使用Mybatis也需要在Mapper代码和映射.xml文件中编写大量的SQL，而这些单表SQL本质上大同小异，完全可以通用化。因此在Mybatis领域为了减少开发量很多项目会使用mybatis-generator插件生成一份完整的映射代码，但是这样的方式也会增加大量的无用代码，看起来并不是那么的简洁。而tk.mybatis则是考虑到了这个问题，可以兼顾对单表操作的便捷性（不需要再写额外的代码）、多表联合查询的灵活性以及代码的简洁性。具体用法如下：项目pom.xml文件引入相关依赖：

主类@MapperScan注解换成tk.mybatis的：

import org.springframework.boot.SpringApplication;
import org.springframework.boot.actuate.autoconfigure.elasticsearch.ElasticSearchRestHealthIndicatorAutoConfiguration;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.web.servlet.ServletComponentScan;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.transaction.annotation.EnableTransactionManagement;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
/*不要使用Mybatis原生注解，用tk.mybatis的 */
import tk.mybatis.spring.annotation.MapperScan;

import java.util.Date;

@SpringBootApplication( exclude = { ElasticSearchRestHealthIndicatorAutoConfiguration.class } )
@ServletComponentScan
@EnableDiscoveryClient
@EnableWebMvc
@MonitorEnableAutoConfiguration
@MapperScan( “com.mafengwo.sales.sp.coupon.dao.mapper” )
@EnableTransactionManagement
public class SpCouponApplication
{
public static void main( String[] args )
{
SpringApplication.run( SpCouponApplication.class, args );
}