我的課有什么問題？

Question

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

[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; }
}

Answer 1

這里最大的問題是誰做了你的評論的專業性 - 你應該要求他們更有建設性和幫助，如果他們仍然堅持如此粗魯，我會把它帶到經理。

---

也就是說，我對你在設計中所看到的東西的猜測是你正在使用繼承。 你需要繼承嗎？ 似乎你可以通過一個Menu類來更好地服務，它包含一個沒有父子關系的SubMenus列表， 或者只是一個可以包含自身列表的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; }
} 

Answer 2

你的對象的整體結構是好的，比如懶惰的實例化，雖然正如其他答案所暗示的那樣，我認為你的繼承有點錯過領先; 但這不是問題！

以下是一些建議; 盡管只需要1級深度，但我建議實現更多級別的可用性，因為它並不過分困難，並且可以在將來為您節省時間。 另外，我們可以在對象中添加幾個構造函數，以便在創建新菜單項時更容易。

我已經創建了一個菜單項的概念，這純粹是一個建議，但希望它有所幫助。 以下是一些需要注意的事項。

1. 我刪除了基礎對象
2. 菜單項現在更長時間使用延遲實例化，但在構造時創建列表
3. 有新的構造函數
4. 菜單項可以是無限級別。

這是它的樣子：

[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>();
    }
}

Answer 3

我同意上述評論員的觀點。 讓你的評論者只是笑而不提供任何建設性的建議既粗魯又適得其反。 我的回答是“ 先回去並從評論者那里獲得專業的建設性建議 ”。 如果那不是即將到來的，那么我擔心審稿人會被自我驅使，而不是管家和指導和教育的原則。

Answer 4

考慮到您的要求，我唯一發現錯誤的是命名問題：

public List<SubMenu> SubMenu

這是一個集合，它應該是復數。 但說真的，沒什么可笑的。

現在，如果你回到你的******評論家，准備你的論點：

• 繼承PLUS集合是必要的，因為菜單本身就是一個SubMenu，因為菜單有一個Text / Url / Image / ID，並且它有一個子集的集合在他下面。

• 解釋SubMenu是Menu的基類的要求（實際上並不那么直截了當）。

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

Answer 5

提交這兩個類（以及業務邏輯和數據訪問邏輯）以進行代碼審查。 審稿人笑着看着代碼並建議我重新上課。 他告訴我做一些研究，不會給我任何線索。

糟糕的評論，讓你查找它是沒有意義的，特別是如果你真的沒有在你自己的代碼中看到任何錯誤。

我找不到任何錯誤。 “子菜單”是基類而不是菜單看起來有點尷尬。 但我的要求就是......菜單只有兩個級別（子菜單永遠不會存在）。

我沒有發現你的實現有趣，但是天真雖然有像“從不”這樣的東西有點搞笑。 如果每次有人說某件事情永遠不會發生，並且最終確實發生的事情，我就有一分錢，那么我現在至少要有15便士。

如果您的要求是菜單只有兩個級別，請不要構建代碼以擴展該要求。 但是，如果您可以選擇非常輕松地打開代碼以便將來擴展，那么為什么不這樣做呢？ 沒有成本，只是受益。 在你的情況下，我認為“開放未來的擴展”確實很簡單。

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

這不一定有趣，也不錯。 我會做不同的事情：如果一個菜單可以包含一個菜單，那不是那個組合嗎？ 如果是這樣，菜單和子菜單之間有什么區別？ 子菜單是恰好有父母的菜單，但它應該關心嗎？ 它應該知道嗎？ 它實際上與菜單本身有什么不同的行為嗎？

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

這可能就是我的嘗試。

Answer 6

審稿人沒有幫助或專業。 雖然彬彬有禮，但你需要明確這樣的評論是毫無意義的。 當被問及時，有知識/經驗的人有責任分享。

我認為您需要查看重命名類型/屬性，例如建議“MenuItem”作為基類名稱的答案更清晰。

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

查看菜單實現，例如winforms - 它們更容易理解

Answer 7

我不確定我是否正確使用以下語句（如果我錯了，請糾正我）但是如果一個類繼承自基類，派生類是否應該保存其基類的項列表？ 在什么情況下這可能是有用的（我現在想不到任何東西）。 如果我想到，例如，“馬”和“動物”：馬匹應該列出動物名單嗎？ 聽起來有點奇怪..

Answer 8

看來你有一個菜單，可以包含兩種類型的項目

1）'簡單菜單項'（Id，Text，url，image）
2）另一個菜單（子菜單）

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

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

心連心，
艾倫。