当前位置：首页 > 文章列表 > Golang > Go教程 > SOLID 原则简介：代码的英雄传奇

SOLID 原则简介：代码的英雄传奇

来源：dev.to 2024-10-22 15:49:07 0浏览收藏

欢迎各位小伙伴来到golang学习网，相聚于此都是缘哈哈哈！今天我给大家带来《SOLID 原则简介：代码的英雄传奇》，这篇文章主要讲到等等知识，如果你对Golang相关的知识非常感兴趣或者正在自学，都可以关注我，我会持续更新相关文章！当然，有什么建议也欢迎在评论留言提出！一起学习！

SOLID 原则简介：代码的英雄传奇

欢迎冒险家同伴来到软件设计领域，意大利面条代码之龙威胁着干净代码的王国！不要害怕，今天我们用传奇的solid原则武装自己。这些原则并不是无聊的规则，而是一些规则。它们是您在争取可维护、可扩展和无错误代码的战斗中的魔法盾牌和利剑。

但首先，代码重构的名称中的 solid 是什么？它代表五种骑士美德——单一职责、开放/封闭、里氏替换、接口隔离和依赖倒置.

拿起你的鼠标和键盘。让我们一起踏上这段充满曲折的旅程，甚至可能还会有一些糟糕的笑话。

s：单一职责原则（srp）——反单一咒语

定义：
一个类应该有一个且只有一个改变的理由。不要给你的班级带来生存危机！

实际操作：
想象一下一个中世纪的铁匠，他制作剑、烤面包并报税。他一边想磨利你的剑，一边考虑减税，而且锻造厂里有面粉。凌乱，对吧？这就是当你的班级试图做太多事情时会发生的事情！

相反，要保持课程的重点。上一堂课是制作剑，另一堂课是烘焙，第三堂课是对付税务巨魔。

示例：

// bad srp example
type blacksmith interface {
    makesword()
    bakebread()
    filetaxes()
}
// better srp example
type blacksmith interface {
    makesword()
}

type baker interface {
    bakebread()
}

type taxfiler interface {
    filetaxes()
}

肩负单一责任的骑士晚上睡得更好。相信我。

o：开闭原则 (ocp) - 门是关着的，但可以随意粉刷它！

定义：
您的课程应该对扩展开放，但对修改关闭。这就像拥有一扇精美的门，您可以装饰但永远无法拆除。

实际操作：
你已经培养了一位忠诚、值得信赖的侍从。但现在你需要他做更多的事——打水、磨剑、擦亮盔甲。不要改写他的 dna（代码）！只需添加到他的训练中即可。

不要每次都修改 squire 类，而是创建扩展。把门关上，但在上面挂一把时尚的剑！

示例：

// without ocp
type squire struct {
    fetchwater()
    sharpensword()
}

// with ocp: add without modifying
type task interface {
    perform()
}

type fetchwatertask struct {}

func (f fetchwatertask) perform() {
    // fetch water
}

type sharpenswordtask struct {}

func (s sharpenswordtask) perform() {
    // sharpen sword
}

现在您的代码可以像骑士的技能一样雄伟地发展，而无需重写核心。

l：里氏替换原理（lsp）——“冒名顶替综合症”的治愈方法

定义：
如果一个类从另一个类继承，它应该能够替换父类，而不会造成混乱（或者，在我们的例子中，不会造成运行时错误）。

实际操作：
想象一下你拥有一个马厩。马匹驰骋，独角兽……好吧，它们也在驰骋，但闪闪发光。现在，如果你把你的马换成独角兽，你不会指望独角兽会爆炸或拒绝驰骋，对吗？这就是 lsp 的实际应用。

你的子类（比如独角兽）的行为应该像父类（马）一样，没有任何意外的行为（请不要出现闪光爆炸）。

示例：

// lsp violation
type horse struct {
    gallop()
}

type unicorn struct {
    gallop() {
        // throws glitter instead of galloping!
    }
}

遵循lsp就像拥有一只乖巧的独角兽。它看起来很神奇，但不会破坏谷仓。

i：接口隔离原则（isp）——不必要契约的诅咒

定义：
客户不应被迫依赖他们不使用的接口。考虑分解合同，这样你就只签署必要的内容。
实际操作：
假设你是一名持剑的骑士。你的骑士公会给你一份合同，还要求你懂得射箭、比武和驯龙。但你只是想挥舞你的剑！除非他们愿意，否则不要让持剑的骑士学习驯龙。

示例：

// bad isp example
type warrior interface {
    fightwithsword()
    ridedragon()  // not every warrior rides dragons!
}

// better isp example
type swordsman interface {
    fightwithsword()
}

type dragonrider interface {
    ridedragon()
}

这样，你就可以专注于你最擅长的事情——挥剑——而把驯龙交给专业人士。

d：依赖倒置原则（dip）——不再有皇家傀儡师

定义：
高层模块不应该依赖于低层模块。两者都应该依赖于抽象。让农民（低级模块）和国王（高级模块）遵循相同的规律（接口）。

实际操作：
想象一个需要武器的骑士。他们并不要求铁匠提供特定的剑，而是要求任何符合武器界面的武器。这样，他们就可以使用剑、弓，甚至香蕉（如果有人实现的话）。骑士并不依赖于一种武器，而只依赖于武器的想法。

示例：

// Without DIP
type Knight struct {
    sword Sword
}

// With DIP
type Weapon interface {
    Use()
}

type Knight struct {
    weapon Weapon
}

func (k *Knight) Fight() {
    k.weapon.Use()
}

现在骑士很灵活，可以使用任何武器战斗，甚至是传奇的土豆大炮（如果编码正确）。