We Keep Coding

How to avoid using "Object" as variable type

I'm implementing a dictionary in the following way to accommodate for an integer "key" and a Decimal/DateTime/String "value":
Dictionary<int, object>
However I recognize that setting the type of the "value" to "object" is not the safest approach. Do you have any suggestions for a better implementation?

I think your concern might be at the wrong level. object probably is the right option for you if you want to store all those types of data in the same collection, but you're right to have concern.
Writing strongly typed code has a lot of advantages, because many of the checks will occur at compile time, rather than runtime. That means a lot of errors will be readily visible, rather than coming up during testing (which may or may not actually catch them the first time around). By storing three types of very different data in the same collection, you're inherently going to be losing the advantages of that strong-typing. That's why you don't want to use object for this, and by definition, any alternative solution that accomplishes the same feat will carry the same risks.
Rather, I'd say you have a couple of more reasonable options.
You could reconsider what you're storing. Are you sure you need these three types of data in the same place? Maybe you'd be better off with three separate dictionaries, each with the correct type information. It's not often we want to compare a string and an int anyway, they're generally used in radically different ways.
You could write a class that wraps the types. Have three properties, one for each type, then store some sort of null indicator in the empty ones. This still isn't a great solution, but it's better than object.
You could investigate generics, and write a class with a single property to store the value, with a function to do something with it, and have that value typed as a generic type parameter T.
Storing it as an object, as you say, will work, but I'd say you'd definitely be better off to come up with a better alternative. It's hard to really tell you what to do, though, because we don't know a lot about what specifically you're doing.

If you want to have different types in your generic collection, your generic type must be object.
Now, it could indicate a greater problem with your architecture. Take a step back and think about it. Maybe it would be better to have 3 dictionaries instead of one (a Dictionary<int,decimal>, a Dictionary<int,DateTime> and a Dictionary<int,string>).
Or maybe you can create your own class that will encapsulate your values.
public class Wrapper
{
public Wrapper(decimal d)
{
//...
}
public Wrapper(DateTime date)
{
//...
}
public Wrapper(string s)
{
//...
}
}
and then use a Dictionary<int,Wrapper>. The good way really dépends on what your are trying to achieve. Having your generic type be object is often a symptom of a bad architectural decision at some point.

Variable should have single use! Therefor instead :
var itemsObject = default(Dictionary<int, object>);
You should have
var itemsString = default(Dictionary<int, string>);
var itemsDecimal = default(Dictionary<int, Decimal>);
var itemsDateTime = default(Dictionary<int, DateTime>);
It is not duplication of code. If code is not used differently by type, then you could simply use itemsString.

Is it less 'expensive' to pass the field of an object as opposed to the whole object itself?

Consider the following class:
public class Person
{
public String FirstName;
public String LastName;
public DateTime DateOfBirth;
public StaffType PersonType;
}
And the following 2 methods and method calls:
public void DoSomethingWithPersonType(Person person)
{
TestMethod(person.PersonType);
}
(called by DoSomethingWithPersonType(person);)
public void DoSomethingWithPersonType(StaffType personType)
{
TestMethod(personType)
}
(called by DoSomethingPersonType(person.PersonType);).
Which method is more efficient? Are they both as 'efficient' as each other? Does it make no difference because it's only one reference passed in anyway? Or does the reference passed differ in some way?
The reason I ask is because I've opted for the first method signature in a current project - and I've done it because at a later date we may need to use other fields of our 'person' - so a more easily scalable/adaptable method is what I've got - but is it a more expensive one?
EDIT: Note - it goes without saying that these differences will be marginal, otherwise I would've already encountered scenarios were the performance implications are evident enough for me to act on. It's simply a matter of curiosity.

Performance wise they will be identical. In both cases you are passing a single reference (which has the same performance cost) and in both cases you're getting the PersonType object out of one of the fields.
The only difference here is in terms of code readability/maintainability, etc. In general, it's best for methods to only accept what information they need. If you only need a PersonType then only accept a PersonType. It allows that method to be used more flexibly. (What if something other than a Person has a PersonType?) If you think you'll actually need more than just the person type than accepting a Person may be appropriate.
Also note that even if there is a difference here, it would most certainly be tiny. You shouldn't think about every little think in terms of how expensive it is to run. Computers are fast these days. Even poor algorithms tend to take little time to run in practice (from the point of view of a person). If you get to the point where your program is taking longer to run than it needs to, then it's time to start looking for places to improve. You should focus on those areas of the code (identified with a profiler) as being a significant percentage of the processor time. Network communication (including database calls), and other IO tend to be good targets for optimizations.
Also note that it's generally considered bad practice to have public fields. At the very least, you should probably have public properties instead.

Whatever you decide to pass to the method performance implications will depend on context. If you pass parameters between methods in the same class performance implication will be immeasurably small, if you call a method over RMI it is a different matter

That depends somewhat on the type of StaffType, but normally the performance difference is negligible.
If StaffType if a class, then there isn't any difference, as both are references. If it's an enum then it would be marginally faster to pass a StaffType value than a reference.
(If StaffType is a large struct, then it would be slower to pass, but then the actual problem is a badly designed struct, not how you use it.)
So, you should use the one that makes most sense. Usually you should send as little information as possible, just to make it easier to see what the method actually uses. Whether you should send the StaffType value or the entire Person object for future possible expansion is hard to tell, but consider the YAGNI principle - You Ain't Gonna Need It.

Presumably, StaffType is an enum. In this case, it should be marginally more efficient than passing an object reference, the enum will create less work for garbage collection.
But any difference will be negligible, I would rate extensibility as far more important in this case.

Speaking of efficiency, they are equal becuase in both cases you'll pass a reference (speaking of two classes, else if StaffType is a struct the second one will be slower). But in terms of Best Coding Practices, it depends on what do you want to do. If you don't need any other property from the Person class you should use the second one, because you should pass less information as possible, but if you have to work more on the person object, you should use the first solution.
But you have to think to the re-usability of the method and your framework, let's say you need to use this method not only for the Person type but you also need it for another "type" you'll have to rewrite another method for it, and the aim of object oriented programming, which is code less, will disappear.

List of const int instead of enum

I started working on a large c# code base and found the use of a static class with several const ints fields. This class is acting exactly like an enum would.
I would like to convert the class to an actual enum, but the powers that be said no. The main reason I would like to convert it is so that I could have the enum as the data type instead of int. This would help a lot with readability.
Is there any reason to not use enums and to use const ints instead?
This is currently how the code is:
public int FieldA { get; set; }
public int FieldB { get; set; }
public static class Ids
{
public const int ItemA = 1;
public const int ItemB = 2;
public const int ItemC = 3;
public const int ItemD = 4;
public const int ItemE = 5;
public const int ItemF = 6;
}
However, I think it should be the following instead:
public Ids FieldA { get; set; }
public Ids FieldB { get; set; }

I think many of the answers here ignore the implications of the semantics of enums.
You should consider using an enum when the entire set of all valid values (Ids) is known in advance, and is small enough to be declared in program code.
You should consider using an int when the set of known values is a subset of all the possible values - and the code only needs to be aware of this subset.
With regards to refactoring - when time and business contraints allow, it's a good idea to clean code up when the new design/implementation has clear benefit over the previous implementation and where the risk is well understood. In situations where the benefit is low or the risk is high (or both) it may be better to take the position of "do no harm" rather than "continuously improve". Only you are in a position to judge which case applies to your situation.
By the way, a case where neither enums or constant ints are necessarily a good idea is when the IDs represent the identifiers of records in an external store (like a database). It's often risky to hardcode such IDs in the program logic, as these values may actually be different in different environments (eg. Test, Dev, Production, etc). In such cases, loading the values at runtime may be a more appropriate solution.

Your suggested solution looks elegant, but won't work as it stands, as you can't use instances of a static type. It's a bit trickier than that to emulate an enum.
There are a few possible reasons for choosing enum or const-int for the implementation, though I can't think of many strong ones for the actual example you've posted - on the face of it, it seems an ideal candidate for an enum.
A few ideas that spring to mind are:
Enums
They provide type-safety. You can't pass any old number where an enum value is required.
Values can be autogenerated
You can use reflection to easily convert between the 'values' and 'names'
You can easily enumerate the values in an enum in a loop, and then if you add new enum members the loop will automatically take them into account.
You can insert new enunm values without worrying about clashes occurring if you accidentally repeat a value.
const-ints
If you don't understand how to use enums (e.g. not knowing how to change the underlying data type of an enum, or how to set explicit values for enum values, or how to assign the same value to mulitple constants) you might mistakenly believe you're achieving something you can't use an enum for, by using a const.
If you're used to other languages you may just naturally approach the problem with consts, not realising that a better solution exists.
You can derive from classes to extend them, but annoyingly you can't derive a new enum from an existing one (which would be a really useful feature). Potentially you could therefore use a class (but not the one i your example!) to achieve an "extendable enum".
You can pass ints around easily. Using an enum may require you to be constantly casting (e.g.) data you receive from a database to and from the enumerated type. What you lose in type-safety you gain in convenience. At least until you pass the wrong number somewhere... :-)
If you use readonly rather than const, the values are stored in actual memory locations that are read when needed. This allows you to publish constants to another assembly that are read and used at runtime, rather than built into the other assembly, which means that you don't have to recompile the dependant assembly when you change any of the constants in your own assembly. This is an important consideration if you want to be able to patch a large application by just releasing updates for one or two assemblies.
I guess it is a way of making it clearer that the enum values must stay unchanged. With an enum another programmer will just drop in a new value without thinking, but a list of consts makes you stop and think "why is it like this? How do I add a new value safely?". But I'd achieve this by putting explicit values on the enums and adding a clear comment, rather than resorting to consts.
Why should you leave the implementation alone?
The code may well have been written by an idiot who has no good reason for what he did. But changing his code and showing him he's an idiot isn't a smart or helpful move.
There may be a good reason it's like that, and you will break something if you change it (e.g. it may need to be a class due to being accessed through reflection, being exposed through external interfaces, or to stop people easily serializing the values because they'll be broken by the obfuscation system you're using). No end of unnecessary bugs are introduced into systems by people who don't fully understand how something works, especially if they don't know how to test their changes to ensure they haven't broken anything.
The class may be autogenerated by an external tool, so it is the tool you need to fix, not the source code.
There may be a plan to do something more with that class in future (?!)
Even if it's safe to change, you will have to re-test everything that is affected by the change. If the code works as it stands, is the gain worth the pain? When working on legacy systems we will often see existing code of poor quality or just done a way we don't personally like, and we have to accept that it is not cost effective to "fix" it, no matter how much it niggles. Of course, you may also find yourself biting back an "I told you so!" when the const-based implementation fails due to lacking type-safety. But aside from type-safety, the implementation is ultimately no less efficient or effective than an enum.

If it ain't broke, don't fix it.
I don't know the design of the system you're working on, but I suspect that the fields are integers that just happen to have a number of predefined values. That's to say they could, in some future state, contain more than those predefined values. While an enum allows for that scenario (via casting), it implies that only the values the enumeration contains are valid.
Overall, the change is a semantic one but it is unnecessary. Unnecessary changes like this are often a source of bugs, additional test overhead and other headaches with only mild benefits. I say add a comment expressing that this could be an enum and leave it as it is.

Yes, it does help with readability, and no I cannot think of any reason against it.
Using const int is a very common "old school" of programming practice for C++.

The reason I see is that if you want to be loosely coupled with another system that uses the same constants, you avoid being tightly coupled and share the same enum type.
Like in RPC calls or something...

Is there any harm in having many enum values? (many >= 1000)

I have a large list of error messages that my biz code can return based on what's entered. The list may end up with more than a thousand.
I'd like to just enum these all out, using the [Description("")] attribute to record the friendly message.
Something like:
public enum ErrorMessage
{
[Description("A first name is required for users.")]
User_FirstName_Required = 1,
[Description("The first name is too long. It cannot exceed 32 characters.")]
User_FirstName_Length = 2,
...
}
I know enums are primitive types, integers specifically. There shouldn't be any problem with that many integers, right?
Is there something I'm not thinking of? It seems like this should be okay, but I figured I should ask the community before spending the time to do it this way.
Does .Net care about enum types differently when they have lots of values?
Update
The reason I didn't want to use Resources is because
a) I need to be able to reference each unique error message with an integer value. The biz layer services an API, in addition to other things, and a list of integer values has to be returned denoting the errors. I don't believe Resources allows you to address a resource value with an integer. Am I wrong?
b) There are no localization requirements.

I think a design that has 1,000+ values in an enum needs some more thought. Sounds like a "God Enum" anti-pattern will have to be invented for this case.

The main downside I'd point out with having the friendly description in an Attribute is that this will cause challenges if you ever need to localize your app for another language. If this is a consideration, it would be a good idea to put the strings in a resource file.
The enum itself should not be a problem, though having all of your error codes in one master list can be confusing. You may consider creating seperate enums for seperate categories of return codes, as this will make it easier for developers to understand the possible return values for a particular function. You can still give them distinct numeric values (by specifying the numeric values explicitly) if it's important that the codes be unique.
On a side note, the .NET BCL does not make much use of return codes and return codes are somewhat discouraged in modern .NET development. They create maintainability issues (you can almost never remove old return codes or risk breaking backwards compatibility) and they require special validation logic to handle the returns for every call. Stateful validation can be accomplished with IDataErrorInfo, where you use an intermediate class that can represent invalid states, but that only allows a Commit of changes that are validated. This allows you to manipulate the object freely, but also provide feedback to the user as to the validity of its state. The equivalent logic with error codes often requires a switch statement for each use.

1000 is not many, you should just make sure that the underlying integer type is big enough (don't use a char for your enum.
On second thought 1000 is tons if you're manually entering them, if they are generated from some data set it could make sense kinda...

I fully agree with duffymo. An enum with 1000+ values smells bad from y design point of view. Not to mention that it would be quite nasty for the developer to use intelligence on such a GOD ENUM:-)
I would better go for using resources.

I think it's very bad, for error handling you can simply use resource, as i see you want to do reflection and fetch the description its bad too.
If you don't want to use resources, you can define different enum for each of your business rules, Also your different business doesn't need others error message (and shouldn't be like this).

Difference between Property and Method [duplicate]

This question already has answers here:
Exposing Member Objects As Properties or Methods in .NET
(7 answers)
Closed 9 years ago.
Which one is better to use when it come to return value for example
public int EmployeeAge
{
get{return intEmployeeAge};
}
And
public int EmployeeAge()
{
return intEmployeeAge;
}
Which one is better and why? And what is best programming practice to use when we have secnario like above ?

Properties are a useful way of expressing a feature of an object, allowing get/set in a common way that can be used by APIs like data-binding, reflection and serialization. So for simple values of the object, properties are handy. Properties can't take arguments, should not have significant side-effects*, and should return quickly and repeatably. Also, there is no such thing as an "extension property" (to mirror an extension method) nor a generic property.
(*=lazy loading etc isn't uncommon, however)
Methods (C# doesn't have functions) are better for expressing things that either change the state, or which have an expectation of taking some time and not necessarily being reproducible. They don't tend to work in binding / serialization etc.
Note that properties are actually just a special way of writing methods. There is little functional difference. It is all about expressing intent. The one thing you don't want to expose, however, is fields (the actual intEmployeeAge instance variable).
So I would have:
public int EmployeeAge { get{return intEmployeeAge}; }
or just (if on the Employee object):
public int Age { get{return intEmployeeAge}; }
Of course... then the question becomes "in what unit?" I assume that is years?

If all you need to do is return a value, use a property.
If you need to do something before returning a value, use a function.

Properties holds object data
Functions defines object behavior
Take a look at -> Property Usage Guidelines

Which one is better and why? And what is best programming practice to use when we have
secnario like above ?
I write in C# however I prefer to use Get/Set functions, for me it's just better way to express what I can get from object and how I can change it's state (and this methods are grouped by alphabet in Intelisense which is also nice). However, if team prefers other conventions it's not a problem but when I work on my own projects it's just easier to read API.
e.g
Obejct1 o = new Object1();
o.P1;
o.P2;
o.P3;
from looking to API you can't say what you change in a public API or what it a read only property, unless you use IDE that shows you a small icon showing actually what you can do.
Object1 o = new Object1();
o.GetP1();
o.SetP2();
o.SetP3();
One can easily find from API how data can be changed by type's clients.

A method returns values after work is completed and a value is the result of the work being done. I don't think this is what you are doing.
A property (accessor) is meant for returning variables, which seems to be what you're trying to achieve:
As per MSDN:
The accessor of a property contains
the executable statements associated
with getting (reading or computing) or
setting (writing) the property. The
accessor declarations can contain a
get accessor, a set accessor, or both.
The declarations take the following
forms:
public int EmployeeAge
{
get;
set;
}
Have a look here, as it gives a very good description on the uses of these.

Property is a way explore the internal data element of a class in a simple manner. We can implement a properties with the type-safe get and set method.Property is implicitly called using calling convention.Property works on compile and runtime.
Method is a block of code that contain a series of statements.Method is explicitly called.
Methods works on runtime.

I'm a little late to this party, but I'll just mention another surprising difference between a property and a parameterless "get" method. As #MarcGravell notes, lazy loading is a common pattern when using properties, but beware of the Heisenberg Watch Window gotcha!

I think this has a lot to do with the culture you are programming in. As I see it, the C# / .NET culture would prefer to use a property for this case.
My advice: Try to be consistent with the main libraries you are using.
BUT: Be wary of using properties (or functions that serve the same purpose, as in your example above), as they are often a sign of bad design. You want to tell your objects to do stuff, as opposed to asking them for information. Don't be religious about this, though, just be aware of this as a code smell.