尚硅谷Java設計模式
設計模式目的
編寫軟件過程中，程序員面臨著來自耦合性，內聚性以及可維護性，可擴展性，重用性，靈活性等多方面的挑戰
設計模式是為了讓程序（軟件），具有更好的
1）可復用性（即：相同功能的代碼，不用多次編寫，也叫做代碼重用性）
2）可讀性（即：編程規范性，便于其他程序員的閱讀和理解）
3）可擴展性（即：當需要增加新的功能時，非常的方便，也叫做可維護性）
4）可靠性（即：當我們增加新的功能后，對原來的功能沒有影響）
5）使程序呈現高內聚，低耦合的特性
設計模式七大原則
設計模式原則，其實就是程序員在編程時，應當遵守的原則，也是各種設計模式的基礎（即：設計模式為什么這樣設計的依據）設計模式
常用的七大原則有：
1）單一職責原則
2）接口隔離原則
3）依賴倒轉原則
4）里氏替換原則
5）開閉原則
6）迪米特法則
7）合成復用原則
單一職責原則
對類來說的，即一個類應該只負責一項職責。如類A負責兩個不同職責：職責1，職責2。當職責1需求變更而改變A時，可能造成職責2執行錯誤，所以需要將類A的粒度分解為A1，A2
方案1
public class SingleResponsibility1 {
public static void main(String[] args) {
Vehicle vehicle = new Vehicle();
vehicle.run("汽車");
vehicle.run("輪船");
vehicle.run("飛機");
}
}
/**
* 方式1的分析
* 1.在方式1的run方法中，違反了單一職責原則
* 2.解決的方案非常的簡單，根據交通工具運行方法不同，分解成不同類即可
*/
class Vehicle{
public void run(String type){
if ("汽車".equals(type)) {
System.out.println(type + "在公路上運行...");
} else if ("輪船".equals(type)) {
System.out.println(type + "在水面上運行...");
} else if ("飛機".equals(type)) {
System.out.println(type + "在天空上運行...");
}
}
}
方案2
public class SingleResponsibility2 {
public static void main(String[] args) {
RoadVehicle roadVehicle = new RoadVehicle();
roadVehicle.run("汽車");
WaterVehicle waterVehicle = new WaterVehicle();
waterVehicle.run("輪船");
AirVehicle airVehicle = new AirVehicle();
airVehicle.run("飛機");
}
}
/**
* 方案2的分析
* 1.遵守單一職責原則
* 2.但是這樣做的改動很大，即將類分解，同時修改客戶端
* 3.改進：直接修改Vehicle類，改動的代碼會比較少=>方案3
*/
class RoadVehicle{
public void run(String type){
System.out.println(type + "在公路上運行...");
}
}
class WaterVehicle{
public void run(String type){
System.out.println(type + "在水面上運行...");
}
}
class AirVehicle{
public void run(String type){
System.out.println(type + "在天空上運行...");
}
}
方案三
public class SingleResponsibility3 {
public static void main(String[] args) {
Vehicle2 vehicle = new Vehicle2();
vehicle.run("汽車");
vehicle.runWater("輪船");
vehicle.runAir("飛機");
}
}
/**
* 方式3的分析
* 1.這種修改方法沒有對原來的類做大的修改，只是增加方法
* 2.這里雖然沒有在類這個級別上遵守單一職責原則，但是在方法級別上，仍然是遵守單一職責
*/
class Vehicle2{
public void run(String type){
System.out.println(type + "在公路上運行...");
}
public void runWater(String type){
System.out.println(type + "在水面上運行...");
}
public void runAir(String type){
System.out.println(type + "在天空上運行...");
}
}
總結
類分解，可能成本較高
解決方案：不在類級別上“單一職責”，往下沉，在方法級別上“單一職責”
注意事項和細節
1）降低類的復雜度，一個類只負責一項職責
2）提高類的可讀性，可維護性
3）降低變更引起的風險
4）通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在代碼級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則
接口隔離原則
1）客戶端（main類）不應該依賴它不需要的接口，即一個類對另一個類的依賴應該建立在最小的接口上
3）類 A 通過接口 Interface1 依賴類 B，類 C 通過接口 Interface1 依賴類 D，如果接口 Interface1 對于類 A 和類 C 來說不是最小接口，那么類 B 和類 D 必須去實現他們不需要的方法
4）按隔離原則應當這樣處理：將接口 Interface1 拆分為獨立的幾個接口，類 A 和類 C 分別與他們需要的接口建立依賴關系。也就是采用接口隔離原則
問題與改進
1）類 A 通過接口 Interface1 依賴類 B，類 C 通過接口 Interface1 依賴類 D，如果接口 Interface1 對于類 A 和類 C 來說不是最小接口，那么類 B 和類 D 必須去實現他們不需要的方法
2）將接口 Interface1 拆分為獨立的幾個接口，類 A 和類 C 分別與他們需要的接口建立依賴關系。也就是采用接口隔離原則
3）接口 Interface1 中出現的方法，根據實際情況拆分為三個接口
4）代碼實現
interface Interface1 {
void operation1();
}
interface Interface2 {
void operation2();
void operation3();
}
interface Interface3 {
void operation4();
void operation5();
}
class B implements Interface1, Interface2 {
@Override
public void operation1() {
System.out.println("B 實現了 operation1");
}
@Override
public void operation2() {
System.out.println("B 實現了 operation2");
}
@Override
public void operation3() {
System.out.println("B 實現了 operation3");
}
}
class D implements Interface1, Interface3 {
@Override
public void operation1() {
System.out.println("D 實現了 operation1");
}
@Override
public void operation4() {
System.out.println("D 實現了 operation4");
}
@Override
public void operation5() {
System.out.println("D 實現了 operation5");
}
}
/**
* A類通過接口Interface1,Interface2依賴（使用）B類，但是只會用到1，2，3方法
*/
class A {
public void depend1(Interface1 i) {
i.operation1();
}
public void depend2(Interface2 i) {
i.operation2();
}
public void depend3(Interface2 i) {
i.operation3();
}
}
/**
* C類通過接口Interface1,Interface3依賴（使用）D類，但是只會用到1，4，5方法
*/
class C {
public void depend1(Interface1 i) {
i.operation1();
}
public void depend4(Interface3 i) {
i.operation4();
}
public void depend5(Interface3 i) {
i.operation5();
}
依賴倒轉原則
基本介紹
1）高層模塊（業務模塊）不應該依賴低層模塊（具體實現模塊），二者都應該依賴其抽象
2）抽象不應該依賴細節，細節應該依賴抽象
3）依賴倒轉（倒置）的中心思想是面向接口編程
4）依賴倒轉原則是基于這樣的設計理念：相對于細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多。在java中，抽象指的是接口或抽象類，細節就是具體的實現類
5）使用接口或抽象類的目的是制定好規范，而不涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成
依賴關系傳遞的三種方式
1）接口傳遞
//方式1：通過接口傳遞實現依賴
//開關的接口
interface IOpenAndClose {
void open(ITV tv);//抽象方法，接收接口
}
//ITV接口
interface ITV {
void play();
}
//實現接口
class OpenAndClose implements IOpenAndClose {
public void open(ITV tv){
tv.play();
}
}
2）構造方法傳遞
//方式2：通過構造函數實現依賴
//開關的接口
interface IOpenAndClose {
void open();//抽象方法
}
//ITV接口
interface ITV {
public void play();
}
//實現接口
class OpenAndClose implements IOpenAndClose {
private ITV tv; // 成員
public OpenAndClose(ITV tv){ // 構造器
this.tv = tv;
}
public void open(){
this.tv.play();
}
}
3）setter 方式傳遞
//方式3，通過setter方法傳遞
interface IOpenAndClose{
void open();//抽象方法
void setTv(ITV tv);
}
//ITV接口
interface ITV{
void play();
}
//實現接口
class OpenAndClose implements IOpenAndClose{
private ITV tv;
public void setTv(ITV tv){
this.tv=tv;
}
public void open(){
this.tv.play();
}
}
注意事項和細節
1）低層模塊盡量都要有抽象類或接口，或者兩者都有，程序穩定性更好
2）變量的聲明類型盡量是抽象類或接口，這樣我們的變量引用和實際對象間，就存在一個緩沖層，利于程序擴展和優化
3）繼承時遵循里氏替換原則
上面的案例有點難理解，再補充以下案例
傳統方式，低層模塊和高層模塊直接相互依賴
// 低層模塊
class LightBulb {
public void turnOn() {
System.out.println("LightBulb: 燈打開了...");
}
public void turnOff() {
System.out.println("LightBulb: 燈關閉了...");
}
}
// 高層模塊直接依賴低層模塊
class ElectricPowerSwitch {
private LightBulb bulb;
private boolean on;
public ElectricPowerSwitch(LightBulb bulb) {
this.bulb = bulb;
this.on = false;
}
public void press() {
if (on) {
bulb.turnOff();
on = false;
} else {
bulb.turnOn();
on = true;
}
}
}
// 使用
public class Main {
public static void main(String[] args) {
LightBulb bulb = new LightBulb();
ElectricPowerSwitch switch = new ElectricPowerSwitch(bulb);
switch.press(); // 開燈
switch.press(); // 關燈
}
}
使用依賴反轉，低層模塊和高層模塊通過接口
// 1. 定義抽象接口
interface Switchable {
void turnOn();
void turnOff();
}
// 2. 低層模塊實現接口
class LightBulb implements Switchable {
@Override
public void turnOn() {
System.out.println("LightBulb: 燈打開了...");
}
@Override
public void turnOff() {
System.out.println("LightBulb: 燈關閉了...");
}
}
// 另一個低層模塊也實現同一接口
class Fan implements Switchable {
@Override
public void turnOn() {
System.out.println("Fan: 風扇打開了...");
}
@Override
public void turnOff() {
System.out.println("Fan: 風扇關閉了...");
}
}
// 3. 高層模塊依賴抽象接口
class ElectricPowerSwitch {
private Switchable device;
private boolean on;
public ElectricPowerSwitch(Switchable device) {
this.device = device;
this.on = false;
}
public void press() {
if (on) {
device.turnOff();
on = false;
} else {
device.turnOn();
on = true;
}
}
}
// 4. 使用
public class Main {
public static void main(String[] args) {
// 使用燈泡
Switchable bulb = new LightBulb();
ElectricPowerSwitch lightSwitch = new ElectricPowerSwitch(bulb);
lightSwitch.press(); // 開燈
lightSwitch.press(); // 關燈
// 使用風扇
Switchable fan = new Fan();
ElectricPowerSwitch fanSwitch = new ElectricPowerSwitch(fan);
fanSwitch.press(); // 開風扇
fanSwitch.press(); // 關風扇
}
}
- 定義抽象接口：先定義高層模塊需要的抽象接口
- 具體實現接口：低層模塊實現這些接口
- 依賴注入：高層模塊通過構造函數或方法參數接收抽象接口的實例
- 松耦合：高層模塊不直接依賴具體實現，只依賴抽象
這種設計使得系統更加靈活，易于擴展和維護。當需要添加新的通知方式時，只需創建新的實現類而不需要修改現有代碼
里氏替換原則
繼承性的思考和說明
1）繼承包含這樣一層含義：父類中凡是已經實現好的方法，實際上是在設定規范和契約，雖然它不強制要求所有的子類必須遵循這些契約，但是如果子類對這些已經實現的方法任意修改，就會對整個繼承體系造成破壞
2）繼承在給程序設計帶來便利的同時，也帶來了弊端。比如使用繼承會給程序帶來侵入性，程序的可移植性降低，增加對象間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，并且父類修改后，所有涉及到子類的功能都有可能產生故障
3）問題提出：在編程中，如何正確使用繼承？=>里氏替換原則
里氏替換原則告訴我們，繼承實際上讓兩個類耦合性增強了，在適當的情況下，可以通過聚合、組合、依賴來解決問題
public void test() {
A a = new A();
System.out.println("11-3=" + a.func1(11, 3));
System.out.println("1-8=" + a.func1(1, 8));
System.out.println("---------------------");
B b = new B();
System.out.println("11-3=" + b.func1(11, 3));
System.out.println("1-8=" + b.func1(1, 8));
System.out.println("11+3+9=" + b.func2(11, 3));
}
class A {
//返回兩個數的差
public int func1(int num1, int num2) {
return num1 - num2;
}
}
class B extends A {
@Override
public int func1(int num1, int num2) {
return num1 + num2;
}
//增加了一個新功能：完成兩個數相加，然后和9求和
public int func2(int num1, int num2) {
return func1(num1, num2) + 9;
}
}
解決方法
1）我們發現原來運行正常的相減功能發生了錯誤。原因就是類 B 無意中重寫了父類的方法，造成原有功能出現錯誤。在實際編程中，我們常常會通過重寫父類的方法完成新的功能，這樣寫起來雖然簡單，但整個繼承體系的復用性會比較差。特別是運行多態比較頻繁的時候
2）通用的做法是：原來的父類和子類都繼承一個更通俗的基類，原有的繼承關系去掉，采用依賴、聚合、組合等關系代替
//創建一個更加基礎的基類
class Base {
//將更基礎的成員和方法寫到Base類中
}
class A extends Base {
//返回兩個數的差
public int func1(int num1, int num2) {
return num1 - num2;
}
}
class B extends Base {
//如果B需要使用A類的方法，使用組合關系
private A a;
public int func1(int num1, int num2) {
return num1 + num2;
}
//增加了一個新功能：完成兩個數相加，然后和9求和
public int func2(int num1, int num2) {
return func1(num1, num2) + 9;
}
public int func3(int num1, int num2) {
return this.a.func1(num1, num2);
}
}
開閉原則
1）開閉原則是編程中最基礎、最重要的設計原則
2）一個軟件實體如類、模塊和函數應該對擴展開放（對提供者而言），對修改關閉（對使用者而言）。用抽象構建框架，用實現擴展細節
3）當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化
4）編程中遵循其它原則，以及使用設計模式的目的就是遵循開閉原則
class GraphicEditor {
public void drawShape(Shape s) {
if (s.m_type == 1) {
drawRectangle(s);
} else if (s.m_type == 2) {
drawCircle(s);
} else if (s.m_type == 3) {
drawTriangle(s);
}
}
public void drawRectangle(Shape r) {
System.out.println("矩形");
}
public void drawCircle(Shape r) {
System.out.println("圓形");
}
public void drawTriangle(Shape r) {
System.out.println("三角形");
}
}
class Shape {
public int m_type;
}
class RectangleShape extends Shape {
RectangleShape() {
m_type = 1;
}
}
class CircleShape extends Shape {
CircleShape() {
m_type = 2;
}
}
class TriangleShape extends Shape {
TriangleShape() {
m_type = 3;
}
}
方式 1 的優缺點
1）優點是比較好理解，簡單易操作
2）缺點是違反了設計模式的 OCP 原則，即對擴展開放（提供方），對修改關閉（使用方）。即當我們給類增加新功能的時喉，盡量不修改代碼，或者盡可能少修改代碼
3）比如我們這時要新增加一個圖形種類，我們需要做如下修改，修改的地方較多4）代碼演示
方式 1 的改進的思路分析
把創建 Shape 類做成抽象類，并提供一個抽象的 draw 方法，讓子類去實現即可
這樣我們有新的圖形種類時，只需要讓新的圖形類繼承 Shape，并實現 draw 方法即可
使用方的代碼就不需要修改，滿足了開閉原則
方式 2 來解決
1）方式 2 的設計方案：定義一個 Shape 抽象類
2）看代碼示例
class GraphicEditor {
public void drawShape(Shape s) {
s.draw();
}
}
abstract class Shape {
int m_type;
public abstract void draw();
}
class RectangleShape extends Shape {
RectangleShape() {
m_type = 1;
}
@Override
public void draw() {
System.out.println("矩形");
}
}
class CircleShape extends Shape {
CircleShape() {
m_type = 2;
}
@Override
public void draw() {
System.out.println("圓形");
}
}
class TriangleShape extends Shape {
TriangleShape() {
m_type = 3;
}
@Override
public void draw() {
System.out.println("三角形");
}
}
迪米特法則
1）一個對象應該對其他對象保持最少的了解
2）類與類關系越密切，耦合度越大
3）迪米特法則又叫最少知道原則，即一個類對自己依賴的類知道的越少越好。也就是說，對于被依賴的類不管多么復雜，都盡量將邏輯封裝在類的內部。對外除了提供的 public 方法，不對外泄露任何信息
4）迪米特法則還有個更簡單的定義：只與直接的朋友通信
5）直接的朋友：每個對象都會與其他對象有耦合關系，只要兩個對象之間有耦合關系，我們就說這兩個對象之間是朋友關系。耦合的方式很多：依賴、關聯、組合、聚合等。其中，我們稱出現成員變量，方法參數，方法返回值中的類為直接的朋友，而出現在局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變量的形式出現在類的內部
//總部員工
class Employee {
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//學院員工
class CollegeEmployee {
private String id;
public String getId() {
return id;
}
public void setId(String id) {
this.id = id;
}
}
//學院員工管理 類
class CollegeManager {
public List<CollegeEmployee> getAllEmployee() {
List<CollegeEmployee> list = new ArrayList<>();
CollegeEmployee collegeEmployee;
for (int i = 0; i < 10; i++) {
collegeEmployee = new CollegeEmployee();
collegeEmployee.setId("學院員工id=" + i);
list.add(collegeEmployee);
}
return list;
}
}
//總部員工管理類
class SchoolManager {
public List<Employee> getAllEmployee() {
List<Employee> list = new ArrayList<>();
Employee employee;
for (int i = 0; i < 5; i++) {
employee = new Employee();
employee.setId("總部員工id=" + i);
list.add(employee);
}
return list;
}
public void printAllEmployee(CollegeManager sub) {
System.out.println("--------------學院員工--------------");
List<CollegeEmployee> list1 = sub.getAllEmployee();
for (CollegeEmployee collegeEmployee : list1) {
System.out.println(collegeEmployee.getId());
}
System.out.println("---------------總部員工-------------");
List<Employee> list2 = this.getAllEmployee();
for (Employee employee : list2) {
System.out.println(employee.getId());
}
}
}
應用實例改進
1）前面設計的問題在于 SchoolManager 中，CollegeEmployee 類并不是 SchoolManager 類的直接朋友（分析）
2）按照迪米特法則，應該避免類中出現這樣非直接朋友關系的耦合
3）對代碼按照迪米特法則進行改進（看老師演示）
注意事項和細節
1）迪米特法則的核心是降低類之間的耦合
2）但是注意：由于每個類都減少了不必要的依賴，因此迪米特法則只是要求降低類間（對象間）耦合關系，并不是要求完全沒有依賴關系
合成復用原則
原則是盡量使用合成/聚合的方式，而不是使用繼承
設計原則核心思想
1）找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起
2）針對接口編程，而不是針對實現編程
3）為了交互對象之間的松耦合設計而努力
創建型模型
單例模式
八種方式
1）餓漢式（靜態常量）
2）餓漢式（靜態代碼塊）
3）懶漢式（線程不安全）
4）懶漢式（線程安全，同步方法）
5）懶漢式（線程安全，同步代碼塊）
6）雙重檢查
7）靜態內部類
8）枚舉
https://gitee.com/vectorx/NOTE_DesignPatterns/tree/main/創建型模式/01-單例模式
浙公網安備 33010602011771號