Deep/Shallow Copy Constructor

zelmak

I really need to find somewhere else to work...

public class Thing {
  private Collection statusList = null;
public void addStatus(Status status) {

if (statusList == null) {

statusList = new ArrayList();

}

if (statusList != null) {

statusList.add(status);

}

}
public void setStatusList(Collection statusList) {

if (this.statusList == null ) {

this.statusList = statusList;

} else {

if ( this.statusList != null ) {

this.statusList.clear();

}

this.statusList = statusList;

}

}
public Collection getStatusList() {

if (statusList == null) {

statusList = new ArrayList();

}

Collection rtn = null;

if ((statusList != null ) && (statusList instanceof Cloneable) {

rtn = statusList;

}

return rtn;

}
public Thing(Thing oldThing) {

// [ed note: copy constructor many other fields copied ... trying to

// concentrate on a single WTF area]

.

.

.

// Copy collections

//

// 01/21/02 <INITIALS> - WARNING - This creates a deep copy of the collection,

// but stores a reference to the object in the source collection, not a

// copy of the object in the source collection

// [ed note: so ... not a deep copy?]
Collection statusCollection = oldThing.getStatusList();
if (statusCollection == null) {
  this.statusCollection = null;
} else {
  try {
    this.statusList = (Collection) Reflection.getClassInstance(statusCollection.getClass());
    for (Iterator iterator = statusCollection.iterator(); iterator.hasNext(); ) {
      this.statusList.add(iterator.next());
    }
  } catch (ReflectionException e) {
    e.printStackTrace();
    throw new RuntimeException("unable to create status collection while instantiating " + this.getClass().getName() );
  }
}

} // end copy constructor
} // end class Thing

For some reason, I feel like I've posted something like this before ...

Do I dare show you how they wrapped Reflection? (ReflectionException wraps the three or four exceptions which can be thrown when muddling about with instantiating a new instance using standard Reflection classes/methods.)

dohpaz42

I hear that Mason Wheeler is hiring. ;)

zelmak

Oh, what the hell ... without comments, it isn't terribly long. I'll leave in comments for the first method so you get a feel for the commenting style.

public abstract class Reflection {
// -------------------------------------------------

//   Method: Reflection.getClassObject

/**

Loads a specified class. This method really only calls
Class.forClass()[sic], but it catches the exceptions from
forClass()[sic] and throws an exception with a more descriptive
error message.

@param className (String) the name of the class to load

@return (Class) the specified class

@throws ReflectionException Thrown if unable to find the specified

                          class file



*/

// -------------------------------------------------

public static

Class

getClassObject(String className) throws ReflectionException

{ // begin method Reflection.getClassObject

//

//   Declare variables

//

Class returnValue;

//

//   Trap exceptions

//

try

{ // begin trapping exceptions

//

//   Load the class file

//

returnValue = Class.forName(className);

} // end trapping exceptions

catch (ClassNotFoundException e)

{ // begin class not found exception handler

//

//   Throw an exception

//

throw new ReflectionException("unable to find class " + className);

} // end class not found exception handler

//

//   Return

//

return returnValue;

} // end method Reflection.getClassObject
// [ed note: the remaining uncommented ... just imagine that its there, tho ... in the style of the above]
public static Object getClassInstance(Class classObj) throws ReflectionException {

Object instance;

try {
  instance = classObj.newInstance();

} catch (IllegalAccessException e) {

  throw new ReflectionException("unable to instantiate abstract class " + classObj.getName() + ": " + e.getMessage());

} catch (InstantiationException e) {

  throw new ReflectionException("unable to instantiate " + classObj.getName() + ": " + e.getMessage());

} catch (SecurityException e) {

  throw new ReflectionException("security exception instantiating " + classObj.getName() + ": " + e.getMessage());

}

return (instance);

}
public static Object getClassInstance(Class classObj, Class[] argTypes, Object[] args) throws ReflectionException {

Constructor constructor;

Object instance;

try {
  constructor = classObj.getConstructor(argTypes);
  instance = constructor.newInstance(args);

} catch (IllegalAccessException e) {

  throw new ReflectionException("unable to instantiate abstract class " + classObj.getName() + ": " + e.getMessage());

} catch (IllegalArgumentException e) {

  throw new ReflectionException("unable to instantiate " + classObj.getName() + ": " + e.getMessage());

} catch (InstantiationException e) {

  throw new ReflectionException("unable to instantiate " + classObj.getName() + ": " + e.getMessage());

} catch (InvocationTargetException e) {

  throw new ReflectionException("unable to construct " + classObj.getName() + ": " + e.getMessage());

} catch (NoSuchMethodException e) {

  throw new ReflectionException("unable to find constructor for " + classObj.getName() + ": " + e.getMessage());

}

return (instance);

}
public static Object getClassInstance(String className) throws ReflectionException {

return (Reflection.getClassInstance(Reflection.getClassObject(className));

}
public static Object getClassInstance(String className, Class[] argTypes, Object[] args) throws ReflectionException {

return (Reflection.getclassInstance(Reflection.getClassObject(className), argTypes, args);

}
}

So, by wrapping all the exceptions, we've lost granularity in understanding the exceptions being thrown at the higher level, but we can parse the message strings to get that information out? Thanks?

zelmak

To explain: I've always been of the opinion that, unless you're writing tools/frameworks for other programmers, you should leave reflection alone and program using interfaces, composition of objects and a minimum of inheritance.

Just one guy's opinion, though.

TGV

@zelmak said:

Oh, what the hell ... without comments, it isn't terribly long. I'll leave in comments for the first method so you get a feel for the commenting style.

Is that even code? I mean, I've been writing some reflection stuff today, but this just gives me a headache. Remember: arson is always an option.

@zelmak said:

So, by wrapping all the exceptions, we've lost granularity in understanding the exceptions being thrown at the higher level, but we can parse the message strings to get that information out? Thanks?

At the very least, they could have stuffed the original thrown exception into a "cause" field so that it is still available for evaluation in case it is ever needed. But I guess that much common sense is too much to expect from people (I can't bring myself to say "programmers"... I just can't) that write code like that.

Xyro

Whooooa. Those are some intense WTFs. I mean, I may have seen worse code, but that stuff shows such a complete failure to understand the language at every level... It makes my head spin with anger that this is allowed to exist... Arg! What a dirty, filthy, smelly piece of code! It was smelly, and obscene and disgusting and I hate it, I hate it,.. nasty, grubby, dirty, mingy, scrubby little code! >:O

Jaime

@zelmak said:

To explain: I've always been of the opinion that, unless you're writing tools/frameworks for other programmers, you should leave reflection alone and program using interfaces, composition of objects and a minimum of inheritance.

Just one guy's opinion, though.

I occasionally use reflection to load plugins. It's still programming primarily with interfaces, but you need reflection to actually load an instance of the plugin class.

Sutherlands

@Jaime said:

@zelmak said:
To explain: I've always been of the opinion that, unless you're writing tools/frameworks for other programmers, you should leave reflection alone and program using interfaces, composition of objects and a minimum of inheritance.

Just one guy's opinion, though.
I occasionally use reflection to load plugins. It's still programming primarily with interfaces, but you need reflection to actually load an instance of the plugin class.

I must not be understanding you correctly.

dotnet-bot

Activator Class (System)

Contains methods to create types of objects locally or remotely, or obtain references to existing remote objects. This class cannot be inherited.

zelmak

@Sutherlands said:

@Jaime said:
@zelmak said:
To explain: I've always been of the opinion that, unless you're writing tools/frameworks for other programmers, you should leave reflection alone and program using interfaces, composition of objects and a minimum of inheritance.

Just one guy's opinion, though.

I occasionally use reflection to load plugins. It's still programming primarily with interfaces, but you need reflection to actually load an instance of the plugin class.
I must not be understanding you correctly.

dotnet-bot

Activator Class (System)

Contains methods to create types of objects locally or remotely, or obtain references to existing remote objects. This class cannot be inherited.

Quite nice ... is there a Java equivalent that you know of? I think that's what the original programmers were trying to do with the 'reflection' class...

Sutherlands

@zelmak said:

@Sutherlands said:
@Jaime said:
@zelmak said:
To explain: I've always been of the opinion that, unless you're writing tools/frameworks for other programmers, you should leave reflection alone and program using interfaces, composition of objects and a minimum of inheritance.

Just one guy's opinion, though.

I occasionally use reflection to load plugins. It's still programming primarily with interfaces, but you need reflection to actually load an instance of the plugin class.
I must not be understanding you correctly.

dotnet-bot

Activator Class (System)

Contains methods to create types of objects locally or remotely, or obtain references to existing remote objects. This class cannot be inherited.

Quite nice ... is there a Java equivalent that you know of? I think that's what the original programmers were trying to do with the 'reflection' class...

Hmmm, did I get my language wrong? It appears so. Very well. Found this for Java:

JDK 22 Documentation - Home

Not sure how that works, exactly... requires an instance, which you can get from NamedClass.class.getClassLoader... not sure how it works if you need to use it on a different class.

In fact, this might not be anything at all.

Jaime

@Sutherlands said:

@Jaime said:
@zelmak said:
To explain: I've always been of the opinion that, unless you're writing tools/frameworks for other programmers, you should leave reflection alone and program using interfaces, composition of objects and a minimum of inheritance.

Just one guy's opinion, though.

I occasionally use reflection to load plugins. It's still programming primarily with interfaces, but you need reflection to actually load an instance of the plugin class.
I must not be understanding you correctly.

dotnet-bot

Activator Class (System)

Contains methods to create types of objects locally or remotely, or obtain references to existing remote objects. This class cannot be inherited.

System.Activator is nothing but a thin wrapper on reflection. Some of the arguments on its methods are even types from the System.Reflection namespace. Also, the Wikipedia article for reflection has a two-line C# example; it uses Activator.CreateInstance.

zelmak

@Jaime said:

@zelmak said:
To explain: I've always been of the opinion that, unless you're writing tools/frameworks for other programmers, you should leave reflection alone and program using interfaces, composition of objects and a minimum of inheritance.

Just one guy's opinion, though.

I occasionally use reflection to load plugins. It's still programming primarily with interfaces, but you need reflection to actually load an instance of the plugin class.

Does this appreciably change my explanation? A plugin framework is a framework for plugin developers. QED?