每個開發(fā)者都應(yīng)該知道的七個原則
軟件開發(fā)是一門復(fù)雜的領(lǐng)域。是什么讓高質(zhì)量的軟件與容易出錯、充滿錯誤的軟件有所不同？答案通常在開發(fā)人員在編寫代碼時采用的核心原則中。
編程原則：優(yōu)秀代碼的基石
編程原則是卓越軟件的基石。這些建議和最佳實踐指導開發(fā)人員編寫既功能強大又優(yōu)雅、易維護和可擴展的代碼。
在本文中，我們深入探討了每個開發(fā)者工具包中都應(yīng)該有的七個基本編程原則：
1. DRY 原則
DRY：不要重復(fù)自己 — 減少冗余的關(guān)鍵原則。如果你發(fā)現(xiàn)自己復(fù)制粘貼同一段代碼超過兩次，現(xiàn)在是考慮抽象的時候了。
考慮這種情況：你有三個函數(shù)，每個函數(shù)都以相同的方式格式化日期。與其在所有三個函數(shù)中都有重復(fù)的格式化代碼，不如創(chuàng)建一個單一的輔助函數(shù)：
// 格式化日期的輔助函數(shù)
function formatDate(date) {
return `${date.getFullYear()}-${String(date.getMonth() + 1).padStart(2, '0')}-${String(date.getDate()).padStart(2, '0')}`;
}
// 函數(shù) 1: 顯示今天的日期
function displayTodaysDate() {
const today = new Date();
return formatDate(today);
}
// 函數(shù) 2: 顯示一周后的日期
function displayDateOneWeekFromNow() {
const oneWeekFromNow = new Date();
oneWeekFromNow.setDate(oneWeekFromNow.getDate() + 7);
return formatDate(oneWeekFromNow);
}
// 函數(shù) 3: 顯示一個月前的日期
function displayDateOneMonthAgo() {
const oneMonthAgo = new Date();
oneMonthAgo.setMonth(oneMonthAgo.getMonth() - 1);
return formatDate(oneMonthAgo);2. KISS 原則
KISS：保持簡單，愚蠢 — 在你的代碼中追求簡單。例如，如果你寫了一個復(fù)雜的 if-else 鏈，也許使用 switch 語句或字典會簡化和美化結(jié)構(gòu)：
之前：
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.';
}
}重構(gòu)后：
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 不是一個單一的原則，而是五個設(shè)計原則的集合。盡管它們根植于面向?qū)ο缶幊蹋∣OP），但它們的智慧可以更廣泛地應(yīng)用。
(1) 單一職責原則（SRP）： 一個類應(yīng)該只有一個改變的理由。這意味著每個類應(yīng)該只有一個任務(wù)或功能，確保更容易維護和在更改過程中減少副作用。
考慮這個例子：
// 錯誤的方法
class UserManager {
saveUser(user) {
// 保存用戶到數(shù)據(jù)庫的邏輯
}
generateReport(user) {
// 生成用戶報告的邏輯
}
}更優(yōu)雅的解決方案是將其拆分為兩個各自處理單一職責的類：
// 正確的方法
class UserDatabase {
save(user) {
// 將用戶數(shù)據(jù)保存到數(shù)據(jù)庫
}
}
class UserReport {
generate(user) {
// 為用戶生成報告
}
}在上面的代碼片段中，我們分擔了責任：UserReport 處理用戶的報告生成，而 UserDatabase 管理將用戶數(shù)據(jù)保存到數(shù)據(jù)庫。
(2) 開閉原則（OCP）： 軟件組件應(yīng)該對擴展開放，對修改關(guān)閉。這允許開發(fā)人員在不修改現(xiàn)有代碼的情況下添加新功能，促進可重用性并減少錯誤。
假設(shè)你有一個 AreaCalculator 類，用于計算矩形的面積?，F(xiàn)在，如果我們添加一個 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：我們從一個基礎(chǔ)的 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）： 子類應(yīng)該能夠替換其基類而不產(chǎn)生異常。這確保繼承類保持其父類的屬性和行為。
遵循 LSP，我們應(yīng)該重構(gòu)設(shè)計以確保正確的繼承：
class Bird {
fly() {
// 通用飛行行為
}
}
class Penguin extends Bird {
// 企鵝不能飛，所以這個方法不應(yīng)該在這里
}正確的方法是我們將形狀從基本的 Shape 類擴展出來，允許輕松添加新的形狀而不修改 AreaCalculator。
(4) 接口隔離原則（ISP）： 類不應(yīng)該被迫實現(xiàn)它們不使用的接口。相反，接口應(yīng)該對其目的具體而清晰。
這意味著接口不應(yīng)該有太多方法，盡量我們將小接口抽取出來，以便類可以只實現(xiàn)它們需要的接口，就像下面的例子：
// 錯誤的方法
interface Worker {
work();
eat();
sleep();
swim();
}
// 正確的方法
interface Worker {
work();
}
interface Eater {
eat();
}
interface Swimmer {
swim();
}(5) 依賴反轉(zhuǎn)原則（DIP）： 高層模塊不應(yīng)與低層模塊糾纏在一起；它們都應(yīng)依賴于抽象。例如在開關(guān)和設(shè)備的設(shè)計中可以找到：
// 錯誤的方法
class LightBulb {
turnOn() {}
turnOff() {}
}
class Switch {
constructor(bulb) {
this.bulb = bulb;
}
operate() {
// 直接控制燈泡
}
}我們可以重構(gòu)這樣，以便 Switch 可以對任何實現(xiàn) SwitchableDevice 的設(shè)備進行操作，而不僅僅是 LightBulb。
// 正確的方法
class SwitchableDevice {
turnOn() {}
turnOff() {}
}
class Bulb extends SwitchableDevice {
// 實現(xiàn) turnOn 和 turnOff 方法
}
class SwitchDIP {
constructor(device) {
this.device = device;
}
operate() {
// 控制設(shè)備
}
}4. YAGNI 原則
YAGNI，“你不會需要它”，警告不要在必要之前添加功能。
例如，如果你正在構(gòu)建一個博客網(wǎng)站，并考慮添加一個基于用戶寫作的功能來預(yù)測用戶的心情，但這對于網(wǎng)站正常運行并不是必需的，那么最好將其留在一邊，至少現(xiàn)在是這樣。
有不必要功能的應(yīng)用：
class Blog {
constructor(posts) {
this.posts = posts;
}
addPost(post) {
this.posts.push(post);
}
displayPosts() {
// 顯示所有帖子
}
predictUserMoodBasedOnWritings(post) {
// 預(yù)測情緒的復(fù)雜算法
// ...
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，或“關(guān)注點分離”，建議不同的功能區(qū)域應(yīng)由不同且最小重疊的模塊管理。
例如，在一個天氣應(yīng)用程序中，一個模塊可以處理數(shù)據(jù)獲取，另一個可以管理數(shù)據(jù)存儲，另一個則可以控制用戶界面。每個都有自己的關(guān)注點，與其他模塊分開。
// 1. 數(shù)據(jù)獲取模塊
function fetchWeatherData(city) {
const apiKey = 'YOUR_API_KEY';
const response = fetch(`https://api.weather.com/v1/${city}?apiKey=${apiKey}`);
return response.json();
}
// 2. 數(shù)據(jù)存儲模塊
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>`;
}
// 在主應(yīng)用程序函數(shù)中組合它們
function weatherApp(city) {
const data = fetchWeatherData(city);
storeWeatherData(data);
displayWeatherData(data);
}6. LoD 原則
LoD（迪米特法則）是開發(fā)軟件的一個指導原則，特別是面向?qū)ο蟮某绦?。在其一般形式中，LoD是松散耦合的一個具體案例。
想象一下餐廳的場景：顧客將訂單（方法）交給服務(wù)員，然后服務(wù)員將訂單交給廚師。顧客不直接與廚師互動。
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 原則
組合優(yōu)于繼承原則（COI）建議使用組合（將簡單對象組合以創(chuàng)建更復(fù)雜的對象）而不是類繼承。
想象一下你有一個類 Bird 和一個類 Airplane。它們都能飛，但有繼承關(guān)系并不合理。相反，你可以有一個 CanFly 類，并將你的 Bird 和 Airplane 類與它組合。
// 錯誤的方法：繼承
class CanFly {
fly() {
console.log(this.constructor.name + ' is flying!');
}
}
class BirdInherit extends CanFly {}
class AirplaneInherit extends CanFly {}通過以下組合方法，你可以輕松地向 BirdCompose 或 AirplaneCompose 添加或刪除功能，而無需進行結(jié)構(gòu)更改或添加不必要的冗余，強調(diào)靈活性。
// 正確的方法：組合
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();
}
}
