Enumeration and Class

  • Thread starter Thread starter shapper
  • Start date Start date
S

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
 
shapper said:
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 ...
Click to expand...

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.
 
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
Click to expand...

Hi,
It could be argue both ways, in the framework the enums are not nested
so I tend to follow that pattern.
 
[...]
Priority is an enumeration with High, Normal and Low values.
It is only used by Asset.
Click to expand...
Should I create an enumeration named Priority inside Asset class or
create an enumeration outside Asset class but inside the same
namespace named AssetPriority.
Click to expand...
I always have this dilema ...
Click to expand...
What would you suggest me?
Click to expand...

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
Click to expand...

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
 
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.
Click to expand...

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

Thanks,
Miguel
 
Back
Top