views:

206

answers:

9

Possible Duplicate:
Properties vs Methods

When is it best to use a property or a method?

I have a class which is a logger. When I create this class I pass in a file name.

My file name for the log is fairly simple, basically it just gets the application path and then combines it with myapp.log.

Now instead of having the log file name lines in my method I want to create a new method to get this.

So my question is, since it's fairly simple, is creating a property a good idea instead of creating a method since there are no parameters.


Duplicate http://stackoverflow.com/questions/601621/properties-vs-methods

A: 

Properties can be used to return simple values. Methods should always been used when fetching the value might incur any kind of performance hit. Simple linear operations can be fine in properties, though.

Blixt
A: 

I'd definitely go with the property. If you were doing something complex or computationally or time intensive, then you would go the method route. Properties can hide the fact that a complex operation is taking place, so I like to reserve properties for fast operations and ones that actually describe a property on the object. Simply: Methods "do" something, properties describe.

jasonh
I disagree. I often use properties for values that may not necessarily be a private field in and of themselves. I only use a method when it does something, not just gets some data.
RCIX
Can you let an example of use such property and field? Sounds strange...
Kamarey
Perhaps you meant to reply to someone else? I didn't say properties should be restricted to making private fields public. I also said: "Methods 'do' something", not "just gets some data".
jasonh
As an example of what I'm referring to, this would be an example property for a Connection object that is wrapping an underlying Telnet connection: public ConnectionState { get { return underlyingTelnetObject.State; } }
jasonh
oops, I forgot the Type: string (or whatever the type really is).
jasonh
Sorry, not specified. I meant an example of what RCIX wrote.
Kamarey
A: 

When you want to use it like a variable, you should go for a property. When you want it to be clear that this is a method, you should use a method.

As a property is a method, it depends on the semantic/design you want to communicate here.

Michael Barth
A: 

Properties should be used to wrap instance variables or provide simple calculated fields. The rule of thumb that I use is if there is anything more that very light processing make it a method.

Mark
+1  A: 

Ask yourself whether it's an aspect of your class (something it has) versus a behaviour of your class (something it does).

In your case, I'd suggest a property is the way to go.

Damovisa
A: 

If you are not doing anything significant, use proerties.
In your case, a readonly property (get only) should be good.

Methods make sense when you are doing something other than returning reference to an internal member.

shahkalpesh
+4  A: 

Properties are typically used to store a state for an object. Method are typically used to perform an action on the object or return a result. Properties offer both getters and setters and can have different scope (at least in .NET 2.0). There is also some advantages to using a property vs methods for serialization or cloning and UI controls look for properties via reflection to display values.

eschneider
A: 

Properties are a design smell.

They are sometimes appropriate in library classes, where the author cannot know how the data will be used but must simply output the same value that was put in (e.g. the Key and Value properties of the KeyValuePair class.)

IMHO some uses of properties in library classes are bad. e.g. assigning to the InnerHTML property of a DOM element triggers parsing. This should probably be a method instead.

But in most application classes, you do know exactly how the value will be used, and it is not the class's responsibility to remind you what value you put in, only to use the data to do its job. Messages should exercise capabilities, not request information

And if the value you want is computed by the class (or if the class is a factory and the value is a newly-created object), using a method makes it more clear that there is computation involved.

If you are setting the log filename, then there is also the side effect of opening the file (which presumably may throw an exception?) That should probably be a method.

And if the filename is just part of the log message, you do not need a getter for the property, only a setter. But then you would have a write-only property. Some people find these confusing, so I avoid them.

So I would definitely go for the method.

finnw
A: 

The answer in the dupicate question is correct. MSDN has a very good article on the differences and when one should be used over an other. http://msdn.microsoft.com/en-us/library/ms229054.aspx

In my case I believe using the Property would be correct because it just returns the path of the exe + a file name combined.

If however I decided to pass a file name to get it to combine with the exe path, then I would use a method.

Coding Monkey