任何具有軟件編程經驗的人都會根據他們的職業道路，使用判斷參數來判斷他人編寫的軟件代碼。
在我的職業生涯中，我認識了許多開發人員，並且已經看到數千行代碼，當我需要評估開發人員的技能時，我主要關注以下兩個因素：
幸運的是，有一些基礎知識或原理可以使您更好地進行編碼。
首字母縮寫詞SOLID代表：
S：單一責任原則
O：開閉原理
L：Liskov替代原則
I：接口隔離原理
D：依賴倒置原則
讓我們開始研究第一個SOLID原則，即
一個類（或模塊）應該只有一個改變，發展的理由。
概念本身非常簡單，但是要實現這種簡單性，實現路徑可能會非常複雜。 一個班級只有一個改變的理由。
但為什麼？
為什麼只有一個更改理由如此重要？
例如，如果有兩個不同的更改原因，則可以想像兩個不同的團隊可以出於兩個不同的原因來處理同一代碼。 每個人都必須實現自己的解決方案，在使用編譯語言（例如C ++，C＃或Java）的情況下，這可能導致模塊與其他團隊或應用程序的其他部分不兼容。
另一個示例，如果您使用的是解釋語言，則可能由於不同的原因必須重新測試同一類或模塊。 這意味著需要更多的工作，時間和精力進行質量控制。
識別類或模塊應具有的功能比僅查看檢查表來運行測試要復雜得多。
但是，讓我們嘗試從較不技術的角度進行思考，即嘗試分析類或模塊的用戶，即誰將使用它。 我們必須始終牢記的一個基本方面是，我們開發的由特定模塊提供服務的應用程序或系統的用戶將是那些要求對其進行修改的用戶。 所服務的人員將要求更改課程或模塊。
模塊及其用法的一些示例：
因此，如果第一步是在模塊中尋找扮演對話者角色的演員或演員，將個人與所有角色聯繫起來可能會很困難。 在小公司中，一個人可以扮演多個角色，而在大公司中，可以有多個人扮演一個角色。
確定角色而不是人員或用戶似乎更合理。
所以：
讓我們看一些例子
假設我們有一個Book類，它封裝了一本書的概念及其功能。
課堂書籍{
函數getTitle（）{
返回“一本好書”；
}
函數getAuthor（）{
返回“ Alessandro Baricco”；
}
函數下一頁（）{
// 下一頁
}
函數printCurrentPage（）{
回顯“當前頁面的內容”；
}
}
這是很普通的課。 我們有一本書，全班可以給我們標題，他們可以給我們作者，他們可以繼續前進。 最後，它還能夠在屏幕上打印當前頁面。
但是，有一個小問題。
考慮參與管理Book對象的參與者，他們可能是誰？
我們可以在這裡輕鬆想到兩個不同的參與者： 圖書管理 （作為 館員）和 數據提交機制 （例如我們希望如何向用戶交付內容：屏幕，圖形用戶界面，純文本用戶界面，也許是打印）。
因此，我們有兩個截然不同的演員與全班互動。
簡而言之，該類介於以下兩者之間：
這可能是一個問題，因為它違反了單一責任原則（SRP）。
我們如何進行更改，如何改進此代碼以遵守單一責任原則？
看下面的代碼：
課堂書籍{
函數getTitle（）{
返回“ Oceano Mare”；
}
函數getAuthor（）{
返回“ Alessandro Baricco”；
}
功能翻頁（）{
// 下一頁
}
函數getCurrentPage（）{
回顯“當前頁面的內容”；
}
}
界面打印機{
函數printPage（$頁面）;
}
StampaLibro類實現打印機{
函數printPages（$頁面）{
echo $頁面；
}
}
HtmlPrinter類實現Printer {
函數printPages（$頁面）{
迴聲'。 $頁面。 ' ';
}
}
這個非常簡單的示例說明瞭如何將演示文稿與業務邏輯分開，並且符合SRP，它在我們項目的靈活性方面具有很大的優勢。
讓我們看另一個例子:
與上面的示例類似的示例是對象可以保存和從演示中檢索自身的情況。
課堂書籍{
函數getTitle（）{
返回“ Oceano Mare”；
}
函數getAuthor（）{
返回“ Alessandro Baricco”；
}
功能翻頁（）{
// 下一頁
}
函數getCurrentPage（）{
返回“當前頁面的內容”；
}
函數save（）{
$ filename ='/文件/'。 $ this-> getTitolo（）。 '-'。 $ this-> getAuthor（）;
file_put_contents（$ filename，serialize（$ this））;
}
}
和以前一樣，在這裡我們也可以識別不同的參與者，例如 圖書管理 （作為 館員）和 堅持不懈。 每當我們想要更改頁面的瀏覽方式時，我們都需要更改此類。 我們有幾種改變的原因。
課堂書籍{
函數getTitle（）{
返回“ Oceano Mare”；
}
函數getAuthor（）{
返回“ Alessandro Baricco”；
}
功能翻頁（）{
// 下一頁
}
函數getCurrentPage（）{
返回“當前頁面的內容”；
}
}
類SimpleFilePersistence {
功能保存（Book $ book）{
$ filename ='/文件/'。 $ book-> getTitle（）。 '-'。 $ book-> getAuthor（）;
file_put_contents（$文件名，序列化（$ book））；
}
}
將持久性操作移至另一類將明顯地將職責分開，並且我們可以自由地交換持久性方法而不會影響Book類。 例如，實現DatabasePersistence類將很簡單，並且圍繞書本操作構建的業務邏輯不會改變。
Ercole Palmeri
Casaleggio Associati 發布了義大利電子商務年度報告。題為「人工智慧商務：人工智慧電子商務的前沿」的報告...
