Easy way to dynamically build classes/objects

[GKusnick]

Originally Posted by Slugger

Until such time someone (maybe you, maybe someone else) decides that the int property can no longer take on a certain set of values.

But then you've already reneged on the contract and potentially broken existing consumers by restricting the set of acceptable values compared to what used to be acceptable in version N-1. Better that consumers should find out about that change through a compile-time error than through runtime exceptions. In fact I'd argue that when changing the meaning of a property like this, you should deprecate the old property name and introduce a new property with a new name to implement the new meaning.

I also agree with Fuzzy that there's a big difference between using operator overloading or other syntactic sugar to obfuscate your meaning or just show off, and using virtual properties to clarify your meaning in the case when you intend a property to behave like a variable and not like a function (even though it may be implemented by getter/setter methods under the hood).

And while it's true that modern IDEs can generate the getter/setter boilerplate for you, the fact that it's necessary to insert such automatically generated boilerplate in the source says to me that there's some gap in the language design. Ideally (although very few languages approach this in practice) the source code should contain only the programmer's intentions, with a minimum of boilerplate. So for instance it should be possible to declare a property as (say) a read-only integer with such-and-such range constraints. Then all the getter/setter boilerplate, range checking, exception throwing, etc should be generated by the compiler (not the IDE's editor) and never appear in the source at all, since at that point it's redundant to the original statement of the programmer's intent. I'd argue that virtual properties come closer to this ideal than explicit getter/setter methods; that's why I call it a deficiency in Java that it lacks such a feature and thereby entails more source-level redundancy and boilerplate.

Finally, I don't consider this an argument and am not offended by anyone's contrary opinions. In a past life I was a language designer and compiler writer, so this sort of programming-theory discussion is right up my alley.

[stuckless]

I don't think your're going to get any argument that java is deficient in some areas.... it's a language... it's going to be deficient. I think the core point, isn't really whether java is deficient in not doing c# style getters/settings, but whether or not, you should adapt yourself to the best practices of using the language. In java, right or wrong, you have beans, properties, methods, etc. If the language was designed to be used that way, then use them, if for no other reason, then it will make your code easier to review and maintain by other peers that are also using the same language.

Just because C# doesn't require you to create getters and setters, isn't a good enough reason NOT to do it Java. Adapt to the language.

[Slugger]

Originally Posted by GKusnick

But then you've already reneged on the contract and potentially broken existing consumers by restricting the set of acceptable values compared to what used to be acceptable in version N-1. Better that consumers should find out about that change through a compile-time error than through runtime exceptions. In fact I'd argue that when changing the meaning of a property like this, you should deprecate the old property name and introduce a new property with a new name to implement the new meaning.

I'd agree if the meaning of the property were changing for some arbitrary reason, but in the example of the negative value for numPages then I think we'd agree that allowing negative values to begin with was a bug that needed to be fixed. So you fix the bug by checking for negative values and throwing an exception in the setter and release the updated jar. Most likely, 99% of your consumers will simply replace the jar with the updated one and not have to change any code (b/c they never tried to set numPages to a negative number). These users have peace of mind that the potential bug was fixed upstream and everyone sleeps easy at night knowing that the upstream API is watching out for them now. They certainly don't want to be bothered with compile errors because numPages was directly exposed and now no longer is. And they'll only be exposed to the runtime exceptions should they be using a negative value for numPages - a value that should never have been used in the first place. Hitting such a runtime exception would now expose a previously uncaught bug in their use of the API.

The other 1%? They update the jar and run their unit, regression, functional, and system verification tests and immediately a new IllegalArgumentException is unexpectedly thrown. Quickly they realize that somewhere they were setting numPages to a negative number and make the fix. Their fix is then deployed along side the new upstream jar and everyone's happy. If the original API exposed the properties directly then hid them to address the negative numPages bug then the first thing you have to do is address all the compile errors that the API change will introduce. After you're done cursing out the upstream API provider for their API breaker you then run your test suites and then find the new IllegalArgException and then you have to address that as well.

Exposing class properties, in my experience, always leads to more work down the road.

I also agree with Fuzzy that there's a big difference between using operator overloading or other syntactic sugar to obfuscate your meaning or just show off, and using virtual properties to clarify your meaning in the case when you intend a property to behave like a variable and not like a function (even though it may be implemented by getter/setter methods under the hood).

Agreed. However, I guess my point is that in Java, specifically, exposing class properties is always wrong* b/c even if you think you'll never restrict the value of an int property, inevitably, you will need to and once you do you have to hide the property in order to implement the restrictions. I'm from the camp of preventative/defensive programming. In a much more complex system, the cost of having to go back and hide class props later on down the road and introduce getters/setters is just too expensive compared to the cost of simply introducing the getters/setters from day one (especially when the initial cost is two mouse clicks).

* There's always exceptions to the rule, but in general, I stand by this statement.

And while it's true that modern IDEs can generate the getter/setter boilerplate for you, the fact that it's necessary to insert such automatically generated boilerplate in the source says to me that there's some gap in the language design. Ideally (although very few languages approach this in practice) the source code should contain only the programmer's intentions, with a minimum of boilerplate. So for instance it should be possible to declare a property as (say) a read-only integer with such-and-such range constraints. Then all the getter/setter boilerplate, range checking, exception throwing, etc should be generated by the compiler (not the IDE's editor) and never appear in the source at all, since at that point it's redundant to the original statement of the programmer's intent. I'd argue that virtual properties come closer to this ideal than explicit getter/setter methods; that's why I call it a deficiency in Java that it lacks such a feature and thereby entails more source-level redundancy and boilerplate.

I don't think the boilerplate is redundant, though I do agree it would be better if you could just define a class property's contract in the prop's declaration.

Java:

public class HockeyResult {

   static protected boolean validateTeamName(String name) {
      return name != null && name.length() > 0;
   }

   static protected boolean validateScore(int score) {
      return score >= 0;
   }

   private String awayTeam;
   private int awayScore;
   private String homeTeam;
   private String homeScore;

   public HockeyResult(String away, int aScore, String home, int hScore) {
      setAwayTeam(away);
      setAwayScore(aScore);
      setHomeTeam(home);
      setHomeScore(hScore);
   }

   public void setAwayTeam(String name) {
      if(!validateTeamName(name))
         throw new IllegalArgumentException("Away name cannot be null nor zero-length!");
      awayTeam = name;
   }

   public String getAwayTeam() { return awayTeam; }

   public void setHomeTeam(String name) {
      if(!validateTeamName(name))
         throw new IllegalArgumentException("Home name cannot be null nor zero-length!");
      homeTeam = name;
   }

   public String getHomeTeam() { return homeTeam; }

   public void setAwayScore(int score) {
      if(!validateScore(score))
         throw new IllegalArgumentException("Away score cannot be negative!");
      awayScore = score;
   }

   public int getAwayScore() { return awayScore; }

   public void setHomeScore(int score) {
      if(!validateScore(score))
         throw new IllegalArugmentException("Home score cannot be negative!");
      homeScore = score;
   }

   public int getHomeScore() { return homeScore; }
}

HockeyResult result = new HockeyResult("Canada", 3, "Russia", 2);
result.setHomeScore(-1); // Ooops, throws IllegalArgException b/c of broken contract

I don't believe there's anything redundant in this code. Is it a little long winded? Sure. Would I like to be able to define my class like this:

public class HockeyResult {

   private String homeTeam(not_null, not_empty);
   private String awayTeam(not_null, not_empty);
   private int homeScore(not_negative, less_than 100);
   private int awayScore(not_negative, less_than 100);

   public HockeyResult(String away, int aScore, String home, int hScore) {
      awayTeam = away;
      awayScore = aScore;
      homeTeam = home;
      homeScore = hScore;
   }
}

HockeyResult result = new HockeyResult("Canada", 3, "Russia", 2);
result.homeScore = -1; // Oops, throws an IllegalArgException because of broken contract

Sure, but since I can't in Java, it's best to use getters/setters to save tonnes of maintenance down the road.

I think both class definitions say the same thing and though the real Java code is much longer to say the same thing, I don't think there's anything redundant in the class def'n? Trying to make the real Java class more compact by exposing the properties might shorten the code, but will undoubtedly eventually cause a massive headache at some point down the road.

[GKusnick]

Originally Posted by stuckless

Just because C# doesn't require you to create getters and setters, isn't a good enough reason NOT to do it Java. Adapt to the language.

Agreed:

Originally Posted by GKusnick

So while obsessive use of getters/setters may be appropriate for Java, it's not a habit one should carry over to other languages that don't require it.

It's the second half of that statement I'm defending. Just because this turns out to be smart practice in Java doesn't elevate it to the status of a general principle of good programming style. It's still just a workaround for a specific language deficiency.

Originally Posted by Slugger

I'd agree if the meaning of the property were changing for some arbitrary reason, but in the example of the negative value for numPages then I think we'd agree that allowing negative values to begin with was a bug that needed to be fixed.

Yes, I understood the numPages example. That's why I was careful to propose as a counterexample "an integer property that can legitimately take on any integer value". Changing your mind later and deciding that, no, it can't take on negative values is changing the contract arbitrarily in that case.

But I'll grant that preemptively using getters/setters even in that case does no real harm, aside from a small "use tax" (method call syntax v. assignment syntax) at the point of consumption.

[Fuzzy]

Depending on the implementation, there may be a real processing time use tax for the redundant getters and setters. This all depends, of course, on the use, and the underlying system in use.

[Slugger]

Originally Posted by GKusnick

But I'll grant that preemptively using getters/setters even in that case does no real harm, aside from a small "use tax" (method call syntax v. assignment syntax) at the point of consumption.

Originally Posted by Fuzzy

Depending on the implementation, there may be a real processing time use tax for the redundant getters and setters. This all depends, of course, on the use, and the underlying system in use.

If the method call vs. direct assignment is a real concern then Java shouldn't even be used. I'd even submit that if the method vs. direct assignment is really that big an issue then most any OO language really should be reconsidered.

Originally Posted by GKusnick

It's the second half of that statement I'm defending. Just because this turns out to be smart practice in Java doesn't elevate it to the status of a general principle of good programming style. It's still just a workaround for a specific language deficiency.

I really have to disagree with this statement. One of the key fundamentals of OOD/OOP is code reuse and data abstraction/info hiding. Rarely should the properties of a class ever be exposed (dare I say, never). Exposed state actually hinders code reuse (as we've been discussing) and contradicts the data abstraction idea. Now, where language syntax allows, then I'm all for direct assignment where under the hood that direct assignment is actually handled with implied getters/setters (thereby allowing for easy enforcement of future contractual needs for the state of an object). But in the case of Java, I just can't envision any case where one would be writing a public API and ever expose the state of an object for direct reading and writing.

People can feel free to hush this thread up, but got to admit it's been awhile since I've had an academic debate on such topics so I'm rather intrigued by the other opinions on the subject.

[MeInMaui]

I think this thread has been very educational. I feel smarter just being in the same (virtual) room with you guys, though I'm sure it will wear off soon.

Aloha,
Mike

[PLUCKYHD]

Originally Posted by MeInMaui

I think this thread has been very educational. I feel smarter just being in the same (virtual) room with you guys, though I'm sure it will wear off soon.

Aloha,
Mike

I share those sentiments wish I knew enough to share my side ,but I have enjoyed reading and learning at the same time.