Easy way to dynamically build classes/objects

[PLUCKYHD]

So wondering if there is an easier way to dynamically define and build custom class's which are for javaobjects.

For instance say I have

class BookObject{

private string Bookname;
private int BookLocation;

public String GetBookname(){
return Bookname;}
public void SetBookname(String Value){
this.Bookname=Value}
public Integer GetBookLocation(){
return BookLocation;}
public void setBookLocation(int Value){
this.BookLocation=Value;}
}

Is there a easier way to build this dynamically wihtout having to add Get/Set calls for every variable the object will hold? I figure there has to be and I am missing it?

maybe not....

cheers and TIA

pluckyhd

[GKusnick]

In what sense would this be dynamic? Presumably you're not planning to generate new classes and methods at runtime. You're going to code them once and that's it. So what you're looking for (if I understand right) is a way to save some typing when coding up new classes.

Seems to me the simplest solution is to make those fields public instead of private, so clients of your class can access them directly instead of through getter/setter methods. Or is there some other reason you need explicit getter/setter methods?

[PLUCKYHD]

Originally Posted by GKusnick

In what sense would this be dynamic? Presumably you're not planning to generate new classes and methods at runtime. You're going to code them once and that's it. So what you're looking for (if I understand right) is a way to save some typing when coding up new classes.

Correct want to save allot of typing/time.

Originally Posted by GKusnick

Seems to me the simplest solution is to make those fields public instead of private, so clients of your class can access them directly instead of through getter/setter methods. Or is there some other reason you need explicit getter/setter methods?

No other reason than that is how I learned how to do it...Is there a way to set those variables without set methods?

[Fuzzy]

There's really no reason to use Get and Sets if all they really do is manipulate the internal variable without any other checks/functions. It's easier to just make the variable itself public. Just make it as so:

class BookObject{

public string Bookname;
public int BookLocation;

}

there are, of course, times when you want the variable itself to be private, and use gets and sets... but that would be if you wanted to actually DO something in that get or set function, like check the data before writing, and potentially throw some errors... or provide logging, etc...

[stuckless]

Pluckly, most IDEs will do this for your.

Just create,

public class class BookObject {
   private string Bookname;
   private int BookLocation;
}

Then right click, and Source -> Generate Getters and Setters. The ide will create all the setters and getters.

Later when you add

private long price;

then right click, Source -> Generate Getters and Setters, and the IDE will fill in the missing methods.

If you use netbeans, then it has the same tools, but may be called something slightly different.

Keep in mind, that java ides (like most ides) will generate tons of boilerplate code. nobody write that stuff anymore.

[GKusnick]

Originally Posted by PLUCKYHD

Is there a way to set those variables without set methods?

object.field = value;

(Assuming the field is public of course.)

[Slugger]

Please do not use public properties for your class, especially if the class is to be part of a public API that you plan to release. Call me "old school", but simply making your properties public will undoubtedly cost you down the road.

public class Book {
   public String title;
   public String content; // Assume content is just one big string for simplicity
   public int numPages;
   public int location;

   public Book(String title, String content, int numPages, int location) {
      this.title = title;
      this.content = content;
      this.numPages = numPages;
      this.location = location;
   }
}

So to make life easier you make these properties public and allow direct access and modification to them. All is good until somewhere down the road you accidentally instantiate an instace of Book like this:

Book b = new Book("My First Novel", "Blah blah blah", -1, 200);

And somewhere else in your code you get an IndexOutOfBoundsException (or some kind of runtime exception) because numPages is negative. So you track down the bug and the sol'n is to ensure that numPages is never negative. You could check this in the constructor, but what happens when the value is set to negative after instantiation?

Book b = new Book("My Novel", "Blah, blah, blah", 5, 200); // Valid object instantiation
b.numPages = -1;  // Completely valid since numPages is public, but now numPages is negative, which will cause that runtime error to resurface

The only way to ensure numPages is never negative is to control the setting of the value via a method:

public class Book {
   private String title;
   private String content; // Assume content is just one big string for simplicity
   private int numPages;
   private int location;

   public Book(String title, String content, int numPages, int location) {
      if(numPages < 0)
         throw new IllegalArgumentException("Number of pages cannot be negative!");
      this.title = title;
      this.content = content;
      this.numPages = numPages;
      this.location = location;
   }

   public int getNumPages() {
      return numPages;
   }

   public void setNumPages(int num) {
      if(num < 0)
         throw new IllegalArgumentException("Number of pages cannot be negative!");
      numPages = num;
   }
}

If you made the properties public then made them private to address the issue then you've now also broken all consumers of the class, which just adds more work. Put the extra work in up front and save yourself a headache later. Any decent IDE (I use Eclipse) will create the public getters and setters for you based on your private properties of the class. Take advantage of that, but trust me when I say don't just go making all your class properties public from the start.

My CS201 Prof would be so proud of me right now. And this also proves, despite his claim, that one can learn something even while napping during those 8am lectures!

[GKusnick]

Originally Posted by Slugger

...trust me when I say don't just go making all your class properties public from the start.

Not all of them, certainly, but if there's (say) an integer property that can legitimately take on any integer value, then I don't see the harm in making it public and avoiding the overhead of getter/setter methods.

Originally Posted by Slugger

If you made the properties public then made them private to address the issue then you've now also broken all consumers of the class...

Point taken, but to my mind this is a deficiency in Java, for which the workaround is to pre-emptively use getter/setter methods and force consumers to use method call syntax instead of the more natural assignment syntax. Other languages (such as VB and C#) handle this situation better by allowing consumers to be agnostic about whether they're accessing a property directly or through getter/setter methods and use assignment syntax in either case. This gives the class designer the freedom to change the implementation without breaking existing consumers. 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.

[stuckless]

I agree with Slugger here... do start out by exposing properties, it's just wrong, for an object.

Now, if you are truly making a structure (ie, what's we'd call a struct in c), then I could see, perhaps, not creating the setters and getters. There are cases where i've done this for inner classes that are being uses only to hold data, ie, there are no operations in the structs. My general rule of thumb here, is the struct instances are never exposed beyond my class, and that the structs do not contain methods.

So, if you objects are purely structs, then I could see someone just using properties. The problem is your objects are going to start out as structs, and then you are going to add in constructors with parameters and method that calculate values, and now you have this crud of an object/struct that doesn't make sense to anyone.

Greg's point above is valid, ie, he way that c# defines setters and getters is better. But given that an ide will generate setters and getters for you in a couple seconds... is there really any reason to choose poor coding conventions, when doing it right, is just so darn easy

[stuckless]

Originally Posted by GKusnick

Point taken, but to my mind this is a deficiency in Java, for which the workaround is to pre-emptively use getter/setter methods and force consumers to use method call syntax instead of the more natural assignment syntax. Other languages (such as VB and C#) handle this situation better by allowing consumers to be agnostic about whether they're accessing a property directly or through getter/setter methods and use assignment syntax in either case. This gives the class designer the freedom to change the implementation without breaking existing consumers. 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.

Part of what makes a good programmer is there ability to adapt to different programming languages. When I write C code, I don't write it in the "java way", and when I write Java code, and I don't write it in the "C" way (although I was a C programmer first). Adapting the language is good for you, and it's even better for the person that has to clean up after you. Do you realize how hard it is for someone to work on java code that been coded in c, or vice versa? Your other point about allowing the developer to use either field notation or method notation for accessing the same value (or setting it)... there's something to be said for consistency. I laugh when I see vb and .net code where parts of the program use object.field and later they use object.getField()... I think this usually stems from different people working the same file, who refuse to adapt to the way it's been previously done.

[PLUCKYHD]

Did not know about the auto set/getter coding do you know how much time that would have saved me 3 months ago if I would have asked

I prefer to leave them private and my reasons are different from above and I didn't mean to start an argument.

The method I read and use it to make all of the private in the object class and have another class for calling the methods it is allot of coding but it is easier for me to keep track of that way.

thanks again and I can't believe I didn't know about the automatic set/get methods of the ide....

[stuckless]

@Plucky - don't feel bad. I've pointed out features of eclipse to people that have been using for longer than I have Keep in mind, then only reason to use an IDE is increase productivity over a regular power editor like vim. I spent years in vim, so when I moved to eclipse, I needed to prove that it would actually increase my productivity. While initially, learning every aspect of the IDE decreased my productivity, doing so has much improved my overall productivity, and then I stopped using vim (i still miss vim )

Bottom line keep posting your questions... whenever you think that "there's got to be an easier way..." there probably is... because we also hate typing

[jphipps]

Originally Posted by stuckless

@Plucky - don't feel bad. I've pointed out features of eclipse to people that have been using for longer than I have Keep in mind, then only reason to use an IDE is increase productivity over a regular power editor like vim. I spent years in vim, so when I moved to eclipse, I needed to prove that it would actually increase my productivity. While initially, learning every aspect of the IDE decreased my productivity, doing so has much improved my overall productivity, and then I stopped using vim (i still miss vim )

Bottom line keep posting your questions... whenever you think that "there's got to be an easier way..." there probably is... because we also hate typing

That is one thing I like about netbeans, they have a vi plugin jvi to make the editor use all vi commands instread of the normal gui editor...

Thanks,
Jeff

[Fuzzy]

Wow.. this discussion really has pointed out how happy i am that I use .net languages.. ;-) I make a custom class for just about every object I use, and the agnostic nature of properties and variables are so much more evolved than the older java and c methods. I hadn't realized the difference when I recommended just majing the variables themselves public earlier. If you can't use them in the same way as get/set methods in subsequent code, then, yes, it does only make sense to ONLY use get and set methods.

In .NET, however, if you are not going to be doing any checking of a value before setting it, or not performing any action when get or set, then there really is no harm in making the variables themselves public. If at a later time, you decide there are some checks and what-not that you wish to perform, you can easily create a private variable to take it's place, and make a public property (the .net name for getters and setters) with the same name... makes it a transparent change to the users of the class.

[Slugger]

Hopefully no one else is seeing this as an argument, but rather a valid discussion on coding practices. I hope my tone is not being read as anything other than that.

Point taken, but to my mind this is a deficiency in Java, for which the workaround is to pre-emptively use getter/setter methods and force consumers to use method call syntax instead of the more natural assignment syntax. Other languages (such as VB and C#) handle this situation better by allowing consumers to be agnostic about whether they're accessing a property directly or through getter/setter methods and use assignment syntax in either case. This gives the class designer the freedom to change the implementation without breaking existing consumers. 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.

I wouldn't call it a deficiency, but rather a difference between Java and VB or C#. Don't quote me on this (b/c I can't find the reference and I'm just working solely from memory on this), but I believe the reason Java doesn't provide such syntactic sugar (which is really all it is in VB/C#) is because Gosling despised the syntactic sugar provided by C++ at the time, namely operator overloading. Instead he felt it was much easier to understand a programmer's intent through the use of explicit getters/setters rather than allowing all kinds of syntactic sugar/implied code. When I first started with Java (coming from a C/C++ background) I have to admit I disagreed and missed my operator overloading from C++. Years later, I now appreciate the explicitness of Java code versus reading some crazy C++ code from some hotshot who felt it was "cool" to overload the bit shift operator to mean "clone" without solid docs. You sit and scratch your head for hours and hours trying to figure out what's going on, whereas if the code just read:

// Not real var names, bare with me ;)
MyObj *obj;
MyObj *obj2;
...
obj->clone(obj2);

Then I'd have saved myself a massive migraine. I'm not saying there's no place for syntactic sugar, but my experience has been that too many devs take advantage of it without properly documenting it, whereas if they had to use explicit method calls then their code becomes self documenting and much clearer. This may not be relevant in the space of SageTV development where most projects are single authors, but still always a good practice.

[Slugger]

Originally Posted by GKusnick

Not all of them, certainly, but if there's (say) an integer property that can legitimately take on any integer value, then I don't see the harm in making it public and avoiding the overhead of getter/setter methods.

Until such time someone (maybe you, maybe someone else) decides that the int property can no longer take on a certain set of values. If you put the work in up front then it's just a matter of enforcing the new requirement in the setter (and perhaps ctor) and releasing the new jar, but if you made the property public then now you have to break all consumers and label your new version as an API breaking update to your API, which is very bad news.

Again, I guess I'm speaking more from my day job when I talk about this kind of thing and I'm sure if you go looking through my source code for all my SageTV plugins you'll find some direct contradictions to my advice (though I'd be shocked if you found a public property defined in any public or pkg protected class that I've written), but, imho, when it comes to Java there's just no reason not to create getters and setters for all class properties. If nothing else, it's preventative maintenance and will save a (possible) API breaking fix later on down the road.

[Fuzzy]

well, to be fair, there's a HUGE difference in the 'sugar' in C++ (which is very inconsistant, and almost 'tacked on' feeling) and .NET's much more natural way of doing things. Of course, a lot of the power of .net IS the visual studio IDE. Why have the code 'self-documenting' just through comments and method names, when you can have the applicable documentation popping up as you are coding?

[stuckless]

Originally Posted by Fuzzy

well, to be fair, there's a HUGE difference in the 'sugar' in C++ (which is very inconsistant, and almost 'tacked on' feeling) and .NET's much more natural way of doing things. Of course, a lot of the power of .net IS the visual studio IDE. Why have the code 'self-documenting' just through comments and method names, when you can have the applicable documentation popping up as you are coding?

I'd be very disappointed in an IDE that didn't do that... other than standard editors, I'm pretty sure every IDE would do auto completion and hovering documentation, click through navigation of objects (ie, in eclpse, if you hover on a type, class, field, etc, and hold the ctrl key, then it turns that item into an hyperlink where you can click it to jump directly to that declaration, class file, etc.).

I think "natural" is a term that people use to describe the way that they currently do things

[Fuzzy]

I was in no way stating that eclipse can't do this, just that THIS is how code should be documented, not just with Method names. I actually think Stuff = GetThis and SetThat(stuff) are an extra level of unnecessary complexity... I much prefer Stuff = This and That = Stuff... Much easier to read through the code. Never liked that Java forced you to use two completly different styles for variables and functions..

[evilpenguin]

Originally Posted by stuckless

I'd be very disappointed in an IDE that didn't do that... other than standard editors, I'm pretty sure every IDE would do auto completion and hovering documentation, click through navigation of objects (ie, in eclpse, if you hover on a type, class, field, etc, and hold the ctrl key, then it turns that item into an hyperlink where you can click it to jump directly to that declaration, class file, etc.).

I think "natural" is a term that people use to describe the way that they currently do things

Man, my IDE doesn't do any of this stuff, maybe I just don't have it set up right...