相親原始碼開發，使用了哪些設計模式來優化業務程式碼？
前言
平時我們寫程式碼呢，多數情況都是流水線式寫程式碼，基本就可以實現相親原始碼的業務邏輯了。如何在寫程式碼中找到樂趣呢，我覺得，最好的方式就是：使用設計模式優化自己的業務程式碼。今天跟大家聊聊在相親原始碼開發中中，都使用過哪些設計模式。
1.策略模式
1.1 業務場景
假設有這樣的業務場景，大資料系統把檔案推送過來，根據不同型別採取不同的解析方式。多數的小夥伴就會寫出以下的程式碼：
if(type=="A"){
//按照A格式解析
}else if(type=="B"){
//按B格式解析
}else{
//按照預設格式解析
}
這個程式碼可能會存在哪些問題呢？
-
如果相親原始碼分支變多，這裡的程式碼就會變得臃腫，難以維護，可讀性低。
-
如果你需要接入一種新的解析型別，那隻能在原有程式碼上修改。
說得專業一點的話，就是以上程式碼，違背了物件導向程式設計的開閉原則以及單一原則。
-
開閉原則（對於擴充套件是開放的，但是對於修改是封閉的）：增加或者刪除某個邏輯，都需要修改到原來程式碼
-
單一原則（規定一個類應該只有一個發生變化的原因）：修改任何型別的分支邏輯程式碼，都需要改動當前類的程式碼。
如果你的程式碼就是醬紫：有多個if…else等條件分支，並且每個條件分支，可以封裝起來替換的，我們就可以使用策略模式來優化相親原始碼。
1.2 策略模式定義
策略模式定義了演算法族，分別封裝起來，讓它們之間可以相互替換，此模式讓演算法的變化獨立於使用演算法的的客戶。
策略模式針對相親原始碼中的一組演算法，將每一個演算法封裝到具有共同介面的獨立的類中，從而使得它們可以相互替換。
1.3 策略模式使用
策略模式怎麼使用呢？醬紫實現的：
-
一個介面或者抽象類，裡面兩個方法（一個方法匹配型別，一個可替換的邏輯實現方法）
-
不同策略的差異化實現(就是說，不同策略的實現類)
-
使用策略模式
1.3.1 一個介面，兩個方法
public interface IFileStrategy {
//屬於哪種檔案解析型別
FileTypeResolveEnum gainFileType();
//封裝的公用演算法（具體的解析方法）
void resolve(Object objectparam);
}
1.3.2 不同策略的差異化實現
A 型別策略具體實現
@Component
public class AFileResolve implements IFileStrategy {
@Override
public FileTypeResolveEnum gainFileType() {
return FileTypeResolveEnum.File_A_RESOLVE;
}
@Override
public void resolve(Object objectparam) {
logger.info("A 型別解析檔案，引數：{}",objectparam);
//A型別解析具體邏輯
}
}
B 型別策略具體實現
@Component
public class BFileResolve implements IFileStrategy {
@Override
public FileTypeResolveEnum gainFileType() {
return FileTypeResolveEnum.File_B_RESOLVE;
}
@Override
public void resolve(Object objectparam) {
logger.info("B 型別解析檔案，引數：{}",objectparam);
//B型別解析具體邏輯
}
}
預設型別策略具體實現
@Component
public class DefaultFileResolve implements IFileStrategy {
@Override
public FileTypeResolveEnum gainFileType() {
return FileTypeResolveEnum.File_DEFAULT_RESOLVE;
}
@Override
public void resolve(Object objectparam) {
logger.info("預設型別解析檔案，引數：{}",objectparam);
//預設型別解析具體邏輯
}
}
1.3.3 使用策略模式
如何使用呢？我們藉助spring的生命週期，使用ApplicationContextAware介面，把對用的策略，初始化到map裡面。然後對外提供resolveFile方法即可。
/**
* @author
*/
@Component
public class StrategyUseService implements ApplicationContextAware{
private Map<FileTypeResolveEnum, IFileStrategy> iFileStrategyMap = new ConcurrentHashMap<>();
public void resolveFile(FileTypeResolveEnum fileTypeResolveEnum, Object objectParam) {
IFileStrategy iFileStrategy = iFileStrategyMap.get(fileTypeResolveEnum);
if (iFileStrategy != null) {
iFileStrategy.resolve(objectParam);
}
}
//把不同策略放到map
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
Map<String, IFileStrategy> tmepMap = applicationContext.getBeansOfType(IFileStrategy.class);
tmepMap.values().forEach(strategyService -> iFileStrategyMap.put(strategyService.gainFileType(), strategyService));
}
}
2. 責任鏈模式
2.1 業務場景
我們來看一個常見的業務場景，下訂單。相親原始碼下訂單介面，基本的邏輯，一般有引數非空校驗、安全校驗、黑名單校驗、規則攔截等等。很多夥伴會使用異常來實現：
public class Order {
public void checkNullParam(Object param){
//引數非空校驗
throw new RuntimeException();
}
public void checkSecurity(){
//安全校驗
throw new RuntimeException();
}
public void checkBackList(){
//黑名單校驗
throw new RuntimeException();
}
public void checkRule(){
//規則攔截
throw new RuntimeException();
}
public static void main(String[] args) {
Order order= new Order();
try{
order.checkNullParam();
order.checkSecurity ();
order.checkBackList();
order2.checkRule();
System.out.println("order success");
}catch (RuntimeException e){
System.out.println("order fail");
}
}
}
這段程式碼使用了異常來做邏輯條件判斷，如果後續邏輯越來越複雜的話，會出現一些問題：如異常只能返回異常資訊，不能返回更多的欄位，這時候需要自定義異常類。
說明：異常設計的初衷是解決程式執行中的各種意外情況，且異常的處理效率比條件判斷方式要低很多。
如何優化這段程式碼呢？可以考慮責任鏈模式
2.2 責任鏈模式定義
當你想要讓一個以上的物件有機會能夠處理某個請求的時候，就使用責任鏈模式。
責任鏈模式為相親原始碼請求建立了一個接收者物件的鏈。執行鏈上有多個物件節點，每個物件節點都有機會（條件匹配）處理請求事務，如果某個物件節點處理完了，就可以根據相親原始碼實際業務需求傳遞給下一個節點繼續處理或者返回處理完畢。這種模式給予請求的型別，對請求的傳送者和接收者進行解耦。
責任鏈模式實際上是一種處理請求的模式，它讓多個處理器（物件節點）都有機會處理該請求，直到其中某個處理成功為止。責任鏈模式把多個處理器串成鏈，然後讓請求在鏈上傳遞：
2.3 責任鏈模式使用
責任鏈模式怎麼使用呢？
-
一個介面或者抽象類
-
每個物件差異化處理
-
物件鏈（陣列）初始化（連起來）
2.3.1 一個介面或者抽象類
這個介面或者抽象類，需要：
-
有一個指向責任下一個物件的屬性
-
一個設定下一個物件的set方法
-
給子類物件差異化實現的方法（如以下程式碼的doFilter方法）
/**
*
*/
public abstract class AbstractHandler {
//責任鏈中的下一個物件
private AbstractHandler nextHandler;
/**
* 責任鏈的下一個物件
*/
public void setNextHandler(AbstractHandler nextHandler){
this.nextHandler = nextHandler;
}
/**
* 具體引數攔截邏輯,給子類去實現
*/
public void filter(Request request, Response response) {
doFilter(request, response);
if (getNextHandler() != null) {
getNextHandler().filter(request, response);
}
}
public AbstractHandler getNextHandler() {
return nextHandler;
}
abstract void doFilter(Request filterRequest, Response response);
}
2.3.2 每個物件差異化處理
責任鏈上，每個物件的差異化處理，如本小節的相親原始碼業務場景，就有引數校驗物件、安全校驗物件、黑名單校驗物件、規則攔截物件
/**
* 引數校驗物件
**/
@Component
@Order(1) //順序排第1，最先校驗
public class CheckParamFilterObject extends AbstractHandler {
@Override
public void doFilter(Request request, Response response) {
System.out.println("非空引數檢查");
}
}
/**
* 安全校驗物件
*/
@Component
@Order(2) //校驗順序排第2
public class CheckSecurityFilterObject extends AbstractHandler {
@Override
public void doFilter(Request request, Response response) {
//invoke Security check
System.out.println("安全呼叫校驗");
}
}
/**
* 黑名單校驗物件
*/
@Component
@Order(3) //校驗順序排第3
public class CheckBlackFilterObject extends AbstractHandler {
@Override
public void doFilter(Request request, Response response) {
//invoke black list check
System.out.println("校驗黑名單");
}
}
/**
* 規則攔截物件
*/
@Component
@Order(4) //校驗順序排第4
public class CheckRuleFilterObject extends AbstractHandler {
@Override
public void doFilter(Request request, Response response) {
//check rule
System.out.println("check rule");
}
}
2.3.3 物件鏈連起來（初始化）&& 使用
@Component("ChainPatternDemo")
public class ChainPatternDemo {
//自動注入各個責任鏈的物件
@Autowired
private List<AbstractHandler> abstractHandleList;
private AbstractHandler abstractHandler;
//spring注入後自動執行，責任鏈的物件連線起來
@PostConstruct
public void initializeChainFilter(){
for(int i = 0;i<abstractHandleList.size();i++){
if(i == 0){
abstractHandler = abstractHandleList.get(0);
}else{
AbstractHandler currentHander = abstractHandleList.get(i - 1);
AbstractHandler nextHander = abstractHandleList.get(i);
currentHander.setNextHandler(nextHander);
}
}
}
//直接呼叫這個方法使用
public Response exec(Request request, Response response) {
abstractHandler.filter(request, response);
return response;
}
public AbstractHandler getAbstractHandler() {
return abstractHandler;
}
public void setAbstractHandler(AbstractHandler abstractHandler) {
this.abstractHandler = abstractHandler;
}
}
執行結果如下：
非空引數檢查
安全呼叫校驗
校驗黑名單
check rule
3. 模板方法模式
3.1 業務場景
假設相親原始碼中有這麼一個業務場景：內部系統不同商戶，呼叫我們系統介面，去跟外部第三方系統互動（http方式）。走類似這麼一個流程，如下：
一個請求都會經歷這幾個流程：
-
查詢商戶資訊
-
對請求報文加簽
-
傳送http請求出去
-
對返回的報文驗籤
這裡，有的商戶可能是走代理出去的，有的是走直連。假設當前有A，B商戶接入，不少夥伴可能這麼實現，虛擬碼如下：
// 商戶A處理控制程式碼
CompanyAHandler implements RequestHandler {
Resp hander(req){
//查詢商戶資訊
queryMerchantInfo();
//加簽
signature();
//http請求（A商戶假設走的是代理）
httpRequestbyProxy()
//驗籤
verify();
}
}
// 商戶B處理控制程式碼
CompanyBHandler implements RequestHandler {
Resp hander(Rreq){
//查詢商戶資訊
queryMerchantInfo();
//加簽
signature();
// http請求（B商戶不走代理，直連）
httpRequestbyDirect();
// 驗籤
verify();
}
}
假設新加一個C商戶接入，你需要再實現一套這樣的程式碼。顯然，這樣程式碼就重複了，一些通用的方法，卻在每一個子類都重新寫了這一方法。
如何優化呢？可以使用模板方法模式。
3.2 模板方法模式定義
定義一個操作中的演算法的骨架流程，而將一些步驟延遲到子類中，使得子類可以不改變一個演算法的結構即可重定義該演算法的某些特定步驟。它的核心思想就是：定義一個操作的一系列步驟，對於相親原始碼中某些暫時確定不下來的步驟，就留給子類去實現，這樣不同的子類就可以定義出不同的步驟。
3.3 模板方法使用
-
一個抽象類，定義骨架流程（抽象方法放一起）
-
確定的共同方法步驟，放到抽象類（去除抽象方法標記）
-
不確定的步驟，給子類去差異化實現
3.3.1 一個抽象類，定義骨架流程
因為一個個請求經過的流程為一下步驟：
-
查詢商戶資訊
-
對請求報文加簽
-
傳送http請求出去
-
對返回的報文驗籤
所以我們就可以定義一個抽象類，包含請求流程的幾個方法，方法首先都定義為抽象方法哈：
/**
* 抽象類定義骨架流程（查詢商戶資訊，加簽，http請求，驗籤）
*/
abstract class AbstractMerchantService {
//查詢商戶資訊
abstract queryMerchantInfo();
//加簽
abstract signature();
//http 請求
abstract httpRequest();
// 驗籤
abstract verifySinature();
}
3.3.2 確定的共同方法步驟，放到抽象類
abstract class AbstractMerchantService {
//模板方法流程
Resp handlerTempPlate(req){
//查詢商戶資訊
queryMerchantInfo();
//加簽
signature();
//http 請求
httpRequest();
// 驗籤
verifySinature();
}
// Http是否走代理（提供給子類實現）
abstract boolean isRequestByProxy();
}
3.3.3 不確定的步驟，給子類去差異化實現
因為相親原始碼是否走代理流程是不確定的，所以給子類去實現。
商戶A的請求實現：
CompanyAServiceImpl extends AbstractMerchantService{
Resp hander(req){
return handlerTempPlate(req);
}
//走http代理的
boolean isRequestByProxy(){
return true;
}
商戶B的請求實現：
CompanyBServiceImpl extends AbstractMerchantService{
Resp hander(req){
return handlerTempPlate(req);
}
//公司B是不走代理的
boolean isRequestByProxy(){
return false;
}
4. 觀察者模式
4.1 業務場景
登陸註冊應該是相親原始碼最常見的業務場景了。就拿註冊來說事，我們經常會遇到類似的場景，就是使用者註冊成功後，我們給使用者發一條訊息，又或者發個郵件等等，因此經常有如下的程式碼：
void register(User user){
insertRegisterUser（user）;
sendIMMessage();
sendEmail()；
}
這塊程式碼會有什麼問題呢？ 如果相親原始碼又加需求：現在註冊成功的使用者，再給使用者發一條簡訊通知。於是你又得改register方法的程式碼了。。。這是不是違反了開閉原則啦。
void register(User user){
insertRegisterUser（user）;
sendIMMessage();
sendMobileMessage（）;
sendEmail()；
}
並且，如果調發簡訊的介面失敗了，是不是又影響到使用者註冊了？！這時候，是不是得加個非同步方法給通知訊息才好。。。
實際上，我們可以使用觀察者模式優化。
4.2 觀察者模式定義
觀察者模式定義物件間的一種一對多的依賴關係，當相親原始碼一個物件的狀態發生改變時，所有依賴於它的物件都得到通知並被完成業務的更新。
觀察者模式屬於行為模式，一個物件（被觀察者）的狀態發生改變，所有的依賴物件（觀察者物件）都將得到通知，進行廣播通知。它的主要成員就是觀察者和被觀察者。
-
被觀察者（Observerable）：目標物件，狀態發生變化時，將通知所有的觀察者。
-
觀察者（observer）：接受被觀察者的狀態變化通知，執行預先定義的業務。
使用場景： 相親原始碼完成某件事情後，非同步通知場景。如，登陸成功，發個IM訊息等等。
4.3 觀察者模式使用
觀察者模式實現的話，還是比較簡單的。
-
一個被觀察者的類Observerable ;
-
多個觀察者Observer ；
-
觀察者的差異化實現
-
經典觀察者模式封裝：EventBus實戰
4.3.1 一個被觀察者的類Observerable 和 多個觀察者Observer
public class Observerable {
private List<Observer> observers
= new ArrayList<Observer>();
private int state;
public int getState() {
return state;
}
public void setState(int state) {
notifyAllObservers();
}
//新增觀察者
public void addServer(Observer observer){
observers.add(observer);
}
//移除觀察者
public void removeServer(Observer observer){
observers.remove(observer);
}
//通知
public void notifyAllObservers(int state){
if(state!=1){
System.out.println(“不是通知的狀態”);
return ;
}
for (Observer observer : observers) {
observer.doEvent();
}
}
}
4.3.2 觀察者的差異化實現
//觀察者
interface Observer {
void doEvent();
}
//Im訊息
IMMessageObserver implements Observer{
void doEvent（）{
System.out.println("傳送IM訊息");
}
}
//手機簡訊
MobileNoObserver implements Observer{
void doEvent（）{
System.out.println("傳送簡訊訊息");
}
}
//EmailNo
EmailObserver implements Observer{
void doEvent（）{
System.out.println("傳送email訊息");
}
}
4.3.3 EventBus實戰
自己搞一套觀察者模式的程式碼，還是有點小麻煩。實際上，Guava EventBus 就封裝好了，它 提供一套基於註解的事件匯流排，api可以靈活的使用，爽歪歪。
我們來看下EventBus的實戰程式碼哈，首先可以宣告一個EventBusCenter類，它類似於以上被觀察者那種角色Observerable。
public class EventBusCenter {
private static EventBus eventBus = new EventBus();
private EventBusCenter() {
}
public static EventBus getInstance() {
return eventBus;
}
//新增觀察者
public static void register(Object obj) {
eventBus.register(obj);
}
//移除觀察者
public static void unregister(Object obj) {
eventBus.unregister(obj);
}
//把訊息推給觀察者
public static void post(Object obj) {
eventBus.post(obj);
}
}
然後再宣告觀察者EventListener
public class EventListener {
@Subscribe //加了訂閱，這裡標記這個方法是事件處理方法
public void handle(NotifyEvent notifyEvent) {
System.out.println("傳送IM訊息" + notifyEvent.getImNo());
System.out.println("傳送簡訊訊息" + notifyEvent.getMobileNo());
System.out.println("傳送Email訊息" + notifyEvent.getEmailNo());
}
}
//通知事件類
public class NotifyEvent {
private String mobileNo;
private String emailNo;
private String imNo;
public NotifyEvent(String mobileNo, String emailNo, String imNo) {
this.mobileNo = mobileNo;
this.emailNo = emailNo;
this.imNo = imNo;
}
}
使用demo測試：
public class EventBusDemoTest {
public static void main(String[] args) {
EventListener eventListener = new EventListener();
EventBusCenter.register(eventListener);
EventBusCenter.post(new NotifyEvent("13372817283", "123@qq.com", "666"));
}
}
5. 工廠模式
5.1 業務場景
工廠模式一般配合策略模式一起使用。用來去優化相親原始碼中大量的if…else…或switch…case…條件語句。
我們就取第一小節中策略模式那個例子吧。根據不同的檔案解析型別，建立不同的解析物件
IFileStrategy getFileStrategy(FileTypeResolveEnum fileType){
IFileStrategy fileStrategy ;
if(fileType=FileTypeResolveEnum.File_A_RESOLVE){
fileStrategy = new AFileResolve();
}else if(fileType=FileTypeResolveEnum.File_A_RESOLV){
fileStrategy = new BFileResolve();
}else{
fileStrategy = new DefaultFileResolve();
}
return fileStrategy;
}
其實這就是工廠模式，定義一個建立物件的介面，讓其子類自己決定例項化哪一個工廠類，工廠模式使其建立過程延遲到子類進行。
策略模式的例子，沒有使用上一段程式碼，而是藉助spring的特性，搞了一個工廠模式，哈哈，小夥伴們可以回去那個例子細品一下，我把程式碼再搬下來，小夥伴們再品一下吧：
/**
* @author
*/
@Component
public class StrategyUseService implements ApplicationContextAware{
private Map<FileTypeResolveEnum, IFileStrategy> iFileStrategyMap = new ConcurrentHashMap<>();
//把所有的檔案型別解析的物件，放到map，需要使用時，信手拈來即可。這就是工廠模式的一種體現啦
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
Map<String, IFileStrategy> tmepMap = applicationContext.getBeansOfType(IFileStrategy.class);
tmepMap.values().forEach(strategyService -> iFileStrategyMap.put(strategyService.gainFileType(), strategyService));
}
}
5.2 使用工廠模式
定義工廠模式也是比較簡單的:
-
一個工廠介面，提供一個建立不同物件的方法。
-
其子類實現工廠介面，構造不同物件
-
使用工廠模式
5.3.1 一個工廠介面
interface IFileResolveFactory{
void resolve();
}
5.3.2 不同子類實現工廠介面
class AFileResolve implements IFileResolveFactory{
void resolve(){
System.out.println("檔案A型別解析");
}
}
class BFileResolve implements IFileResolveFactory{
void resolve(){
System.out.println("檔案B型別解析");
}
}
class DefaultFileResolve implements IFileResolveFactory{
void resolve(){
System.out.println("預設檔案型別解析");
}
}
5.3.3 使用工廠模式
//構造不同的工廠物件
IFileResolveFactory fileResolveFactory;
if(fileType=“A”){
fileResolveFactory = new AFileResolve();
}else if(fileType=“B”){
fileResolveFactory = new BFileResolve();
}else{
fileResolveFactory = new DefaultFileResolve();
}
fileResolveFactory.resolve();
一般情況下，對於工廠模式，你不會看到以上的程式碼。工廠模式會跟配合其他設計模式如策略模式一起出現的。
6. 單例模式
6.1 業務場景
單例模式，保證一個類僅有一個例項，並提供一個訪問它的全域性訪問點。相親原始碼 I/O與資料庫的連線,一般就用單例模式實現de的。Windows裡面的Task Manager（工作管理員）也是很典型的單例模式。
來看一個單例模式的例子
/**
*
*/
public class LanHanSingleton {
private static LanHanSingleton instance;
private LanHanSingleton(){
}
public static LanHanSingleton getInstance(){
if (instance == null) {
instance = new LanHanSingleton();
}
return instance;
}
}
以上的例子，就是懶漢式的單例實現。例項在需要用到的時候，才去建立，就比較懶。如果有則返回，沒有則新建，需要加下 synchronized 關鍵字，要不然可能存線上性安全問題。
6.2 單例模式的經典寫法
其實單例模式還有有好幾種實現方式，如餓漢模式，雙重校驗鎖，靜態內部類，列舉等實現方式。
6.2.1 餓漢模式
public class EHanSingleton {
private static EHanSingleton instance = new EHanSingleton();
private EHanSingleton(){
}
public static EHanSingleton getInstance() {
return instance;
}
}
餓漢模式，它比較飢餓、比較勤奮，例項在相親原始碼初始化的時候就已經建好了，不管你後面有沒有用到，都先新建好例項再說。這個就沒有執行緒安全的問題，但是呢，浪費記憶體空間呀。
6.2.2 雙重校驗鎖
public class DoubleCheckSingleton {
private static DoubleCheckSingleton instance;
private DoubleCheckSingleton() { }
public static DoubleCheckSingleton getInstance(){
if (instance == null) {
synchronized (DoubleCheckSingleton.class) {
if (instance == null) {
instance = new DoubleCheckSingleton();
}
}
}
return instance;
}
}
雙重校驗鎖實現的單例模式，綜合了懶漢式和餓漢式兩者的優缺點。以上程式碼例子中，在synchronized關鍵字內外都加了一層 if 條件判斷，這樣既保證了執行緒安全，又比直接上鎖提高了執行效率，還節省了記憶體空間。
6.2.3 靜態內部類
public class InnerClassSingleton {
private static class InnerClassSingletonHolder{
private static final InnerClassSingleton INSTANCE = new InnerClassSingleton();
}
private InnerClassSingleton(){}
public static final InnerClassSingleton getInstance(){
return InnerClassSingletonHolder.INSTANCE;
}
}
相親原始碼靜態內部類的實現方式，效果有點類似雙重校驗鎖。但這種方式只適用於靜態域場景，雙重校驗鎖方式可在例項域需要延遲初始化時使用。
6.2.4 列舉
public enum SingletonEnum {
INSTANCE;
public SingletonEnum getInstance(){
return INSTANCE;
}
}
列舉實現的單例，相親原始碼簡潔清晰。並且它還自動支援序列化機制，絕對防止多次例項化。
本文轉載自網路，轉載僅為分享乾貨知識，如有侵權歡迎聯絡雲豹科技進行刪除處理
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69996194/viewspace-2839527/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 相親交友原始碼前端效能優化，通常使用哪些手段？原始碼前端優化
- 婚戀app原始碼開發，相親直播間聊天訊息列表卡頓優化APP原始碼優化
- 相親交友原始碼實現相親直播間，移動終端的優化方案原始碼優化
- 相親交友原始碼開發，前端如何實現水印功能？原始碼前端
- 相親交友原始碼開發，前端API如何請求快取？原始碼前端API快取
- 「譯」使用策略設計模式來簡化程式碼設計模式
- Spring用了哪些設計模式Spring設計模式
- 相親交友原始碼開發中，Redis的三種限流方式原始碼Redis
- 如何優雅的在業務中使用設計模式（程式碼如詩）設計模式
- 程式設計師相親程式設計師
- 如何實現相親交友原始碼的CPU效能優化？解決方案梳理原始碼優化
- 相親交友原始碼中，音訊AAC解碼的實現程式碼原始碼音訊
- 相親原始碼開發，從程式碼級別減少資料請求次數的實現原始碼
- 相親原始碼的效能為何這麼重要，該怎樣實現優化？原始碼優化
- 相親交友原始碼實現程式內快取，提升高併發能力！原始碼快取
- 相親原始碼前端開發知識點，每天進步一點點原始碼前端
- 程式設計師在直播app原始碼的開發過程中都有哪些技巧？程式設計師APP原始碼
- 模板化的封裝，降低業務程式碼開發封裝
- 低程式碼開發平臺有哪些優點
- 相親交友原始碼開發中會用到的幾種日期處理方法原始碼
- 程式設計師相親圖鑑程式設計師
- 某程式設計師去相親程式設計師
- 併發程式設計之 鎖的優化有哪些程式設計優化
- 併發程式設計—— FutureTask 原始碼分析程式設計原始碼
- Android原始碼設計模式-模板模式Android原始碼設計模式
- 編寫相親交友原始碼，註釋方面應該重視哪些問題？原始碼
- 低程式碼比傳統開發有哪些優勢
- 相親交友原始碼開發，演算法的定義及複雜度分析原始碼演算法複雜度
- iOS開發 面向切面程式設計之 Aspects 原始碼解析iOS程式設計原始碼
- 哪些業務場景需要做程式碼審計?程式碼審計很重要嗎？
- 業務程式碼程式設計陷阱案例 - jaxenter程式設計
- 軟體教練說：效能優化與效能設計，“相親相愛”的一對優化
- 直播原始碼和短視訊原始碼，相親相愛的一家人原始碼
- 優秀網站原始碼、程式設計原始碼下載網站大集中網站原始碼程式設計
- 趣文：程式設計師相親指南程式設計師
- C 語言高效程式設計與程式碼優化程式設計優化
- 量化合約開發丨量化合約原始碼丨JAVA系統開發程式設計程式碼示例原始碼Java程式設計
- 程式模組化設計結構化開發優勢