這兩個代碼，哪個更合理？哪個更容易維護？
如果要保證每個方法不超過20行，造汽車1比較好。但是方法太多，調來調去，跳來跳去，好像也不易閱讀。
造汽車2一個方法的代碼可能上百行，但只要一個方法。雖然感覺壓力很大，但是想象成讀文章，好像也合理。而且可以用注釋把代碼分段。
public class 造汽車1 {
public void 造一輛汽車() {
采礦();
把礦做成原料();
把原料做成零件();
把零件組裝成汽車();
出廠前檢查();
}
private void 采礦() {
System.out.println("采礦");
}
private void 把礦做成原料() {
System.out.println("把礦做成原料");
}
private void 把原料做成零件() {
System.out.println("把原料做成零件");
}
private void 把零件組裝成汽車() {
System.out.println("把零件組裝成汽車");
}
private void 出廠前檢查() {
System.out.println("出廠前檢查");
}
public static void main(String[] args) {
new 造汽車1().造一輛汽車();
}
}public class 造汽車2 {
public void 造一輛汽車() {
System.out.println("采礦");
System.out.println("把礦做成原料");
System.out.println("把原料做成零件");
System.out.println("把零件組裝成汽車");
System.out.println("出廠前檢查");
}
public static void main(String[] args) {
new 造汽車2().造一輛汽車();
}
}
uj5u.com熱心網友回復：
這個要看你的是實際應用場景，這個造汽車的功能是否單一，如果只是單單設計一個類，能夠按照步驟成功創建一個想要的物件，那么汽車2肯定更簡單直接。但是如果考慮到以后的擴展以及和其他的類的關系，肯定汽車1的寫法可操作性更強，靈活性與結合性都會更好~uj5u.com熱心網友回復：
兩種代碼結構，從可維護性上來看，當然是第一種優于第二種了。第二種，所有功能的代碼堆疊在一起，不但閱讀會造成困難，變數在前后的使用上會產生嚴重的依賴，由于處理環節的增多，就很容易產生漏洞。
第一種，把核心處理程序拆分成五個階段，每個階段對應一個函式呼叫，如果樓主覺得閱讀困難，那一定是處理程序的拆分存在問題，如果處理程序的拆分是合理的，閱讀起來反而會更加的輕松（相比第二種寫法）。
另外，一個大的處理程序，除了處理程序的拆分外，每個處理程序的處理環節，也會遇到拆分的情況。這樣的話，我們會創建個多的類來有層次的拆分和處理。樓主如果想深入了解這方面的內容的話，推薦樓主看看設計模式里面的幾種行為模式，就是教你不同場景下，怎樣相對合理的拆分和組織代碼的。
uj5u.com熱心網友回復：
你這兩種設計都不合格要保證擴展性和低耦合 每一個動作都要考慮指責 比如采礦可以定義一個采礦的介面 提供采礦方法 每種礦的開采可能都不一樣 需要實作類 而造汽車需要哪種礦就參考那種礦的實作 執行采礦方法 后面幾個步驟類似.
造汽車類把控好操作步驟就夠了 比如需要什么礦石 用什么方式轉換成原料 用什么方法做成零件? 中間可以穿插一些圖紙類 用單一指責讓專門的類去做好了 其實造汽車類我們要定義成一個介面 具體造什么汽車 我們再一一實作
uj5u.com熱心網友回復：
第一種做法好像更符合面相物件的標準。
但是，最近我在網上下載一個飛機大戰的游戲，十幾個類，繼承和呼叫關系想必也是復雜，還沒有結構圖沒有說明檔案，我差點找不到main在哪個類里面。雖然我是初學，但還是感覺到閱讀陌生的面相物件的代碼的難度，配合api檔案，能看懂每一行代碼，但就是對整體毫無感覺。
uj5u.com熱心網友回復：
你好，我現在還沒到那個階段，但聽起來你的思路應該是很標準的面向物件的思路了。
對于目前的我來說，讀你這樣的代碼，就像讀一本100頁的小說，但小說被分開裝訂在50本書中，我除了花精力理解每句代碼，還要額外精力去翻50本書（翻書簡單但翻多了也會累）。
uj5u.com熱心網友回復：
你這個方法名和類名怎么用的中文uj5u.com熱心網友回復：
如果要可維護的話，不是簡簡單單的一個類能解決的，需要功能細分，甚至每個功能都是一個模塊。而且最好做成介面模式，這樣優化的時候或者實作邏輯變化的時候，只要修改介面的實作類，其他都不需要改動，甚至可以通過配置決定到底是哪個實作類來實作這個功能。
uj5u.com熱心網友回復：
第一種更合理方法名，
step101_采礦
---將來擴展102，103
step201＿做成原料
step301
uj5u.com熱心網友回復：
第一種方法好uj5u.com熱心網友回復：
能看懂代碼，就是成功的基礎。為什么對專案的整體沒有概念，這是每個初學者都會遇到的問題。并且，這個問題沒有一個快速解決的辦法。
我這里推薦樓主兩個笨辦法：
第一，重新閱讀和理解專案代碼，讀懂每一條陳述句只是第一步，再讀幾遍原始碼，你的眼光就不會停留在每一句代碼的上面，而是會對每個方法（或者說每個函式）有個直觀的印象。當你對所有的方法，都有一個直觀的印象的時候，就可以進行第三步了。第三步還是要繼續閱讀原始碼，了解為什么這幾個函式要寫在這個類里面，為什么這個函式做的兩件事，不能拿一件事出來放到另一個類里面處理，等等的這些考慮。閱讀的遍數多了，自然就會掌控全域了。初學者讀十幾個類的專案，已經是極限了，不要再看更復雜的專案了。
第二，在多次閱讀同一個小專案之后，可以嘗試不看專案原始碼，自己獨立完成一個相同功能的專案。也就是說，不抄人家代碼，模仿著做一遍這個專案，獨立撰寫很重要，拷貝粘貼除了浪費時間，沒有任何作用。
最后，我要說明的一點，做開發這一行，每個階段都會有一個痛苦的程序，想要自己獨立成長成為參天大樹，不吃苦是不行的。推薦一本書《Java編程思想》。
uj5u.com熱心網友回復：
abstract class 造汽車{
public void 造一輛汽車() {
采礦();
把礦做成原料();
把原料做成零件();
把零件組裝成汽車();
出廠前檢查();
}
abstract 采礦();
......
}
class 造奔馳汽車 extends 造汽車{
public 采礦(){
采牛逼礦;
}
......
}
class 造奔奔汽車 extends 造汽車{
public 采礦(){
采土逼礦;
}
......
}
下面還要造很多種汽車，造車各個程序需要隨意組合。
uj5u.com熱心網友回復：
我認為代碼設計合理是讓你最小代碼來修改代碼的功能，因為代碼可能是你設計的但是修改可能是別人修改的，如果每次修改都需要重新讀代碼這樣還有效率可言么？所以優秀的設計是不需要別人讀程式，預留了擴展功能的介面。
uj5u.com熱心網友回復：
分工協作，如果造汽車要從采礦開始，那什事都沒法完成了！造汽車只是組裝就可以了
uj5u.com熱心網友回復：
實際上沒有絕對好的方法，不能走兩個極端。分層細致有利于擴展，不利于閱讀；分層粗糙正好相反。我的意見：簡單業務就分層粗糙一些，復雜業務就分層細致一些。總不能蓋個雞窩，就要把選址、環評、設計、采購、組織施工、竣工驗收等正規流程都走一遍吧（過渡設計），反之摩天大樓總不能拍拍腦門就開工吧。
uj5u.com熱心網友回復：
兩種代碼結構，從可維護性上來看，當然是第一種優于第二種了。第二種，所有功能的代碼堆疊在一起，不但閱讀會造成困難，變數在前后的使用上會產生嚴重的依賴，由于處理環節的增多，就很容易產生漏洞。
第一種，把核心處理程序拆分成五個階段，每個階段對應一個函式呼叫，如果樓主覺得閱讀困難，那一定是處理程序的拆分存在問題，如果處理程序的拆分是合理的，閱讀起來反而會更加的輕松（相比第二種寫法）。
另外，一個大的處理程序，除了處理程序的拆分外，每個處理程序的處理環節，也會遇到拆分的情況。這樣的話，我們會創建個多的類來有層次的拆分和處理。樓主如果想深入了解這方面的內容的話，推薦樓主看看設計模式里面的幾種行為模式，就是教你不同場景下，怎樣相對合理的拆分和組織代碼的。
uj5u.com熱心網友回復：
學習學習
uj5u.com熱心網友回復：
類比存在問題,小說還是那個小說,但不是很多本,閱讀設計良好的代碼,你需要從高層次去了解代碼設計意圖,就好比你看一本技術書籍,你可以先從目錄開始看齊,從整體上把握書的節奏,然后看具體的功能.
當然水平一般,自然只能從頭看到尾,那對他來說,流水賬或許更適合他,但技術了得,就只需要看他關注的部分.
uj5u.com熱心網友回復：
代碼可維護性就是一部機器被分解成一個一個部件，當你需要維修的時候只要維修損壞的部件，而不需要了解整個機器的運行原理。需要了解全部程序才能進行修改程式，只能說維護性很差。不管是100頁小說還是分開裝訂50本書，如果要全看的都一樣累人。
uj5u.com熱心網友回復：
第一種更合適。uj5u.com熱心網友回復：
吃得苦中苦，方為人上人。聰明的人會自己想出辦法來解決問題，相對笨一些的人會通過學習別人的東西來解決問題，次之的人，知道學習別的東西能解決問題，但是，由于怕麻煩，怕苦，怕累等等的原因，從而潦草解決或者不解決問題的人，最笨的一類人，要么是怎么學習都學不會，要么就是不知道學別人的東西自己又搞不定，還一直在堅持著，其實，這叫做愚。uj5u.com熱心網友回復：
// 如果有這樣的需求，肯定是第一種更好了。public void 造一輛汽車() {
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("采礦");
System.out.println("把礦做成原料");
System.out.println("把原料做成零件");
System.out.println("把零件組裝成汽車");
System.out.println("出廠前檢查");
}
-- 直接
public void 造一輛汽車() {
for(int i=0; i<20; i++){
System.out.println("采礦");
}
System.out.println("把礦做成原料");
System.out.println("把原料做成零件");
System.out.println("把零件組裝成汽車");
System.out.println("出廠前檢查");
}
uj5u.com熱心網友回復：
我覺得第一個挺不錯uj5u.com熱心網友回復：
感覺很強啊 雖然看不懂uj5u.com熱心網友回復：
我個人傾向第一種，高內聚低耦合是作為程式開發的原則。uj5u.com熱心網友回復：
這看上去是個基礎問題 實際上很難uj5u.com熱心網友回復：
第一種更合理。uj5u.com熱心網友回復：
看上去還不錯，希望沒什么毛病uj5u.com熱心網友回復：
具體情況具體分析uj5u.com熱心網友回復：
這兩種方法都不太靠譜，如果非要選擇一個的話，第一個好點。為什么說不靠譜呢，因為造車最直接的可能就是組裝零件。而原料的采集這已經不是直接聯系了，還有出廠檢查。這也不是造車環節。uj5u.com熱心網友回復：
不錯不錯。。。。。。uj5u.com熱心網友回復：
你好。你說的應該是過度設計的問題，只要一個香蕉，卻做出來一片森林和一只拿著香蕉的猩猩。
我想問的是設計模式，一段代碼是分解成若干方法好，還是把這段代碼全部丟在一個方法里面好。
uj5u.com熱心網友回復：
用分析的方法進行解答uj5u.com熱心網友回復：
前段時間又理解了一下 對修改封閉，對擴展支持當時就比較納悶兒【也是基于一些實際經驗】：
它的目的、以及好處毋庸置疑。但如果我實作的一個類。一個模塊。再后來的使用程序中發現：缺少了某樣介面。此時從理論上講、無論如何也無法在類、或者模塊兒未提供介面的前提下 擴展出來。
那么，對修改封閉豈不是就無法拓展介面了？
---------------------------------------------
多次思考、暫時確認，如我所問那樣的情況。如果模塊缺少某個介面，未提供時。外部想要使用這個的時候，除非修改原模塊。否則無法完成功能。
---------------------------------------------
因此又有一個問題：
如果有上述情況，則不得不打破，所謂的開閉原則。說明了什么？
---------------------------------------------
我想，這可能說明：該模塊提供的介面不足【也即意味著該模塊是不足】以支撐上層需求的。
所以在設計某個模塊、基礎、支持、服務、之前，應該明確本模塊【將且僅將】提供哪些功能，從而實作對應的介面。
在此之上如果還是有應用要求更多的介面，那屬于不在設計當中的服務。那只能說另請高明、或者待我版本更迭。
---------------------------------------------
---------------------------------------------
---------------------------------------------
uj5u.com熱心網友回復：
開閉原則是設計準則,但不代表完全不修改,預期的擴展和實際業務發展的擴展可能并不一致,那代碼也需要及時重構,這個并沒有多大問題.
所以寫代碼并不需要過度設計,因為沒人能預測未來,只需要對當前業務進行設計,根據自己的經驗來做可擴展設計.
而且其實業務代碼很難做到這點的,開閉原則一般在框架層面,或者高層抽象層面,增刪改查沒必要糾結什么開閉原則,遵循規范,模塊化,確定邊界,邏輯內聚反而是更重要的.
uj5u.com熱心網友回復：
當真對于這個例子的話，可能更專業些的分類或許是：class 采礦場
{
func 采礦（xxx）；
}
class 原料加工場
{
func 提煉原料（xxx）；
}
class 零件加工廠
{
func 零件加工（）；
}
class 汽車組裝廠
{
func 組裝汽車（）；
}
....
-------------------------------------------------------
上述方式毋庸置疑，更加的模塊化了。更接近現實情景。
但如果、在我們的程式中，只可能討論關于汽車的組裝。也許分的那么細就沒有意義了。
-------------------------------------------------------
因為代碼中只討論汽車的組裝，不關心你組裝汽車的流程，那么好的。我們完成了代碼。寫成了一個模塊。只開放一個介面：
汽車 造汽車（type 汽車牌子）；//內部程序你不關心，也不提供你那些介面了
-------------------------------------------------------
此時如果想在這個模塊基礎上組裝一個輪船、那就沒了啊。因為沒有提供更多的介面。要么修改這個模塊，要么重寫一個。
uj5u.com熱心網友回復：
對當前業務進行設計,根據自己的經驗來做可擴展設計。
這位老師總結的很好，很有識訓。
uj5u.com熱心網友回復：
個人覺得第一種 更合理，而且方便后期維護uj5u.com熱心網友回復：
不知道你說的每個方法不超20行是不是硬性要求，是的話那就沒得說了，不是的話可以可以考慮。我們一般要求是一個方法里不超過200行都可以，還有一點是方法呼叫不可以超過3層，結構上講1比較好吧，但是如果代碼不多，做好注釋，2也可以uj5u.com熱心網友回復：
第一個吧 如果代碼太多第二個挺讓人頭疼的 不過一般像第一個那樣的我一般都是工具類用到uj5u.com熱心網友回復：
不考慮其他的單單是這些東西第二種簡潔明了，如應用在復雜場景，每個功能有更多更具體的業務肯定是第一種，解耦，復用uj5u.com熱心網友回復：
擇優第二，簡便。uj5u.com熱心網友回復：
一個函式只做好一件事。可以看看clean code這本書。uj5u.com熱心網友回復：
第一種方法作用單一，分隔開，便于以后的更新和修改，第二種方法將所有用途放在一起，省時省力，減少空間的使用。若使用在程式中，可以先使用第一種方法進行試運行，如果能起作用，第二種方法的運行不出問題，在程式確定下來之后，就可以將第一種方法替換，減少編程語言的行數，便于閱讀。uj5u.com熱心網友回復：
第一種更合理方法名，
step101_采礦
---將來擴展102，103
step201＿做成原料
step301
uj5u.com熱心網友回復：
不用太糾結。如果是做資料分析，用一次就不用的代碼，那就在main里面胡亂寫完就得了。如果是自己用的，或是開源代碼，考慮未來重用，那封裝個類或者函式就好了，簡單的作業傾向二，復雜的用一。
如果是閉源商業庫，就復雜了，要考慮很多，樓上很多人都說了。
uj5u.com熱心網友回復：
2好，怎么少怎么來uj5u.com熱心網友回復：
第一種方法好uj5u.com熱心網友回復：
若是我，還是推薦走第一種寫法。
uj5u.com熱心網友回復：
第一種好一些，程式更容易擴展，可以定義抽象類有采礦。。那些方法介面，不同的類實作不同的汽車可以繼承這個抽象類實作自己的采礦。。介面，程式更有擴展性uj5u.com熱心網友回復：
第一個代碼更合理uj5u.com熱心網友回復：
如果自己使用 第二種好 完整 不分散。如果考慮以后擴展和其他人合作的話 第一種好，因為分的細 好控制 好拆分 改寫一個功能 不會影響其它功能
uj5u.com熱心網友回復：
第一種。更好的是Builder模式——用內部類的方式。
uj5u.com熱心網友回復：
第一種做法好像更符合面相物件的標準轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/39621.html
標籤：Java SE