Topic: Creating a simple class, what is the right way?

[Viktor]

Ok, this is the part of OOP i still find a bit hard to comprehend, simply because i haven't heard a reason why do it one way vs another way, could also be cause I haven't looked hard enough. Anyway, lets say I want a simple "person" class with first and last name properties. I can do it simply like this:

Code: [Select]

Public Class RuleViolation
    Public FirstName As String
    Public LastName As String

    Public Sub New(ByVal _FirstName As String, ByVal _LastName As String)
        FirstName = _FirstName
        LastName = _LastName
End Sub
End Class

Or you can do it by using Get/Set Properties. But what's the difference? Why is above not good? and where does it fail?

Thanks,
Viktor.

[sinc]

There's nothing particularly wrong with that.

The only thing I see with that is that Microsoft recommends that you do not use identifiers that start with underscores.  It has to do with the fact that that .NET languages get compiled to MSIL, and MSIL can be decompiled to any .NET languages, and one or more of the languages doesn't like identifiers to start with an underscore.  If you are only working in VB, then you may not particularly care about this.  But I thought I 'd mention it.

The get/set properties are merely a coding convenience.  They are also designed with encapsulation rules in mind.  For example, I frequently use something like this:

Code: [Select]

public string SomeValue { get; private set; }
This construct allows the class itself to set and get SomeValue, but other classes can only read the value of SomeValue, and cannot set it.  It is basically the equivalent of this:

Code: [Select]

private string m_SomeValue;
public string GetSomeValue()
{ return m_SomeValue; }


[Bobby C. Jones]

I tend to prefer properties over fields.  With properties you can validate the data, properties can be read-only, & even write-only if so desired, and fields do not work with databinding, just to name a few.  The debate, however, is far from closed.

http://www.google.com/search?q=fields+vs.+properties&btnG.x=13&btnG.y=16

[Viktor]

Thanks guys, and I guess I have just stumbled over another debate... Fun fun. ok.

[It's Alive!]

encapsulation

[sinc]

I don't think this is really a big topic of debate.  Or if it is, it's being debated in circles I don't hang in.

The general rules of Object Oriented Programming encourage the use of Properties in C#.  And Data Binding needs Properties.  Some people like to just use a public field instead, because it might involve a bit less typing, and if you aren't doing anything in your accessors or using Data Binding, you can argue that they are really unnecessary.  And if you start out using Fields, you can convert them to Properties relatively easily if you need to.

So from a practical point of view, it generally doesn't make a lot of difference.  But I usually prefer Properties, as they are more in-line with the guidelines of OOP.

[MP]

Just to add to the conversation ... if you want to have a "simple class with public properties/fields" you might consider using a structure instead of a class. Really depends upon the intended use/clients of the structure/class.

[sinc]

Just keep in mind that classes are reference types, while structs are value types.

Reference types can have null values; value types cannot.  When used as arguments, a copy of a value type is passed, but only a reference is passed to a reference type.

If you want something that stores data, then a struct may be more efficient.  However, structs are not polymorphic, and you cannot define subcategories of structs, the way you can derive subclasses from classes.

There are some other differences.  I found this, which may be useful for understanding the differences:

http://ptgmedia.pearsoncmg.com/images/0321245660/items/wagner_item6.pdf