公司作項目,都是使用Mybatis, 我的不太喜歡xml的方式,天然也嘗試無xml的Mybatis,在以前寫的一篇多數據源+Mybatis+無xml配置.html
不廢話,本篇記錄使用JPA遇到的問題筆記.java
寫到Dao層,繼承JpaRepository,實現分頁時候的問題.spring
public interface HelloRepository extends JpaRepository<Hello,Integer>
單元測試的時候,用到了PageRequestapi
PageRequest pageRequest=newPageRequest(0,10);
這明顯是過時了,不能容忍的強迫症犯發,點進去API查看安全
發現3個構造器都@Deprecated註解,說明過期的調用方式,不推薦使用.dom
再往下看,能夠找到static的方法,是用來建造PageRequest對象的,內部調用的也是原來的構造器.函數
把原來的 new PageRequest 改爲 PageRequest.of(0,10);單元測試
有3個重載 對應 3個構造器.學習
官方API說明: since 2.0, use of(...)
instead.測試
2.0版本後,使用 of(...) 方法代替 PageRequest(...)構造器
URL : ↓↓↓
https://docs.spring.io/spring-data/commons/docs/current/api/org/springframework/data/domain/PageRequest.html
擴展學習一下API的設計思想
分析: PageRequest構造器中的參數最可能是4個參數,其中必填的是2個參數(page,rows)
另外2個參數是選填direction(正序倒序),properties(排序字段)
設計這該類的構造器的方法有幾種方案:
1.重疊構造器模式
2.JavaBeans模式
3.構建器模式
其餘.......
構建結構 : 由參數少的構造器向參數多的構造器方向調用, 最終調用參數多的構造器建立對象.
好處: 只要有必要參數,就能夠建立對象; 若是還知道了選填的控制參數,就能夠選擇性的建立可控的對象
壞處: 若是參數多了,就是一大坨,一坨接一坨,閃閃發光
public class LotShit { private Double wight; private String color; private String whoS; private boolean sweet; public LotShit(Double wight) { this(wight,"golden"); } public LotShit(Double wight, String color) { this(wight,color,"大黃"); } public LotShit(Double wight, String color,String whoS) { this(wight,color,whoS,true); } public LotShit(Double wight, String color, String whoS, boolean sweet) { this.wight = wight; this.color = color; this.whoS = whoS; this.sweet = sweet; } }
構建結構 : 遵循特定規則的java類,必須有一個無參的構造函數、屬性必須私有化private、私有化的屬性必須經過公有類型的方法(get/set)對外暴露
好處 : 建立簡單,想要什麼本身加什麼
壞處 : 構造過程能夠被set改變字段值,不能保證其安全
public class LotShit { private Double wight; private String color; private String whoS; private boolean sweet; public LotShit(){} //getter & setter ... }
構建結構 : 一個複雜對象的構建和表示分離,使得一樣的構建過程能夠創造建立不一樣的表示
好處 : 能夠靈活構造複雜對象實例,適用於多個構造器參數,且參數包含必選和可選參數
壞處 : 寫起來複雜了,構建實例成本高了
只有2個參數,仍是不要用了,若是你不是閒得慌的話
public class LotShit { private Double wight; private String color; private String whoS; private boolean sweet; private LotShit(Shit shit) { this.wight=shit.wight; this.color=shit.color; this.whoS=shit.whoS; this.sweet=shit.sweet; } public static class Shit { private Double wight; private String color; private String whoS; private boolean sweet; public LotShit create() { return new LotShit(this); } private Shit setWight(Double wight) { this.wight = wight; return this; } private Shit setColor(String color) { this.color = color; return this; } private Shit setSweet(boolean sweet) { this.sweet = sweet; return this; } private Shit setWhoS(String whoS) { this.whoS = whoS; return this; } } }
說了這麼多,彷佛PageRequest用的靜態方法代替構造器的方式和上面沒有什麼關係,哈哈哈
這裏區別於工廠方法模式中的,它只是一個靜態的方法,工廠方法模式一般有產品和工廠兩部分
這樣使用的分析一下:
1. 能夠自定義方法名字,區別多個構造器是幹什麼用的,構建的階段什麼的,明顯PageRequest.of用的都同樣,統一與構造器結構也不錯,哈哈哈
2. 能夠充分利用多態,使代碼更具備可擴展性,好比返回子類的實例,構造器則不行
3. 同樣具備重疊構造器的優勢
4. 若是該類中沒有public或protected的構造器,該類就不能使用靜態方法子類化
5.基於第4點,策略模式說到應該多用組合而不是繼承,當一個類不能子類化後,組合將是你惟一的選擇
PS: 靜態工廠方法本質上就是一個靜態方法
---------------------------------------------------------------