Enumeration and Class

[shapper]

Hello,

I have the following object:

// Asset
public class Asset {
public Guid Id { get; set; }
public String Content { get; set; }
public DateTime? Created { get; set; }
public Boolean? Locked { get; set; }
public String Name { get; set; }
public Priority Priority { get; set; }
public DateTime? Updated { get; set; }
} // Asset

Priority is an enumeration with High, Normal and Low values.
It is only used by Asset.

Should I create an enumeration named Priority inside Asset class or
create an enumeration outside Asset class but inside the same
namespace named AssetPriority.

I always have this dilema ...

What would you suggest me?

Thanks,
Miguel

 

[Jeroen Mostert]

I have the following object:

// Asset
public class Asset {
public Guid Id { get; set; }
public String Content { get; set; }
public DateTime? Created { get; set; }
public Boolean? Locked { get; set; }
public String Name { get; set; }
public Priority Priority { get; set; }
public DateTime? Updated { get; set; }
} // Asset

Priority is an enumeration with High, Normal and Low values.
It is only used by Asset.

Should I create an enumeration named Priority inside Asset class or
create an enumeration outside Asset class but inside the same namespace
named AssetPriority.

I always have this dilema ...

You sound like the kind of person who would enjoy this book:
http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321545613/

It talks about this and many other design issues that might crop up, with
sound justifications.

This particular issue is discussed, and you can read it online:
http://www.informit.com/articles/article.aspx?p=423349&seqNum=9

The conclusion to take away from that is that there are very few justifiable
uses for public nested types, enumerators being one of them, enums almost
certainly not qualifying.

 

[Ignacio Machin ( .NET/ C# MVP )]

Hello,

I have the following object:

  // Asset
  public class Asset {
    public Guid Id { get; set; }
    public String Content { get; set; }
    public DateTime? Created { get; set; }
    public Boolean? Locked { get; set; }
    public String Name { get; set; }
    public Priority Priority { get; set; }
    public DateTime? Updated { get; set; }
  } // Asset

Priority is an enumeration with High, Normal and Low values.
It is only used by Asset.

Should I create an enumeration named Priority inside Asset class or
create an enumeration outside Asset class but inside the same
namespace named AssetPriority.

I always have this dilema ...

What would you suggest me?

Thanks,
Miguel

Hi,
It could be argue both ways, in the framework the enums are not nested
so I tend to follow that pattern.

 

[shapper]

[...]
Priority is an enumeration with High, Normal and Low values.
It is only used by Asset.

Should I create an enumeration named Priority inside Asset class or
create an enumeration outside Asset class but inside the same
namespace named AssetPriority.

I always have this dilema ...

What would you suggest me?

That you need to get off the fence?  

Seriously though, it's not always clear what the right answer will be.  My  
general rule of thumb: nested types are for things used specifically as  
part of the proper operation of the containing class.  Unfortunately, life  
isn't black and white, and it can be hard to decide whether something is  
really "part of the proper operation" or just some related type.

For nested classes, often a determining factor is the degree of coupling  
to the outer class.  But enumerations are so simple, it can be hard to  
decide what the degree of coupling is.

My general preference is to avoid nested types if I can.  The biggest  
advantage to using a nested type for an enumeration is, IMHO, that it  
becomes part of the outer class and so further qualifies the type name.  
But, if you're sure you won't have other classes similar to "Asset" in the  
same namespace that will need a "Priority" enumeration that is different  
 from the one used by "Asset", or (even better) if in the event a class 
similar to "Asset" is created it would be able to reuse the "Priority"  
enumeration used by "Asset", then I think a non-nested type is much better.

Which is all a long way of saying that, absent any other information about  
the situation, I'd say to make "Priority" a non-nested type.

Pete

Thank You Peter. I usually go for not nested.
I wasn't just sure about this case in particular but I am going for no
nested enum to.

Thanks.
Miguel

 

[shapper]

You sound like the kind of person who would enjoy this book:http://www.amazon.com/Framework-Design-Guidelines-Conventions-Develop...

It talks about this and many other design issues that might crop up, with
sound justifications.

This particular issue is discussed, and you can read it online:http://www..informit.com/articles/article.aspx?p=423349&seqNum=9

The conclusion to take away from that is that there are very few justifiable
uses for public nested types, enumerators being one of them, enums almost
certainly not qualifying.

Thank you for both urls. I didn't know that book. It seems useful.

Thanks,
Miguel