tags:

views:

77

answers:

3

Hi

I'm pretty new in OOP but have to develop a big project... Just for imagination, below 2 examples which returns same.

Which one is (more) correct, hmm or cleaner? The Property or the method? In real I have to return complex datasets from joined tables... I avoid copy the complet query which returns the dataset. Thats why it's just an empty here in this example.

Thanks.

public class House
    {
        public static DataSet Windows
        {
            // just for imaging 
            get
            {
                DataSet ds = new DataSet(); // Here would be my data set from sql which returns a windows collection.
                return ds;
            }
            set
            {
                Windows = value;
            }
        }
        public static DataSet GetWindows()
        {
            DataSet ds = new DataSet(); // Gets same right?
            return ds;
        }
    }
+5  A: 

The property is definitely incorrect - the setter will throw a StackOverflowException because it just recurses.

Even the getter is very odd though - properties normally reflect some aspect of the property or type, rather than just creating a new object and forgetting it.

Personally I'd go with:

public static DataSet CreateWindows()
{
    return new DataSet();
}

That gives the correct impression that it's creating something new - GetWindows would imply caching, or that the data set is part of the static state of the type.

If there's a possibility that at a later date you'll want to make it do caching, then GetWindows is reasonable - but I'd then document that it may or may not create a new result each time.

Jon Skeet
but it works with property...
snarebold
why not ... property could also return a DataSet not?... Unless it's empty
snarebold
Yes, a property can return a DataSet - but it's somewhat odd for a property to just create a new object and return it. It's not really a *property* of the type or the object then, is it?
Jon Skeet
+5  A: 

Properties in C# are converted to get/set methods, so technically they are equivalent. However, the framework guidelines recommend that properties should be used for 'simple' operations like field access. Therefore, in your example I'd use the GetWindows method approach since it hints to consumers that it could be a long-running call.

Lee
Thank you. I even like properties :)... Hmm but why the often used "Controls" property is not a method like GetControls().. Behind I think it must be complex to return all Controls ...
snarebold
@snarebold: It returns a controls collection - there's no reason that shouldn't just be a field. However, I wouldn't restrict yourself to *just* field access... just don't go overboard.
Jon Skeet
Ok. Thank you. I understand.. Makes sense
snarebold
+1  A: 

I suggest that, in very general terms, a property is something that an object 'has', and a method is something that the object 'does'. Your House 'has' windows, so using a property to retrieve the windows data set would be correct.

In your code, every time someone accesses the property, a new data set is created - probably not what you want. It is also declared as 'static', which means that any House object that you create would end up with the same set of windows. It seems to me that the data set should be an instance member which gets created in the constructor (or in another appropriate place). Depending on your requirements, of course.

Ray
oh intresting ... thanks... I use static because later I like to create a big class and get over one line its properties and sub classes the specific datasets from cms. goal is to send the datasets to a repeater.I think so because behind in the database there are many relations and this I wanna filter in one dataset.in example: rptRepeater.DataSource = myclass.servicesanother repeater on same pagerptRepater2 = myclass.specialservices.behind the "services method" it collects data from different table.
snarebold