At 02:53 PM 9/3/98 -0700, you wrote:
>It's immediately obvious to me why inheriting a defclass from a
>deftemplate is useful: you can make Beans appear to be subclasses of
>make-believe common ancestor classes without writing any Java code -
>i.e., the example I gave with the 'machine' class can be done with a
>deftemplate instead of a defclass; then Pump and Tank no longer need
>to have a common subclass, but you can group them together for the
>sake of pattern matching. It's very neat, actually - if the Beans have
>property names in common, then a common deftemplate 'superclass' can
>let you match on that shared property, even if the Beans are otherwise
>unrelated. I've modified things so that it behaves this way if the
>superclass is a defclass, as well.
>
I hadn't thought about this direction! In some respects this is similar to
a Java interface, and its use to recover an illusion of 'multiple inheritance'.
If the two classes/beans already extend other superclasses, you can
declare their implementation of an 'interface' defining their common
behavior. Then those classes can be referenced as instances of this
new type.
>In the other direction, I'm not sure it'd be as useful - the subclass
>deftemplates would lose the magical Java-connectedness of their parent
>defclass, which could be confusing.
>
>Hmm. Maybe, though, I can think of a shceme for creating hybrid
>objects which effectively let you add Jess-only properties to a
>defclassed Bean instance. Would that be useful or interesting?
>
>
I was thinking of the latter case. For example, I've created a 'Person' Java
bean that held attributes read from a database. Within the Jess rule set,
I wanted to add a Jess-only property called 'counted' so that I could flag
those persons that were counted, based on some selection criteria. A group
of rules would select and flag matched person objects. Then other rules
would be activated, based on presence of the 'counted' flag.
I ended up adding that property to the Java bean itself, but its purpose was
only for local use within the rule execution. So, a Jess-only property would
be a better match to my needs. This would be a better design if other Java
applications and/or rulebases used the Person object, but had no need for
the counted property. A pretty classic example of subclassing, but this is
an approach for defining a subclass locally within Jess.
Dave
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
