What's with all the Get/Set lines?

[alan93]

The reasons for using properties, and ALWAYS keeping data private, is that it gives you the flexability to change the internal representation without effecting your clients. It also provides "hooks" for intercepting all read/write accesses.

I'm sure you had some specific examples in mind as you were providing this broad and generalized statement. ? And it could be that your examples are not applicable to my scenarios but I'm willing to see if they are.
In the past i did most of my hooking after the var is assigned a value so I'm not sure of the benefit of before its assigned. Seem like 6-to-1 1/2 dozen to the other.

There is (almost) nevery a reason to have data members directly exposed.

The words "quick", "easy", "full access" don't come to mind here?

[TheCPUWizard]

[QUOTE=alan93]I'm sure you had some specific examples in mind as you were providing this broad and generalized statement. ? And it could be that your examples are not applicable to my scenarios but I'm willing to see if they are.
In the past i did most of my hooking after the var is assigned a value so I'm not sure of the benefit of before its assigned. Seem like 6-to-1 1/2 dozen to the other.

private int m_Value;
public int Value
{
    set
     {
        // Do things before the write
       m_Value = value;
       // Do things after the write
      }
     get
     {
        // Do things before the read
       return m_Value;
      }
}

The words "quick", "easy", "full access" don't come to mind here?

Nope, all of those thiongs are "bad". "Correct", "Reliable", "Maintainable", "Encapsulated", "Minimal-Surface-Area"... those are terms that come to mind.

[alan93]

I guess this article of a fellow thinking skeptic explains better for me the questions I have about encapsulation, hiding, etc...

http://www.tonymarston.net/php-mysql/good-bad-oop.html

Particularly this excerpt:

Another common OOP feature that I deliberately chose to ignore is having a separate 'getter' and 'setter' for each of my entity variables. Why should I waste my time in feeding an object one item of data at a time when I can feed all data in a single associative array? Why should I waste my time in retrieving data from an object one item at a time when I can retrieve all data items in a single associative array?

Since my MDI app uses records in a formview class , I don't have different objects. The formview is always going to be the formview with the same controls and control vars. The document will always be the same object with the same record objects. I do have a record class object but I would prefer to assign the vars directly in the doc without all the pretty get/set properties. I can perform validation on it but I prefer to do all the vars of a record in one place, not each individually.

[TheCPUWizard]

...but I prefer....

If you are writing the code for your own personal use, you are (of course) free to do what ever you like, as only you will have to deal with the consequences.

If you are in a professional programming environment, then the goals change. The primary focus is to reduce cost over the entire lifecycle of the product. Bugs cost money.

As an example, if you validate your values any other place than in a set property, you will have a hard(er) time tracking down who/where/when the value is set incorrectly. The following will definately be quicker to diagnose problems:

int Month
{
    set
    {
        if (value <1 || value>>12)
           throw new InvalidArgumentException("Month Values Must be between 1 and 12");
         m_Month = value;
     }
}

Now you have guarenteed that the value will NEVER be invalid, even for a nanosecond. There will never be any time spent tracking down the issue.

In terms of class sizes. Large classes are inherently harder to maintain. You will save time (in the long run) by breaking up the classes into related portions and aggregating them.

Remember one of the rules of testing is that any time a file is modified in any way shape or form, the ENTIRE file must be completely tested. This means running tests that exercise all possible paths through the code, including all error detection paths. If you split up the source, then the amount of work to test a change will be drastically reduced.

Excerpted from the coding rules my firms use:

1) All data private. No exceptions without written approval
2) 25 public properties maximum per class. Some flexability
3) Strive for a 3-5 to 1 ratio of properties to methods
4) All methods should have some internal function. If everything can be done in terms of public properties, the method should be factored out of the class. Methods are for "what an object does" not "what you can do to an object".

[Mutant_Fruit]

I guess this article of a fellow thinking skeptic explains better for me the questions I have about encapsulation, hiding, etc...

He also has this to say:

There are times when making a variable private instead of public, thus forcing you to use a 'getter' or a 'setter' is a good thing. In this way should it ever be necessary to adjust the data before it is input or output you only have to change the code inside the 'getter' or 'setter' rather than all those places which reference the 'getter' or 'setter'.

Out of interest, have you ever designed and implemented a library meant for widespread use and incorporation into many different apps? If so, did you make all your variables public and not use get/set methods on them? Also, have you any comments on the example i mentioned twice which shows a scenario where using get/set methods is a necessity?

[Rudegar]

i believe that with components it's only the properties which show up on the heh properties list for the gui component

personaly i believe that no vars should ever be made public

back before properties were really around we used to make get and set functions ourselfs (allso in c++)
because c++ have less enforced rules is no reason to be lazy
and if you need to compare less rules of c++ with something dont use vb as eks. vb is a world of pain
but not very ruly
pascal on the other hand is the disciplinarian :P

sure irl rules are cut but it would be madness if eks. dident try to enforce any types of rules

in c++ you can still use goto 10 (10 being line nr)
some crazy person may feel that heck people do things like that irl
but not! on my watch! :P jk

[MadHatter]

that link you provided was for OOP in PHP. PHP isn't quite the same as C++, C# or even java. it has a much more limited context and I'm not totally convinced that it works best in a strict OOP implementation. I love OOP and PHP but split OOP and standard PROC coding in it to about 50/50.

in .net having public members isn't going to hurt anything. it's definitely against what most consider "best practice" and it will limit some things that you can do with your object, but hey, its your baby, ignore or use anything you want to.

I always found it annoying to create getter / setter methods for member access.

It always felt awkward to me to reference a variable like a method. I really like the interface provided by .net properties because accessing an object's members "like" a public member feels a bit more logical in my eyes. there are things that you can do with properties that you cannot do with public members, but I cant think of one thing you can do with a public variable that you cannot do with a property.

things you cannot do with public variables that you can do with properties:
1. validate input / output
2. lazy initialization
3. access to read / write
4. virtualized members (mark the "variable" as virtual or abstract to allow for inheritors to implement their own functionality of what that member does for the concrete class).
4. notify observers on access (trigger events on get or set)

there are probably many more but these are what come to mind.


like I said, do what you want, but don't miss the forest for the trees.

[Mutant_Fruit]

Out of interest, not knowing any php, wouldn't the technique described in the previous link (http://www.tonymarston.net/php-mysql/good-bad-oop.html ) not tie you to implementation detail?

For example, suppose you wanted to change the internals to a dictionary, or a sorted list, or a linked list, or a hashtable, or seperate member variables, could you? I think not. However using properties in C# you can make those changes and the user of your code *does not care*.

[MadHatter]

php is a different beast. its not as strict an OOP language as .net is.

1. variables are not strongly typed.
2. there is no real encapsulation in the first place.
3. there aren't different container / collection types, so thats not really a valid use case.

anything you design whether ood or not is going to be tied to implementation at some level.

[krisk123]

Hi,

A property procedure is a set of code statements that are used to assign or retrieve the values of the member variables declared within a Class. Properties are types of variables that store the values for an object of a Class.

We can access properties either as public variables or by using Set and Get property procedures. However, it is advantageous to use property procedures instead of public variables, because using a property procedure we can define a property as read-only, write-only, or read/write type. There are two types of property procedures in C#.


• get method, which is used to retrieve the value from a member.
• set method, which is used to assign values to a member.


Try This bookatabase programming using Visual Basic 2005 and Csharp 2005

[TheCPUWizard]

Hi,

A property procedure is a set of code statements that are used to assign or retrieve the values of the member variables declared within a Class. Properties are types of variables that store the values for an object of a Class.

We can access properties either as public variables or by using Set and Get property procedures. However, it is advantageous to use property procedures instead of public variables, because using a property procedure we can define a property as read-only, write-only, or read/write type. There are two types of property procedures in C#.


• get method, which is used to retrieve the value from a member.
• set method, which is used to assign values to a member.


Try This bookatabase programming using Visual Basic 2005 and Csharp 2005

Still tring to determine the purpose of your post...

What is the "Value Added"?

[jmcilhinney]

Properties provide numerous advantages, many of which have been suggested here. The general idea of properties is that they behave from the outside like variables so they are easy to use in calling code, but they behave from the inside like methods so they provide all sorts of flexibility.

Take the Text property of the TextBox class. If that was a variable then when you set it in code its value would change but nothing else could possibly happen. Because it is a property, when it is set the class can update its display as well as raise the TextChanged event to notify the form that the property value has changed. That would all be impossible with just a variable. Without properties you would have to use a method to accomplish this as you do in Java, where there are countless pairs of get_SomeValue and set_SomeValue methods. This is less intuitive than .NET properties, which can be used just like variables in calling code.

Properties also facilitate data-binding in .NET apps. You can bind a collection of objects to a DataGridView or other control and have its property values displayed. You cannot do that with variables because data-binding requires event support that variables don't provide.

Another reason that has already been mentioned is the freedom to change the implementation of a class without changing its interface. All developers should care about that. There are many situations where using a property doesn't provide an immediate advantage but the mere fact that it does provide the freedom to change the implementation without breaking calling code should be enough to convince any conscientious developer to use them.

The fact that the C# IDE provides support to create property skeletons for you makes any complaint about too much code moot. You just type "prop" and hit the Tab key twice and the code snippet will create a property skeleton for you and even helps you edit that skeleton coherently.

There is no valid argument for not using properties that I can see. Writing less code is not valid as the amount of additional code you actually have to write yourself is very small. The advantages it offers far outweigh that small inconvenience.

[Rudegar]

well you could use events to do actions when a public var was changed but it would be alot of needless troublesome work to implement

[Zaccheus]

In C++/CLI (that's C++ for .net) there's a syntax which lets you declare public properties for which the compiler automatically provides the internal field & implements the get/set accessors for you.

I believe the same is planned for C# v3.

Still tring to determine the purpose of your post...

I think he's just agreeing that 'properties = good', 'public fields = bad'.

[jmcilhinney]

well you could use events to do actions when a public var was changed but it would be alot of needless troublesome work to implement

Rubbish. How would you do that? Events are raised from within the object. If you set a public field then no internal code is executed so no event can be raised. You would need to set the field via a method of the object, which is exactly what properties do. A property is implemented as two methods when compiled but it is used in code as though it was a field. That's the point: you get the best of both worlds.