What's with all the Get/Set lines?

Quote:

---

Originally Posted by 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

---

Erm... but how your code know to fire the event when a public member variable changes.

If i have a class which has a public member variable Temperature, and i set Temperature = 100, how can you automatically fire an event to let people know i've changed Temperature. You can't. There is no way.

Quote:

---

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.

---

Yes, they're called automatic properties, i've mentioned em a few times in this thread ;)

Regarding Events on Modification...

1) Agreed it is impossible if you expost the data member itself, you MUST use properties, and put the logic inside the property (see alternate note below...)

2) Raising Events on "Data" changes is a common feature. In fact my firms entiry line of "SmartData" products make VERY heave use of this..

Now the exclusion to point #1...

(Free Typed, so syntax not guarenteed ;) )

Code:

---


class SmartData<DATA_TYPE>
{
public DATA_TYPE Value
{
    get
    {
        return m_Value;
    }
    set
    {
        if (m_PreWriteEvent != null)
          m_PreWriteEvent(this, m_Value, value);
        DATA_TYPE oldValue = m_Value;
        m_Value = value;
        if (m_PostWriteEvent != null)
          m_PostWriteEvent (this, m_oldValue, Value );
    }
}
}

---

Code:

---

class SomeClass
{
    public readonly SmartData<int> MyIntegerProperty;
}

---

Code:

---

SomeClass.MyIntegerProperty.PreWriteEvent += new PreWriteEventHandler();
SomeClass.MyIntegerProperty.Value = 123; // Will fire Event...

---

While this may seem complicated for trivial situations, the model is HIGHLY extensible. The actual library contains full Control Binding, DataBase Persistance, Dynamic Data Caching, XMjects, and more...

Quote:

---

Originally Posted by Mutant_Fruit

Yes, they're called automatic properties, i've mentioned em a few times in this thread ;)

---

Sorry, I somehow missed that. :thumb:

Quote:

---

Originally Posted by Mutant_Fruit

He also has this to say:


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?

---

Sorry getting a little overwhelmed with the plethora of ideas coming in here.
Let me see if I can address most of them here.

Btw I didn't get your 100000 example.

Yes we have a dll dialog app that is used by several different programs. The dialog class has MANY global variables shared amonst the functions in that class. I don't make everything global but when it has to be shared I do m_csSharedStringVar or m_bSharedBoolVar. So controlling access doesn't resonate with me. I just use them masterfully the way I see fit.

Some people have mentioned that apps can be buggy but if you don't do this but the bugs we usually get are related to missing dlls or system anomolies not because a variable was public.

If I understood everything jmcilhinney said I might be sold on it lol.

My thoughts about doing the validation within the property bothers me because I LIKE doing the validation WHERE the values gets assigned. Not in a property in a galaxy far far away.

I like the single line declaration of the property , especially until I decide if I even want to use it to fire another event or do "remote" validation because Like I said , in the large scale MDI, have LOTS of controls and membr vars.

SO my aversion to 12 lines of property code is having all these in my view class or whatever and then making my eyes bleed looking for one or scrolling my fingers to the bone.

I think my primary programming philosophy is EFFICIENCY & CONDENSATION.

And yes I have been known to see millions of trees and no forrest yet I can weed through details very skillfully.

Quote:

---

Originally Posted by 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*.

---

Not following you .
Without details I'm pretty much deaf, dumb , and blind.

Quote:

---

I just use them masterfully

---

I like the modesty in that. :D :D

Quote:

---

I LIKE doing the validation WHERE the values gets assigned

---

and

Quote:

---

EFFICIENCY & CONDENSATION

---

So what happens if you assign to the variable multiple times in the code ? Do you do the same validation at every point ? And what happens if something in the validation changes - or there's a bug you need to fix. Do you have to fix it in the x number of copied and pasted pieces of code ? Can you remember EVERYWHERE where you assign to the variable ?

Personally I work on the principle of never write the same code twice. That's pretty efficient and condenses the code down nicely. And fewer lines of code = fewer bugs I've found.

Doing validation everywhere you set a variable is, I would say, neither efficient nor condenses the code. In fact you'd end up with validations just about everywhere making the code very hard to read...

So that's a big thumbs up :thumb: for encapsulation from me. In the long run it makes my life so, so, so much easier. And anyone elses life who has to work on code I've written too....

I've found that just because you can do something you shouldn't necessarily do it. I could make every variable in my applications public and global but I don't. Just as I can walk across any road anytime I want : but I don't because otherwise a big lorry will come along and squash me.

Darwen.

Quote:

---

Originally Posted by darwen

I like the modesty in that. :D :D

---

Well, lets just say there's no conceit in my family, I have it all. :p

Quote:

---

Originally Posted by darwen

So what happens if you assign to the variable multiple times in the code ? Do you do the same validation at every point ? And what happens if something in the validation changes - or there's a bug you need to fix. Do you have to fix it in the x number of copied and pasted pieces of code ? Can you remember EVERYWHERE where you assign to the variable ?

---

Good point, good questions. Let's talk. The vars in my app are populated two ways mainly. 1. user 2. from external library. I do it at those to entry points and the rest of the program is basically shuffling it around so I don't need to validate in very many places. Most validation changes occur at the same points and is usually due to a vendor changing their data sturcture on us or a user getting creative in a way we never imagined.

And no I don't do this a lot even though I may get facetious about it. I make most vars local in scope of a function but if multiple functions need it I make them members.

Quote:

---

Originally Posted by darwen

Personally I work on the principle of never write the same code twice.

---

Exactly! Whenever possible I make a separate function that is called by various routines so so the code in that function , such as Validate(), is only written once. But get/set for each var, this seems like overkill even though I know you can do a lot with that.

So mostly i just want to declare a var (lots of them), use it, assign it, and get from it without the 12 lines.

Quote:

---

Originally Posted by alan93

Sorry getting a little overwhelmed with the plethora of ideas coming in here.
Let me see if I can address most of them here.

Btw I didn't get your 100000 example.

---

Suppose you're writing a card game library. You only want to allow a player to switch cards 3 times. If you make your NumberOfSwitchesAllowed variable public, the user can just write: NumberOfSwitchesAllowed = 100000 and they'll get a royal flush every time because they'll just keep switching.

This is the (common enough) situation where public variables suck.

Code:

---

I just use them masterfully the way I see fit.

---

Fair enough, now what happens when your company hires a new guy to maintain your code and he doesn't understand your masterful plan and instead sees 200 global variables and hasn't a clue which of them belong to which class, what sanity checks need to be performed every time he assigns a value to them and suchlike. Which brings me on to this point:

Quote:

---

My thoughts about doing the validation within the property bothers me because I LIKE doing the validation WHERE the values gets assigned. Not in a property in a galaxy far far away.

---

You're right. I like doing validation only where the values get assigned. The value is *only* assigned in the property. So that's where the validation goes. For example, consider this property

Code:

---

private int m_Month;
public int Month {
      get {  return m_Month; }
      set  {
          if (value > 12 || value < 1)
              throw new Exception("Invalid Month");
          m_Month = value;
      }
}

---

That's 9 lines, including all validation. Now, there is no chance in hell that i could *ever* forget to validate the value. Everywhere else in my code i can just call: Month = myInt and i'm guaranteed Month will never take on an invalid value.

With a public variable i'd be forced to duplicate these two lines every time i want to set a value to Month:

Code:

---

          if (value > 12 || value < 1)
              throw new Exception("Invalid Month");

---

Of course, you hate code duplication (as do i) which is why i'm sure you'd much prefer to only have your validation in one easy to edit place! Now suppose in the future you want to change the valid months to exclude December, in my version you have to change 1 character. In your version you'd have to change 1 character many times, with the chance of accidentally missing one point where it was used.

If you can't understand the advantages to this method, then fair enough, it's not our fault, we've tried explaining using many simple examples. You might be better off getting a beginners book to OOP which may explain it better than us.

EDIT: Can i point out that a get/set does not take 12 lines. It takes 9 including validation. You can place your brackets wherever the hell you want and liberally add whitespace and make a get/set take 30 lines, but it still doesn't make it bloat.

Finally, AutomaticProperties reduce the code to just:

Code:

---

// This code allows public getting, but only internal functions can
// actually set the value. So public users see a GET only
// internally you have get and set
public int MyInt { get; internal set;}

---

I certainly woulden't want to be this guys co-worker :)

Make variables wherever you want. You don't have to use get/set.

Code:

---

public int myPublicInt = 0;

---

Then use the = operator wherever you like.

Code:

---

myClass.myPublicInt = 0;

---

Quote:

---

Originally Posted by alan93

Exactly! Whenever possible I make a separate function that is called by various routines so so the code in that function , such as Validate(), is only written once. But get/set for each var, this seems like overkill even though I know you can do a lot with that.

So mostly i just want to declare a var (lots of them), use it, assign it, and get from it without the 12 lines.

---

maybe this is a stupid question, but why use C# at all? using the logic you've been talking about: String.Length is pointless because I can call strlen("some string") and its better because I have a function that manipulates a string and isnt only available as a member on a string type. lets not wrap up string functionality in a string object, because one can write some global function that can do everything you need for you, and makes your data types more compact.

if this is the prevailing logic, then standard C is going to your best bet, not some language that runs in a framework, contains a lot of pointless code (I had a professor in school that complained about the STL because it was too bloated. He was a retired asm developer.) and functionality that doesn't fit your style.



I work with people who think just like you, and our code base is literally 3 to 4 times larger than it needs to be because instead of utilizing encapsulation, inheritance / polymorphism, they write one class to hold the data, another to modify the data, and another to persist it and in some cases a class that wraps the original data type (with the public members) for a "object oriented" feel to the class.

personally, that kind of design drives me mad. it is expensive to maintain, monotonous to code against, almost impossible to extend and doesn't follow any of the best practices that can make development more cost efficient.