當我第一次開始涉足軟體開發世界時,我經常發現自己被周圍飛來飛去的流行語和概念淹沒。似乎特別令人畏懼的概念之一是「堅實的原則」。感覺就像只有「認真的」開發人員才需要擔心的事情。但隨著我對編碼越來越熟悉,我意識到這些原則並不是花哨,而是編寫不會讓你在幾個月後就想抓狂的程式碼。
所以,這是我對 JavaScript 中 SOLID 原則的看法——一本嚴肅實用的指南,我希望在開始時就擁有它。
單一職責原則規定,一個類別應該只有一個改變的理由,這意味著它應該只有一項工作或職責。
想像一下您最喜歡的咖啡店的咖啡師。他們的工作是煮咖啡。如果他們突然必須開始修理濃縮咖啡機、提供糕點、倒垃圾,事情就會變得混亂。就像咖啡師應該專注於煮咖啡一樣,你的班級應該專注於做好一件事。
假設您有一個 User 類,用於處理使用者驗證、資料驗證和資料庫儲存。做得太過分了!透過將這些職責拆分為單獨的類,可以使程式碼更易於管理和維護。
class UserAuthenticator { login(user) { // handle login } } class UserDataValidator { validate(user) { // validate user data } } class UserDatabase { save(user) { // save user to the database } }
開放/封閉原則規定軟體實體應對擴充開放,但對修改關閉。換句話說,您應該能夠在不更改現有程式碼的情況下新增功能。
想像一下您最喜歡的遊戲機。您可以添加新遊戲、控制器和配件,但無需打開它並重新接線。同樣,您應該能夠在不更改其核心結構的情況下向程式碼添加新功能。
假設您有一個 Shape 類,其中包含計算面積的方法。如果您需要新增形狀(例如三角形),則不必修改現有類別。相反,延長它。
class Shape { area() { throw "Area method not implemented"; } } class Rectangle extends Shape { constructor(width, height) { super(); this.width = width; this.height = height; } area() { return this.width * this.height; } } class Circle extends Shape { constructor(radius) { super(); this.radius = radius; } area() { return Math.PI * this.radius * this.radius; } }
里氏替換原則規定超類別的物件應該可以用子類別的物件替換,而不影響程式的正確性。
想像一下租車。無論您購買的是轎車還是 SUV,您都希望它具有汽車的基本功能:駕駛、轉向和停車。如果您的租賃汽車需要一套完全不同的控制裝置,那麼您就有麻煩了!同樣,子類別的行為方式應該不違反其父類別設定的期望。
如果你有一個 Bird 類和一個擴展它的 Penguin 類,那麼 Penguin 的行為仍然應該像 Bird,即使它不能飛。它仍然應該行走、進食,甚至可能游泳。
class Bird { move() { console.log("Flies in the sky"); } } class Penguin extends Bird { move() { console.log("Swims in the water"); } } const myBird = new Bird(); const myPenguin = new Penguin(); myBird.move(); // Flies in the sky myPenguin.move(); // Swims in the water
介面隔離原則建議客戶端不應被迫實作他們不使用的介面。您不應該創建一個大的介面,而應該創建更小、更具體的介面。
想像一家餐廳,廚師還必須兼任服務生、調酒師和洗碗機。這是壓倒性的和低效的!相反,每個角色都應該有其特定的任務。同樣,您的介面應該專業化且專注。
如果您有一個包含 buildHouse、paintHouse 和 designHouse 等方法的 Worker 接口,則僅粉刷房屋的 Worker 不必實現所有其他方法。將其分解為更小的介面。
class Builder { build() { console.log("Building house..."); } } class Painter { paint() { console.log("Painting house..."); } } class Designer { design() { console.log("Designing house..."); } }
依賴倒置原則指出高階模組不應該依賴低階模組。兩者都應該依賴抽象。
Think about how you plug your phone charger into a wall socket. You don’t need to know the details of the electrical wiring inside the walls—all you need is the interface (the socket) to power your device. Similarly, your code should depend on abstractions (interfaces), not concrete implementations.
If you have a LightBulb class that directly controls a Switch class, you’re creating a tight coupling. Instead, both should depend on an interface like PowerSource.
class LightBulb { turnOn(powerSource) { powerSource.provideElectricity(); console.log("Light is on"); } } class Switch { constructor(powerSource) { this.powerSource = powerSource; } operate() { this.powerSource.togglePower(); } } class PowerSource { provideElectricity() { console.log("Providing electricity"); } togglePower() { console.log("Toggling power"); } }
Mastering the SOLID principles is like learning to cook with a set of proven recipes. Once you understand them, you can whip up code that’s not just functional but elegant and easy to maintain. So next time you find yourself in a coding conundrum, remember: there’s a principle for that!
Happy coding! ?
以上是讓 SOLID 變得簡單:乾淨程式碼原則的 JavaScript 指南的詳細內容。更多資訊請關注PHP中文網其他相關文章!