[Anthonidas]

Thank you

last question, and perhaps a stupid one, but I prefer to ask it and understand it 100%, than playing with the doubt. There is no difference, if I define the "call"-Class inside or outside the KdStats, isn't there?

Quote from baavgai's post:

baavgai, on 20 January 2013 - 04:22 PM, said:

class KdCustomer {
	public int CustomerNumber { get; set; }
	public string Name { get; set; }
	public class Call {
		public DateTime StartTime { get; set; }
		public int DurationInSeconds{ get; set; }
	}
	public List<Call> Calls { get; set; }
}

[andrewsw]

From my limited experience (and someone may correct me) it is sometimes possible to use either construct. I would create a nested class if it has no utility outside of its containing class. That is, if a Call cannot exist independently of a Customer.

I believe, though, that nested-classes are more usually private or protected, rather than public. Added: If Call is private then you would need to create methods on Customer that enable Call's to be created and managed outside the class, as they would not be directly accessible.

This post has been edited by andrewsw: 21 January 2013 - 07:11 AM

[andrewsw]

An example

If you keep everything public:

class KdCustomer {
    public int CustomerNumber { get; set; }
    public string Name { get; set; }
    public class Call {
        public DateTime StartTime { get; set; }
        public int DurationInSeconds { get; set; }
    }
    public List<Call> Calls = new List<Call>();
}

KdCustomer matey = new KdCustomer();
matey.Calls.Add(new KdCustomer.Call { StartTime = DateTime.Now, DurationInSeconds = 200 });

foreach (KdCustomer.Call aCall in matey.Calls) {
    Console.WriteLine(aCall.DurationInSeconds.ToString() + " " + aCall.StartTime.ToString());
}

This post has been edited by andrewsw: 21 January 2013 - 07:33 AM

[Anthonidas]

Thanks a lot! (uuuh I bet you all never got so much +1's! )

[CodingSup3rnatur@l-360]

Quote

However, I am a bit confused now if I should use classes or structures.

You should just use classes.

Quote

I might still use structures occasionally but unless you are aware of the pitfalls then you should avoid them

Definitely. I'd probably add to that that you should also only use them if you have a concrete (preferably tested) reason to do so. If you cannot explain what a struct offers that a class doesn't, and specifically how that benefits you in your situation, what's the point in adding the extra complexity they bring?

For example, a reasonable argument for using a struct could be:

"I have measured that my graphics library is not meeting performance targets in this module, and have conclusively measured that the time taken to allocate memory for all these point objects in these tight loops is the bottleneck, and measurements prove that changing the point object to a struct alleviates this allocation speed problem, and allows performance targets to be met."

Just don't whatever you do, don't blindly use a structure just because of some misguided notion that structs are just lightweight, faster classes. They behave in a fundamentally different way to classes, and should be thought of completely differently. Structures will likely hurt performance if used wrongly. Always confirm with tests before making a performance decision like that.

Quote

After having read the VB.Net article I think classes are every time better than structures, or am I wrong?

Structs have their usage, on occasion.

Here are Microsoft's minimum requirements that should be met before considering using a struct. They serve as a good initial check list when trying to make the decision. Most types won't even pass those initial checks.

Three general uses of structures.

1) To improve performance - If this is the case, measure to verify that you actually have a performance problem. Identify the specific hotspot(s) in your code, and then verify that structs actually solve the problem.

2) You are modeling a conceptually single value (think integer, complex number, point, vector, color, etc) - In this case, you simply see benefits in the value semantics that structs offer vs classes. That's fine, structs are designed to be suited to modeling logically singular values (although the need to model such values yourself doesn't tend to come up that often). However, at least ensure Microsoft's guidelines in the link above have been met before committing to the change.

3) Interop with unmanaged code, like the WinAPI - C# structs tend to be more closely aligned to C structs than C# classes do, it therefore may be easier to use structs over classes in certain WinAPI interop scenarios, for example.

Conclusion

I think using structs for types that don't actually model a conceptually single value, and/or using mutable structs, is where things will start going down hill quickly in terms of the understandability, intuitiveness and maintainability of your code.

The bottom line is, classes should always be your default, and structs shouldn't usually even enter your head.

This post has been edited by CodingSup3rnatur@l-360: 21 January 2013 - 09:04 AM

[Anthonidas]

this one clarified everything! thank you again.