public static Menu BuildMenu()
{
    var menu =
        new Menu()
            .AddItem("Products", new Menu()
                .AddItem("Hardware", new Menu()
                    .AddItem("Computers")
                    .AddItem("Printers"))
                .AddItem("Software"))
            .AddItem("Services", new Menu()
                .AddItem("Consulting")
                .AddItem("On-Site Support"))
            .AddItem("Support")
            .AddItem("Contact");

    return menu;
}

public static Menu BuildMenu(){    var menu = new Menu() .AddItem(“Products”, new Menu() .AddItem(“Hardware”, new Menu() .AddItem(“Computers”) .AddItem(“Printers”)) .AddItem(“Software”)) .AddItem(“Services”, new Menu() .AddItem(“Consulting”) .AddItem(“On-Site Support”)) .AddItem(“Support”) .AddItem(“Contact”);    return menu;}

It’s basically the same as the original solution, but instead of params MenuItem[] menuItems in the constructor, there is an overload for AddItem that takes a single Menu object as the last parameter in case of a submenu.

The indentation makes it easy to read, but the new Menu() initializers add some noise.

My two object oriented cents

Collection initializer is definitely another option. Do you find it easier to read? Personally, the brackets seem to add more distractions than purely constructors/builder methods.

public static MenuItem BuildMenu()
{
var menu = new Menu()
{
new MenuItem(“Products”)
{
new MenuItem(“Hardware”)
{
new MenuItem(“Computers”),
new MenuItem(“Printers”)
},
new MenuItem(“Software”)
},
new MenuItem(“Services”)
{
new MenuItem(“Consulting”),
new MenuItem(“On-Site Support”)
},
new MenuItem(“Support”),
new MenuItem(“Contact”)
};

return menu;
}

You’d just need to change your AddItem method to Add, and make sure the class supports IEnumerable:

public class MenuItem : IEnumerable
{
private readonly List _menuItems = new List ();

public MenuItem(string title)
{
Title = title;
}

public string Title
{
get;
set;
}

public void Add(MenuItem menuItem)
{
_menuItems.Add(menuItem);
}

public IEnumerator GetEnumerator()
{
return _menuItems.GetEnumerator();
}

IEnumerator IEnumerable.GetEnumerator()
{
return GetEnumerator();
}
} ]]> http://lostechies.com/jimmybogard/2008/10/15/fluent-hierarchical-construction/#comment-956 Jimmy Bogard Thu, 16 Oct 2008 22:21:26 +0000 /blogs/jimmy_bogard/archive/2008/10/15/fluent-hierarchical-construction.aspx#comment-956 @Different view Yes, this would _usually_ be put in the database. But there are cases where I need to define hierarchies that shouldn't be in the database. This really wasn't about menu items, rather building hierarchies. In our case, each menu item represents new code. Since code and menus are tightly coupled, no point in putting them in the DB, as it would be more work to re-correlate them with specific view pages/controller actions. @Different view

Yes, this would _usually_ be put in the database. But there are cases where I need to define hierarchies that shouldn’t be in the database. This really wasn’t about menu items, rather building hierarchies.

In our case, each menu item represents new code. Since code and menus are tightly coupled, no point in putting them in the DB, as it would be more work to re-correlate them with specific view pages/controller actions.

Yes it’s readable, however it has very few benefits over simply writing straight HTML… you’re procedurally defining the options and there is no persistent queryable structure to build on in the future.

To create a re-usable menu structure of arbitrary depth, I usually pull it from a table like this (MySQL semantics but you get the drift):

create table menu_items(
id int unsigned not null auto_increment primary key,
parent_id int unsigned
);

alter table menu_items add foreign key(parent_id) references menu_items(id) on delete set null on update cascade;

Then create a different table to hold titles, which may potentially be multilingual…

create table menu_item_names(
id int unsigned not null auto_increment primary key,
item int unsigned not null,
name tinytext not null,
language int unsigned not null
);

alter table menu_item_names add foreign key(language) references languages(id) on delete cascade on update cascade;
alter table menu_item_names add foreign key(item) references menu_items(id) on delete cascade on update cascade;

Just a different way to accomplish the same thing … but more extensible / persistent (ie: tightly database-coupled, and therefore easier to build a simple interface for and delegate management to users…).

It’s partly a different outlook – to me, these days, one-off code is just too hard to maintain, I tend to put the extra time in up front for peace of mind and re-usability.

Why does “With” need to prefix what are essentially operations that describe structure? That stuff is mostly noise.

I think it’s valuable to question when building fluent interfaces whether we are cognizant of whether we’re trying to create domain-specific languages, or English. if we’re trying to create English, and we believe that English is what makes program code readable, we’re likely off-target.

public static Menu BuildMenu()
{
var menu =
new Menu().
WithSubMenu(“Products”).
WithSubMenu(“Hardware”).
WithItem(“Computers”).
WithItem(“Printers”).
End().
WithItem(“Software”).
End().
WithSubMenu(“Services”).
WithItem(“Consulting”).
WithItem(“On-Site Support”).
End().
WithItem(“Support”).
WithItem(“Contact”);

return menu;
}

The examples tagged with “fluent” that i have seen floating around the blogosphere all seem to expose an API that leans on chaining (returning some helper object), reads like English, and provides contextual intellisense as you build your expression.

In the above example, i’d probably execute as an extension method on MenuItem that operates on it’s collection and returns the updated MenuItem. Hmmm, how to handle the submenu chaining? perhaps returning an intermediate helper object to ensure that the return type would notify you if you had forgotten an End()