欢迎冒险家同伴来到软件设计领域，意大利面条代码之龙威胁着干净代码的王国！不要害怕，今天我们用传奇的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 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() } 

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

结论：英雄的 solid 代码之旅

掌握 solid 原则的旅程充满挑战，就像屠龙一样。但是有了单一职责、开放/封闭、里氏替换、接口隔离和依赖倒置的帮助，您的代码将像吟游诗人的歌谣一样流畅。

您现在挥舞着可维护设计的强大剑。勇敢的编码员，充满信心地进行重构！

如果您想更深入地了解任何特定领域，请告诉我！

以上就是SOLID 原则简介：代码的英雄传奇的详细内容，更多请关注php中文网其它相关文章！