java RTTI n reflection

I feel this potentially powerful in GTD, but seldom tested in interviews.

[[thinking in java]] has a concise chapter on RTTI:

  • class object internals
  • class literals
  • new cast syntax, esp. useful in generic programming
  • dynamic proxies
  • dynamically created or hand-written null objects — a technique designed to save you the effort of checking nulls.

decorator quiz – subclassing by reflection

(See background below)
XR,
I agree with you that reflection, using dynamic proxy, can automatically redirect or wrap all 200 public methods, so CheckingAccount.java won’t look super long and needs no code change when Account.java adds methods. This does require that those 200 (public) methods are specified in an interface. This is usually not hard – just ask the Account.java author to create the interface and make Account.java implement it. Not possible if Account.java comes from a 3rd-party library.

More importantly, reflective subclass falls short on several fronts.
* Biggest shortfall — If base class Account.java has a public method printMe() that calls this.toString(), then a regular subclass can override toString() and it will be invoked by printMe(). Doesn’t work in reflective subclass. “this” is a kind of address in JVM, shared by both acct1 and checking1 in a regular subclass scenario. In the reflective case, checking1 has a different JVM address than acct1, so this.toString() can’t be intercepted by our proxy but goes through regular dynamic binding via virtual table.
* If Account has protected methods and fields, then a regular subclass can easily use them. Not so easy in reflective subclass.
* If Account has a final public field pf1, then in main(), we can say System.out.print(checking1.pf1) only if CheckingAccount is a regular subclass.
* We can cast checking1 from Account to CheckingAccount only for regular subclass

————————————
From: Tan, Bi
See if you have any good solution —

public static void main(...){
Account acct1 = getAccountFromDB(123);
CheckingAccount checking1 = new CheckingAccount (....); // Somehow create a CheckingAccount instance whose parent object is acct1.
... }

Account.java class already has 200 public methods. CheckingAccount.java should inherit all and override toString(). How?

AOP ] %% own lang

“crosscutting”, “concern” … are too abstract for many (SG, Indian,
Chinese) programmers I work with.

A “property” (related to “concern” and “aspect”) is a characteristic,
quality, personality of a class. A class can have 0 or more
properties.

AOP can implement interceptor, which is widely used for security, transaction etc.

Simple code eg 1: without AOP, adding a word “thread-safe” requires
additional code in many classes
[[ java reflection in action ]] P 175

Simple code eg 2: “serializable”

Simple code eg 3 of a property: “persistent”

code eg 4: perl AOP solution http://www.perl.com/pub/a/2007/04/12/lightning-four.html

,,proxy, intercession
[[ java reflection in action ]] P 74
solution for “property-implementation”

,,code gen
[[ java reflection in action ]] P 175

Method Object ^ Param Object

“Essential Java Style” is an excellent text on these 2.

In Both cases, the object is of an inner class. I think the MO need to access the enclosing class’s fields (attributes, properties, inst vars).

Both patterns are safe refactor operations, almost blind, robotic operations. I think a computer scientist can prove they won’t change behaviour/functionality. Therefore, these are more like implementation patterns than design patterns.

If there are x args to the original VLVU method, then the MO constructor gets exactly those x args, no more no less. All the original inst vars are still accessible from the composed methods in the MO (“inner”), and all original local/stack vars become MO attributes.

When to choose MO over PO? See P34. If after applying composed methods the VLVU method splits to 99 methods, then MO serves to group these many methods inside the inner class, whereas PO leaves them all in the enclosing class.

Note we go to such length just to avoid converting local/stack vars into fields. Such conversions contaminates the original class.

Q: how about a method with too many (55) args?
A: i think you can use an inner class or a regular bean to help build the arg list. Converting all args to attributes is the laziest and dirtiest solution.