每個開發者都應該知道的七個原則
軟件開發是一門復雜的領域。是什么讓高質量的軟件與容易出錯、充滿錯誤的軟件有所不同？答案通常在開發人員在編寫代碼時采用的核心原則中。
編程原則：優秀代碼的基石
編程原則是卓越軟件的基石。這些建議和最佳實踐指導開發人員編寫既功能強大又優雅、易維護和可擴展的代碼。
在本文中，我們深入探討了每個開發者工具包中都應該有的七個基本編程原則：
1. DRY 原則
DRY：不要重復自己 — 減少冗余的關鍵原則。如果你發現自己復制粘貼同一段代碼超過兩次，現在是考慮抽象的時候了。
考慮這種情況：你有三個函數，每個函數都以相同的方式格式化日期。與其在所有三個函數中都有重復的格式化代碼，不如創建一個單一的輔助函數：
// 格式化日期的輔助函數
function formatDate(date) {
return `${date.getFullYear()}-${String(date.getMonth() + 1).padStart(2, '0')}-${String(date.getDate()).padStart(2, '0')}`;
}
// 函數 1: 顯示今天的日期
function displayTodaysDate() {
const today = new Date();
return formatDate(today);
}
// 函數 2: 顯示一周后的日期
function displayDateOneWeekFromNow() {
const oneWeekFromNow = new Date();
oneWeekFromNow.setDate(oneWeekFromNow.getDate() + 7);
return formatDate(oneWeekFromNow);
}
// 函數 3: 顯示一個月前的日期
function displayDateOneMonthAgo() {
const oneMonthAgo = new Date();
oneMonthAgo.setMonth(oneMonthAgo.getMonth() - 1);
return formatDate(oneMonthAgo);2. KISS 原則
KISS：保持簡單，愚蠢 — 在你的代碼中追求簡單。例如，如果你寫了一個復雜的 if-else 鏈，也許使用 switch 語句或字典會簡化和美化結構：
之前：
function getErrorMessage(errorCode) {
if (errorCode = 'E001') {
return 'Invalid input.';
} else if (errorCode = 'E002') {
return 'Connection timed out.';
} else if (errorCode = 'E003') {
return 'Database error.';
} else if (errorCode = 'E004') {
return 'File not found.';
} else {
return 'Unknown error.';
}
}重構后：
const ERROR_MESSAGES = {
'E001': 'Invalid input.',
'E002': 'Connection timed out.',
'E003': 'Database error.',
'E004': 'File not found.'
};
function getErrorMessage(errorCode) {
return ERROR_MESSAGES[errorCode] || 'Unknown error.';
}3. SOLID 原則
SOLID 不是一個單一的原則，而是五個設計原則的集合。盡管它們根植于面向對象編程（OOP），但它們的智慧可以更廣泛地應用。
(1) 單一職責原則（SRP）： 一個類應該只有一個改變的理由。這意味著每個類應該只有一個任務或功能，確保更容易維護和在更改過程中減少副作用。
考慮這個例子：
// 錯誤的方法
class UserManager {
saveUser(user) {
// 保存用戶到數據庫的邏輯
}
generateReport(user) {
// 生成用戶報告的邏輯
}
}更優雅的解決方案是將其拆分為兩個各自處理單一職責的類：
// 正確的方法
class UserDatabase {
save(user) {
// 將用戶數據保存到數據庫
}
}
class UserReport {
generate(user) {
// 為用戶生成報告
}
}在上面的代碼片段中，我們分擔了責任：UserReport 處理用戶的報告生成，而 UserDatabase 管理將用戶數據保存到數據庫。
(2) 開閉原則（OCP）： 軟件組件應該對擴展開放，對修改關閉。這允許開發人員在不修改現有代碼的情況下添加新功能，促進可重用性并減少錯誤。
假設你有一個 AreaCalculator 類，用于計算矩形的面積。現在，如果我們添加一個 Circle，AreaCalculator 將需要修改。
// 錯誤的方法
class AreaCalculator {
calculateArea(shape) {
if (shape.type = "circle") {
return 3.14 * shape.radius * shape.radius;
} else if (shape.type = "square") {
return shape.side * shape.side;
}
}
}相反，使用 OCP：我們從一個基礎的 Shape 類擴展我們的形狀，允許輕松添加新形狀而不修改 AreaCalculator。
// 正確的方法
class Shape {
calculateArea() {}
}
class Circle extends Shape {
constructor(radius) {
super();
this.radius = radius;
}
calculateArea() {
return 3.14 * this.radius * this.radius;
}
}
class Square extends Shape {
constructor(side) {
super();
this.side = side
;
}
calculateArea() {
return this.side * this.side;
}
}(3) 里氏替換原則（LSP）： 子類應該能夠替換其基類而不產生異常。這確保繼承類保持其父類的屬性和行為。
遵循 LSP，我們應該重構設計以確保正確的繼承：
class Bird {
fly() {
// 通用飛行行為
}
}
class Penguin extends Bird {
// 企鵝不能飛，所以這個方法不應該在這里
}正確的方法是我們將形狀從基本的 Shape 類擴展出來，允許輕松添加新的形狀而不修改 AreaCalculator。
(4) 接口隔離原則（ISP）： 類不應該被迫實現它們不使用的接口。相反，接口應該對其目的具體而清晰。
這意味著接口不應該有太多方法，盡量我們將小接口抽取出來，以便類可以只實現它們需要的接口，就像下面的例子：
// 錯誤的方法
interface Worker {
work();
eat();
sleep();
swim();
}
// 正確的方法
interface Worker {
work();
}
interface Eater {
eat();
}
interface Swimmer {
swim();
}(5) 依賴反轉原則（DIP）： 高層模塊不應與低層模塊糾纏在一起；它們都應依賴于抽象。例如在開關和設備的設計中可以找到：
// 錯誤的方法
class LightBulb {
turnOn() {}
turnOff() {}
}
class Switch {
constructor(bulb) {
this.bulb = bulb;
}
operate() {
// 直接控制燈泡
}
}我們可以重構這樣，以便 Switch 可以對任何實現 SwitchableDevice 的設備進行操作，而不僅僅是 LightBulb。
// 正確的方法
class SwitchableDevice {
turnOn() {}
turnOff() {}
}
class Bulb extends SwitchableDevice {
// 實現 turnOn 和 turnOff 方法
}
class SwitchDIP {
constructor(device) {
this.device = device;
}
operate() {
// 控制設備
}
}4. YAGNI 原則
YAGNI，“你不會需要它”，警告不要在必要之前添加功能。
例如，如果你正在構建一個博客網站，并考慮添加一個基于用戶寫作的功能來預測用戶的心情，但這對于網站正常運行并不是必需的，那么最好將其留在一邊，至少現在是這樣。
有不必要功能的應用：
class Blog {
constructor(posts) {
this.posts = posts;
}
addPost(post) {
this.posts.push(post);
}
displayPosts() {
// 顯示所有帖子
}
predictUserMoodBasedOnWritings(post) {
// 預測情緒的復雜算法
// ...
return "Happy"; // 只是一個示例情緒
}
notifyUserAboutMood(mood) {
// 通知邏輯
console.log(`Based on your writing, you seem to be ${mood}`);
}
}刪除不必要功能后：
class Blog {
constructor(posts) {
this.posts = posts;
}
addPost(post) {
this.posts.push(post);
}
displayPosts() {
// 顯示所有帖子
}
}5. SoC 原則
SoC，或“關注點分離”，建議不同的功能區域應由不同且最小重疊的模塊管理。
例如，在一個天氣應用程序中，一個模塊可以處理數據獲取，另一個可以管理數據存儲，另一個則可以控制用戶界面。每個都有自己的關注點，與其他模塊分開。
// 1. 數據獲取模塊
function fetchWeatherData(city) {
const apiKey = 'YOUR_API_KEY';
const response = fetch(`https://api.weather.com/v1/${city}?apiKey=${apiKey}`);
return response.json();
}
// 2. 數據存儲模塊
function storeWeatherData(data) {
localStorage.setItem('weatherData', JSON.stringify(data));
}
// 3. 用戶界面模塊
function displayWeatherData(data) {
const weatherBox = document.querySelector('#weather-box');
weatherBox.innerHTML = `<h1>${data.city}</h1><p>${data.temperature}°C</p>`;
}
// 在主應用程序函數中組合它們
function weatherApp(city) {
const data = fetchWeatherData(city);
storeWeatherData(data);
displayWeatherData(data);
}6. LoD 原則
LoD（迪米特法則）是開發軟件的一個指導原則，特別是面向對象的程序。在其一般形式中，LoD是松散耦合的一個具體案例。
想象一下餐廳的場景：顧客將訂單（方法）交給服務員，然后服務員將訂單交給廚師。顧客不直接與廚師互動。
class Customer {
constructor(waiter) {
this.waiter = waiter;
}
giveOrder(order) {
console.log("Customer: I'd like to order " + order);
this.waiter.takeOrder(order);
}
}
class Waiter {
constructor(chef) {
this.chef = chef;
}
takeOrder(order) {
console.log('Waiter: Order received - ' + order);
this.chef.prepareOrder(order);
}
}
class Chef {
prepareOrder(order) {
console.log('Chef: Preparing ' + order);
// Logic to prepare the food...
}
}7. COI 原則
組合優于繼承原則（COI）建議使用組合（將簡單對象組合以創建更復雜的對象）而不是類繼承。
想象一下你有一個類 Bird 和一個類 Airplane。它們都能飛，但有繼承關系并不合理。相反，你可以有一個 CanFly 類，并將你的 Bird 和 Airplane 類與它組合。
// 錯誤的方法：繼承
class CanFly {
fly() {
console.log(this.constructor.name + ' is flying!');
}
}
class BirdInherit extends CanFly {}
class AirplaneInherit extends CanFly {}通過以下組合方法，你可以輕松地向 BirdCompose 或 AirplaneCompose 添加或刪除功能，而無需進行結構更改或添加不必要的冗余，強調靈活性。
// 正確的方法：組合
class CanFlyComposition {
fly() {
console.log('Flying in the sky!');
}
}
class BirdCompose {
constructor() {
this.flyingCapability = new CanFlyComposition();
}
fly() {
this.flyingCapability.fly();
}
}
class AirplaneCompose {
constructor() {
this.flyingCapability = new CanFlyComposition();
}
fly() {
this.flyingCapability.fly();
}
}
