物件導向設計原則 – 6 大原則(一)

abstract class AbstractPoker {
    abstract fun material() : String

    abstract fun playTimes() : Int
}

class PaperPoker : AbstractPoker() {

    override fun material(): String {
        return "Paper"
    }

    override fun playTimes(): Int {
        return 50
    }

}

class PlasticPoker : AbstractPoker()  {

    override fun material(): String {
        return "Plastic"
    }

    override fun playTimes(): Int {
        return 500
    }

}

fun main() {

    // play 函數不會知道真正的實做
    fun play(poker: AbstractPoker) {
        println("${poker.material()},play times: ${poker.playTimes()}")
    }

    play(PaperPoker())
    play(PlasticPoker())

}

● 子類實現時要注意「合約」

如果 子類已經不能完整實現父類的方法，亦或曲解的父類方法的原意（或是不符合業務邏輯），這時就必須斷開父子繼承關係！改為採用依賴、聚合、組合... 等等關係取代

否則其基底就容易歪掉，之後就不容易修正

「透明替換」表示在使用子類對象時，不應該需要知道它是子類，而應該像使用父類一樣。這樣才能確保符合里氏替换原則

如果子類參數擴大，那就 符合里式原則；父類出現的地方，子類替換後 仍在父類控制範圍（這是個重點）

open class Father {
    open fun getCollection(map: HashMap<String, String>) : Collection<String> {
        println("Father work")
        return map.values
    }

}

class Child : Father() {

    // Overload
    // 子類放大接收的參數範圍
    fun getCollection(map: Map<String, String>) : Collection<String> {
        println("Child work")
        return map.values
    }

}

● 測試子類擴大參數後是否可被正常訪問？ 這裡測試兩種狀況，其實就是父類、子類呼叫同個函數，並觀察是哪個實做類被呼叫到

fun main() {

    fun test1() {
        // 實做類 Father
        val father = Father()

        father.getCollection(HashMap<String, String>().apply {
            put("A", "Apple")
        }).let {
            println(it)
        }
    }


    fun test2() {
        // 實做類 Child
        val child = Child()

        child.getCollection(HashMap<String, String>().apply {
            put("A", "Apple")
        }).let {
            println(it)
        }
    }

    test1()
    test2()

}

縮小參數 不符合里式原則；將原先父類的替換為子類，子類 Overload 函數後就可能被訪問到 (不在父類控制範圍)

open class Father2 {
    open fun getCollection(map: Map<String, String>) : Collection<String> {
        println("Father work")
        return map.values
    }

}

class Child2 : Father2() {

    // Overload
    fun getCollection(map: HashMap<String, String>) : Collection<String> {
        println("Child work")
        return map.values
    }

}

曲解了父類的規範，不符合里氏替換原則

● 測試子類縮小參數後是否可被正常訪問：這裡測試兩種狀況，其實就是父類、子類呼叫同個函數，並觀察是哪個實做類被呼叫到

fun main() {

    fun test1() {
        val father = Father2()

        father.getCollection(HashMap<String, String>().apply {
            put("A", "Apple")
        }).let {
            println(it)
        }
    }


    fun test2() {
        val child = Child2()

        child.getCollection(HashMap<String, String>().apply {
            put("A", "Apple")
        }).let {
            println(it)
        }
    }

    test1()
    test2()

}

// 父類
open class ReturnFather

// 子類
class ReturnChild: ReturnFather()

這符合里氏原則

open class Father3 {

    open fun getSample() : ReturnFather {
        return ReturnFather()
    }

}

class Child3 : Father3() {

    // 縮小返回的範圍是可以的，仍在父類的掌控範圍之內
    override fun getSample(): ReturnChild {
        return ReturnChild()
    }

}

class Computer constructor(val cpu: CPU) {

    fun showInfo() {
        println("CPU: ${cpu.getCore()}")
    }

}

class CPU {

    fun getCore() : Int {
        return 2   
    }

}

fun main() {

    Computer(CPU()).showInfo()

}

結果如下

class PowerCPU {

    fun getCore() : Int {
        return 8
    }

}

fun main() {

    Computer(PowerCPU()).showInfo()

}

// 低層模組換成依賴接口
class Computer2 constructor(val cpu: ICPUInfo) {

    fun showInfo() {
        println("CPU: ${cpu.getCore()}")
    }

}

interface ICPUInfo {
    fun getCore() : Int
}

class CPU2 : ICPUInfo {

    override fun getCore() : Int {
        return 2
    }

}

class PowerCPU : ICPUInfo {

    override fun getCore() : Int {
        return 8
    }

}

● 何為穩定性？

高穩定的設計在周遭環境變化時仍可以作到很少的異動就達成業務需求！