[rules-users] question on drools and method calls on facts

[Greg Barton]

I have to disagree on one point.  Having fact classes with methods that modify the object in addition to the usual setters is not dangerous, it's called "encapsulation" or "information hiding" and is a common OO pattern.  Now, in the rules context, you have to inform the engine that the object has changed, but that's necessary when you call a setter as well.  In fact I think it's an advantage of Drools that you can use pojos in working memory and take advantage of OO design.

--- On Wed, 9/2/09, Wolfgang Laun <wolfgang.laun at gmail.com> wrote:

> From: Wolfgang Laun <wolfgang.laun at gmail.com>
> Subject: Re: [rules-users] question on drools and method calls on facts
> To: "Rules Users List" <rules-users at lists.jboss.org>
> Date: Wednesday, September 2, 2009, 1:30 AM
> It depends whether you are a purist, a
> pragmatist, or a maverick. A few random thoughts, and note
> that I consider myself a repenting pragmatist ;-)
> 
> Having fact classes with methods that modify the object in
> addition to
> the usual setters is dangerous; a toString() according to
> the
> convention is harmless.
> 
> 
> Even from a purist's point of view your list could be
> extended by "calls of methods to global objects",
> e.g., for communicating results to some GUI or whatever.
> 
> What is usually frowned at it the use of conditional
> statements on the RHS as going against the spirit of rule
> based programming.  
> 
> 
> If complex processing is required, hide it in some static
> methods of an utility class. It will make your rule code
> trimmer and slimmer, avoiding needless binding between the
> business logic part and implementation details.
> 
> 
> -W
> 
> 
> On Tue, Sep 1, 2009 at 11:02 PM,
> Garner, Shawn <Garner.Shawn at principal.com>
> wrote:
> 
> I'm under the impression that in the action clause of a
> rule you should only do one of the following:
> 
> 1) Set a property on a Fact
> 
> 2) Retract a Fact
> 
> 3) Insert (Assert) a new Fact
> 
> 4) Modify an existing Fact
> 
> 
> 
> However in some of the examples in the documentation it
> shows calling methods other than bean property getters and
> setters.
> 
> I was wondering if what other peoples opinions are on
> whether you should be doing more than the 4 things I listed
> above in a then clause of a rule.
> 
> 
> 
> Thanks,
> 
> SG
> 
> 
> 
> 
> 
> -----Message Disclaimer-----
> 
> 
> 
> This e-mail message is intended only for the use of the
> individual or
> 
> entity to which it is addressed, and may contain
> information that is
> 
> privileged, confidential and exempt from disclosure under
> applicable law.
> 
> If you are not the intended recipient, any dissemination,
> distribution or
> 
> copying of this communication is strictly prohibited. If
> you have
> 
> received this communication in error, please notify us
> immediately by
> 
> reply email to Connect at principal.com
> and delete or destroy all copies of
> 
> the original message and attachments thereto. Email sent to
> or from the
> 
> Principal Financial Group or any of its member companies
> may be retained
> 
> as required by law or regulation.
> 
> 
> 
> Nothing in this message is intended to constitute an
> Electronic signature
> 
> for purposes of the Uniform Electronic Transactions Act
> (UETA) or the
> 
> Electronic Signatures in Global and National Commerce Act
> ("E-Sign")
> 
> unless a specific statement to the contrary is included in
> this message.
> 
> 
> 
> While this communication may be used to promote or market a
> transaction
> 
> or an idea that is discussed in the publication, it is
> intended to provide
> 
> general information about the subject matter covered and is
> provided with
> 
> the understanding that The Principal is not rendering
> legal, accounting,
> 
> or tax advice. It is not a marketed opinion and may not be
> used to avoid
> 
> penalties under the Internal Revenue Code. You should
> consult with
> 
> appropriate counsel or other advisors on all matters
> pertaining to legal,
> 
> tax, or accounting obligations and requirements.
> 
> 
> 
> 
> 
> _______________________________________________
> 
> rules-users mailing list
> 
> rules-users at lists.jboss.org
> 
> https://lists.jboss.org/mailman/listinfo/rules-users
> 
> 
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>