Now a little background. I am using this class as a super class to a bunch of different classes which represent objects from an XML file. This is basically an implementation of an API wrapper and I am using this as an adapter between the parsed XML from an API and a database. Casting is delegated to the caller of the get method. If the subclasses need to do something when they are created or when they return a variable, they just call super and then manipulate what gets returned afterwards. eg.:

The reason I feel like I should do this is so I don't have to write getId, getName, getWhatever methods for every single subclass just because they have different attributes. It would save time and it is pretty self explanatory.

Now this is obviously "unJavalike" and more like a ducktyped language way of doing things, but is there a logical reason why I should absolutely not be doing this?

There's nothing inherently wrong with this (imo). As long as the users of the subclass know they only put certain objects into your class, there's nothing wrong with them casting them on the way out.
–
FalmarriDec 16 '10 at 20:04

1

I changed your title a little bit, see if it still fits your intent. :D
–
Gordon GustafsonDec 16 '10 at 20:06

You might get some issue with re-usable components like Java beans and some other components like and IDE use getter and setters. A good IDE like eclipse will generate getter and setter automatically for you.
–
AkadisoftDec 16 '10 at 20:08

If you're going to this level of complexity and mucking up your object model just because you don't want to have getters and setters, do it in Groovy instead.

Groovy is a duck typed dynamic language on the JVM that accepts 98% of valid Java code, so you already know most of the language (you don't lose functionality)...there are "more idiomatic" ways of doing things, but you can pick those up with time. It also already has a built in XmlSlurper, which probably does most of what you're trying to do anyway.

As for the "reasons why you shouldn't", you're introducing all types of maintainability concerns.

New classes will always have to derive from the base class.

They will have to implement a constructor that always calls a base constructor

They will have to override get() [which you're basically using to encapsulate your getters and setters anyway, why not just add that method and delegate to those other methods] and write specific logic which is likely to degrade with time.

Why shouldn't you? It'll work, right? Sure. But it's poor engineering in that you're either creating a maintenance nightmare, or reinventing the wheel and likely to do it wrong.

I like your answer. However, a couple issues: Groovy is not an option for me. This script is to be passed along for future use and I highly doubt they'll want to learn the new Groovy syntax. Also, would it work on a regular JVM without Groovy installed on a server or another machine? Because I can't tell. As for "New classes will always have to derive from the base class." - not sure why that's a problem. "They will have to implement a constructor that always calls a base constructor" - They'll have to write their own constructor no matter what. and...
–
AndrewKSDec 16 '10 at 20:18

For 3. I'll have to write getters and setters for everything if done the normal Java way, anyways. But instead, they'll just be filled with the public getId(){return id;}, public getName(){return name;} syntax over and over for several different classes. It's basically repeated code.
–
AndrewKSDec 16 '10 at 20:21