什么'；我的课错了

本文关键字：错了 我的 什么 | 更新日期: 2023-09-27 18:25:44

提交了这两个类（以及业务逻辑和数据访问逻辑）以供代码审查。评审员看着代码笑了，并建议我重新上课。他让我做一些调查，不给我任何线索。我没有发现任何错误。"子菜单"是基类而不是菜单，这看起来有点尴尬。但我的要求是。菜单只有两个级别（子菜单将永远不存在）。他们有什么好笑的？如果有人向我展示改进这些课程的途径，我将不胜感激。

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

什么'；我的课错了

这里最大的问题是审查人员的专业性——你应该要求他们更具建设性和帮助性，如果他们仍然坚持如此粗鲁，我会把它交给经理。

也就是说，我猜他们在你的设计中看到的是你在使用继承。你这里需要遗产吗？看起来，拥有一个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; }
}

对象的整体构造很好，比如懒惰实例化，尽管正如其他答案所暗示的那样，我认为您的继承有点漏洞百出；但这不是问题！

以下是一些建议；尽管只需要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>();
    }
}

我同意上述评论。对于你的评论者来说，只是大笑而不提供建设性的建议既粗鲁又适得其反。我的回答是"回去，先从评审员那里获得专业的建设性建议"。如果这还没有实现，那么我担心审查者似乎是由自我驱动的，而不是管理以及指导和教育的原则。

考虑到您的需求，我发现唯一错误的是命名问题：

public List<SubMenu> SubMenu

这是一个集合，应该是复数。但说真的，这没什么好笑的。。

现在，如果你回到你的******e评审员那里，准备好你的论点：

  • 继承加上集合是必要的，因为菜单本身就是子菜单，因为菜单有一个Text/Url/Image/ID，并且它有一个属于它的子菜单集合。

  • 解释SubMenu是Menu基类的要求（实际上并不是那么简单）。

我最好的猜测是，这一切看起来有点愚蠢，他只看了一眼

提交了这两个类（以及业务逻辑和数据访问逻辑）以供代码审查。评审员看着代码笑了，并建议我重新上课。他让我做一些调查，不给我任何线索。

糟糕的评论，让你查找它真的没有意义，尤其是如果你真的在自己的代码中没有发现任何错误。

我没有发现任何错误。"子菜单"是基类而不是菜单，这看起来有点尴尬。但我的要求是。。。菜单只有两个级别（子菜单将永远不存在）。

我不觉得你的实现很有趣，但有一种天真的想法，比如"从不"，这有点有趣。如果每次有人说什么永远不会发生，而事情最终真的发生了，我就有一便士，那么到目前为止，我至少会多出15便士。

如果您的需求是菜单只有两个级别，那么不要构建代码来扩展该需求。然而，如果您可以很容易地将代码开放给未来的扩展，那么为什么不这样做呢？没有成本，只有效益。就你的情况而言，我认为"向未来扩展开放"确实很简单。

他们有什么好笑的？如果有人向我展示改进这些课程的途径，我将不胜感激。

这不一定很有趣，也不一定是错误的。不过，我会采取不同的做法：如果菜单可以包含菜单，那不是合成吗？如果是，菜单和子菜单之间有什么区别？子菜单是一个碰巧有父菜单的菜单，但它应该关心吗？它应该知道吗？它真的有什么不同于菜单本身的行为吗？

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

这可能就是我尝试的样子。

审查员没有帮助或专业。在礼貌的同时，你需要清楚这样的评论是毫无意义的。这是那些有知识/经验的人在被要求时分享的责任。

我认为您需要考虑重命名类型/属性，例如建议将"MenuItem"作为基类名称的答案更清楚。

此外，从SubMenu继承（具有误导性，因为根据您喜欢的术语，您通常从基类或超类继承，而进行继承的是一个子类）和具有一个也称为SubMenu的属性（该属性表示一个集合而不是一个实例）之间的混淆。

看看菜单实现，例如winforms中的菜单实现-它们更容易遵循

我不确定下面的语句是否正确（如果我错了，请纠正我），但如果一个类从基类继承，派生类应该保存其基类的项列表吗？在什么情况下，这会有用（我现在想不出任何有用的）。例如，如果我想到"马"answers"动物"："马"类应该有动物列表吗？听起来有点奇怪。。

1） "简单菜单项"（Id、Text、url、image）
2） 另一个菜单（子菜单）

我知道你只想深入一个层次，但实际上重用通用解决方案可能更简单。

复合设计模式（http://en.wikipedia.org/wiki/Composite_pattern）似乎很合适。

hth，
阿兰。

相关文章：