CODEWITHSUNDEEP
c#architectureclass-design
ahsteele
ahsteele

Reputation: 26494

Class Design C# Namespace Separation

I am still trying to workout separation of function and how it applies to class creation and namespace inclusion. I have a custom class SoftwareComponent which when presented to the user will most often appear as a ListItem. Is creating a ToListItem method a good idea? I worry because I have now placed a dependency in the class which will require the inclusion of the System.Web.UI.WebControls namespace.

    public ListItem ToListItem()
    {
        ListItem li = new ListItem();
        li.Text = ComponentName + " (+" + ComponentCost + ")";
        li.Selected = Selected;

        return li;
    }

My other inclination is to create a ListItem from the SoftwareComponent based on its properties outside of the class itself. Please provide any thoughts on which approach is more appropriate/better.

Upvotes: 0

Views: 1007

Answers (3)

Jeff Yates
Jeff Yates

Reputation: 62367

Could you not provide this additional method as an extension method? It seems to be better suited to being part of a utility class that can be included as a choice by creating a static method that provides this functionality rather than providing it on the main class as a first class method.

public static class SoftwareComponentExtensions
{
    public static ListItem ToListItem(this SoftwareComponent component)
    {
        ListItem li = new ListItem(component.ComponentName + " (+" + component.ComponentCost + ")");
        li.Selected = component.Selected;

        return li;
    }
}

Upvotes: 5

user60229
user60229

Reputation:

It sounds like SoftwareComponent is a domain object - an object that describes a "thing" in the world your application speaks in.

I try to avoid making those domain objects depend on anything outside the domain - this could be the lower level (how is it stored? Is it serialized? Stored in a database) or at the UI level.

I agree that it is difficult to do so, quite often you end up with separate hierarchies of classes to manage - ui classes, database mappings and so on. So depending on the size of the thing you build it is a tradeoff to include UI or database code in the domain objects or to keep stuff out.

For the specific problem you've got have a look at C#3.5 extension methods. They are a sleight of hand of making static methods look like they are defined within a class -- as long as they don't access private/protected stuff (they only can access public methods like any other method) you can get away with them. I use them for stuff like you want to do (UI-Level "methods" for domain objects) that are defined elsewhere, however.

But keep in mind, extension methods are nothing but syntactic sugar for you good old static methods in a static class.

Upvotes: 1

itsmatt
itsmatt

Reputation: 31406

I wouldn't have SoftwareComponent know about ListItems and such. Obviously, somebody has to know how to take a SoftwareComponent and jam its pieces into a ListItem, but I think that isn't the concern of the SoftwareComponent.

Ask yourself if you would add a new ToXYZ() method each time you needed to have it work for another UI element or construct some new class from its properties. Not likely, I'd guess.

Upvotes: 1

Related Questions