我的課有什麼問題？

提交代碼審查這兩個類（以及業務邏輯和數據訪問邏輯）。評論員笑着看着代碼，並建議我重新開課。他讓我做一些研究，不會給我任何線索。我找不到任何錯誤。它看起來有點尷尬，「子菜單」是基類而不是菜單。但我的要求就是這樣。。。菜單隻有兩個級別（子菜單永遠不會存在）。他們有什麼好笑的？如果有人向我展示改進這些課程的途徑，將不勝感激。我的課有什麼問題？

[Serializable] 
public class Menu: SubMenu 
{ 
    private List<SubMenu> _subMenu; 
    public List<SubMenu> SubMenu 
    { 
     get 
     { 
      if (_subMenu == null) 
       _subMenu = new List<SubMenu>(); 
      return _subMenu; 
     } 
     set 
     { 
      _subMenu = value; 
     } 
    } 
} 

[Serializable] 
public class SubMenu 
{ 
    public int ID { get; set; } 
    public string MenuText { get; set; } 
    public string MenuURL { get; set; } 
    public string ImageURL { get; set; } 
}

來源

2012-02-23 Romeo

當然應子從門繼承，而不是倒過來？子菜單：菜單 – CSharpened 2012-02-23 11:21:34

你甚至不說*這些類應該做什麼*。 – Jon 2012-02-23 11:21:57

良好的代碼審查的藝術是良好的反饋。審查他的評論並說明你的問題。 – 2012-02-23 11:21:57

這裏最大的問題是誰做你的評論的專業性 - 你應該問他們更具建設性和有益的，如果他們仍然堅持如此粗魯，我會把它帶給經理。

這就是說，我猜他們在你的設計中看到的事實是，你使用的是繼承。你需要繼承嗎？看起來，如果你有一個Menu類，它包含一個沒有父子關係的子菜單列表或者，它只是一個MenuItem對象，它可以包含它自己的一個列表。

我寧願實際上第二種方式，這樣的事情也許：

[Serializable] 
public class MenuItem 
{ 
    public MenuItem() 
    { 
     MenuItems = new List<MenuItem>(); 
    } 

    public int ID { get; set; } 
    public string MenuText { get; set; } 
    public string MenuURL { get; set; } 
    public string ImageURL { get; set; } 

    // I'm not bothering with the code to protect access to the list 
    // in this example but you might want that too... 
    public List<MenuItem> MenuItems { get; set; } 
}

來源

2012-02-23 11:40:21

我不知道如果我用下面的語句正確的是（和請不要糾正我，如果我錯了），但如果一個類從基類繼承，應在派生類中持有的項目清單它的基類？而且在什麼情況下可能會有用（我現在想不出任何）。如果我想到，例如，'馬'和'動物'：馬類是否應該列出動物列表？聽起來有點奇怪..

來源

2012-02-23 11:27:02 Abbas

聽起來像你從來沒有實現圖或樹，甚至列表（我的意思是不是基於數組的）。 – 2012-02-23 11:32:40

我從來沒有。 :) – Abbas 2012-02-23 11:34:48

我同意上面的評論員。對於你的審稿人只是笑，並沒有建設性的建議既粗魯又適得其反。我的回答將是'回去，並從評論者首先得到專業的建設性意見'。如果這不是即將到來的，恐怕看起來審稿人是由自我驅動的，而不是管理者和指導和教育的原則。

來源

2012-02-23 11:30:59

是的，回我的審稿人是我的選擇。但在此之前，我想確保一切都很好，就像#Orsol說的那樣，也許我應該爲基類提供更多的通用名稱。 – Romeo 2012-02-23 11:35:00

romi - 沒有一個完整的設計問題的背景下，我想你會隨風而去。現在起牀並預訂30分鐘的議程，重點關注您的問題。這種方式（來自您的評論者）強調了許多「商店」中錯誤的地方，教育和建設信心已不再重視 – 2012-02-23 11:38:24

考慮你的要求，我找錯的僅僅是一個命名問題：

public List<SubMenu> SubMenu

這是一個集合，它應該是複數。但嚴重的是，這沒什麼好笑的..

現在，如果你回到你的******è評審，獲得你的論點準備：

繼承PLUS集合是必需的，因爲菜單本身就是一個子菜單，因爲菜單有一個文本/ URL /圖像/ ID，它有一個子菜單集合，在他下面。
解釋SubMenu是Menu的基類的要求（實際上並不那麼直截了當）。

我最好的猜測是，它看起來都有點愚蠢，他只給了它一眼。

來源

2012-02-23 11:33:59

看來，你有哪些可包含兩種類型的菜單項

1）「簡單菜單項」（同上，文字，鏈接，圖片）
2）另一個菜單（子菜單）

我知道你只想深入一層，但實際上可以更簡單地重新使用廣義解決方案。

複合設計模式（http://en.wikipedia.org/wiki/Composite_pattern）似乎很適合。

hth，
Alan。

來源

2012-02-23 11:35:18 AlanT

提交了代碼審查這兩個類（以及業務邏輯和數據訪問邏輯）。評論員笑着看着代碼，並建議我重新開課。他讓我做一些研究，不會給我任何線索。

差評，真的是在有你看看它，特別是如果你真的看不出有什麼錯在你自己的代碼是沒有意義的。

我找不到任何錯誤。它看起來有點尷尬，「子菜單」是基類而不是菜單。但我的要求是這樣的...菜單隻有兩個級別（子子菜單永遠不會存在）。

我不覺得你的實現有趣，但天真的說，有這樣的事情，像「從來沒有」是有趣的。如果每次有人說某件事永遠不會發生時，我有一分錢，並且最終確實發生了，那麼現在至少有一個十五便士。

如果您的要求是菜單隻有兩個級別，請不要構建代碼以滿足該要求。但是，如果您有一個選項可以非常容易地將代碼打開到未來的擴展，那麼爲什麼不這樣做呢？沒有成本，只是好處。就你而言，我認爲「開放未來的延伸」確實很簡單。

他們有什麼好笑的？如果有人向我展示改進這些課程的途徑，將不勝感激。

這不一定有趣或錯誤。我會做不同的做法：如果一個菜單可以包含一個菜單，那不就是組成嗎？如果是這樣，菜單和子菜單有什麼區別？一個子菜單恰好有一個父母，但它應該在意嗎？它應該知道嗎？它實際上是否有與菜單本身不同的行爲？

class Menu 
    +addSubmenu(Menu menu) : Menu 
    +addItem(Item item) : Menu

這就是我的嘗試可能看起來像，可能。

來源

2012-02-23 11:38:03

你的對象的整體結構是好的，如延遲實例，儘管其他答案建議，我認爲你的產業有點小姐領先;但這不是問題！

以下是一些建議;儘管只需要1個深度，但我建議實施更多層次的可用性，因爲這不是太困難，並且可以幫助您在將來重新考慮事物。另外，我們可以在對象中添加一些構造函數，以便在創建新菜單項時更輕鬆。

我創建了我的菜單項的概念，這純粹是一個建議，但希望它有幫助。這裏有一些事情要注意。

我已經刪除了基礎對象
菜單項現在不再使用延遲實例化，而造成在施工列表
有新構造
菜單項可以是無限的深層次。

，這裏是它的外觀：

[Serializable] 
public class MenuItem 
{ 
    public int Id { get; set; } 
    public string MenuText { get; set; } 
    public string MenuUrl { get; set; } 
    public string ImageUrl { get; set; } 

    public List<MenuItem> Children { get; set; } 

    public MenuItem(int id, string text, string url) 
     : this(id, text, url, String.Empty) 
    { 
    } 

    public MenuItem(int id, string text, string url, string imageUrl) 
    { 
     this.Id = id; 
     this.MenuText = text; 
     this.MenuUrl = url; 
     this.ImageUrl = imageUrl; 

     this.Children = new List<MenuItem>(); 
    } 
}

來源

2012-02-23 11:43:46 Richard

lol，我沒有真實地複製您的代碼:) +1有相同的猜測我做了評論者神祕更好的設計。 – 2012-02-23 11:49:29

審閱者沒有幫助或專業。雖然有禮貌，但你需要清楚，這樣的評論是毫無意義的。被問及時，有知識/經驗的人分擔責任。

我認爲你需要查看重命名類型/屬性，例如，提示「MenuItem」作爲基類名稱的答案更清晰。

此外，繼承SubMenu之間的混淆（誤導，因爲你通常從基類或超類取決於你喜歡的術語繼承和做繼承的東西是一個子類），並有一個屬性也稱爲SubMenu和該屬性代表一個集合而不是一個實例。

看菜單的實現如在的WinForms - 他們更容易跟蹤

來源

2012-02-23 11:58:38 kaj

我的課有什麼問題？

回答

相關問題