Chapter 11: Classes, Instances, and Message-Handlers

Chapter 11:

Classes, Instances, and Message-

Handlers

Expert Systems: Principles and Programming, Fourth Edition

Expert Systems: Principles and Programming, Fourth Edition 2

The Defclass Construct

• Before instances of classes can be created, CLIPS needs to know the list of valid slots for the given class.

• To provide this information, the defclass construct is used:

(defclass <class-name> [<optional-comment>]

(is-a <superclass-name>)

<slot-definition>*)


The Defclass Construct

• Note that <superclass-name> is the class from which the newly defined class will inherit information.

• All user-defined classes ultimately inherit from the system class USER.

• A user-defined class will therefore inherit from the USER class or from another user-defined class.


The Slot Definition

The syntax of the <slot-definition> is:

(slot <slot-name> <slot-attribute>* |

(multislot <slot-name> <slot-attribute>*)

type, range, cardinality, allowed-symbols

allowed-strings, allowed-lexemes, allowed-integers

allowed-floats, allowed-numbers, allowed-values

allowed-instance-names, default, and default-dynamic


Creating Instances

To create an instance of a class, use the make-instance command as follows:

(make-instance [<instance-name-expression>]

of <class-name-expression>

<slot-override>*)

where <slot-override> is:

(<slot-name-expression> <expression>)

Instances belong to the module in which their corresponding defclass is defined.


System-Defined Message-Handlers

• Just like data, procedural information can be attached to classes.

• Such procedures are called message-handlers.– User-defined

– System-defined – automatically created

• Message handlers can be invoked for an instance (object) using the send command.

(send <object-expression>

<message-name-expression> <expression>*)


System Message-Handlers

• For each slot defined in a defclass, CLIPS automatically defines get- and put-slot message-handlers that are used to retrieve and set slot values.

• The get-message-handlers have no arguments and return the value of the slot.

• The put-message-handlers take zero or more arguments. If not arguments are supplied, the slot is restored to its original default-value.


System Message-Handlers

• Supplying the arguments will set the slot value to those values.

• The return value of a put-message-handler is the new value of the slot.

• When slots are being watched, an informational message is printed whenever the value of an instance slot is changed.

• When instances are watched, an informative message appears when an instance is created/deleted.


The Definstances Construct

• The definstances construct is the equivalent of the deffacts construct.

• When a reset command is issued, all instances are sent a delete message.

• Then all instances found in the definstances constructs are created.


Definstances Construct

General format:

(definstances <definstances name> [active]

[<optional comment>]

<instance-definition>*)

Where <instance-definition> is:

([instance-name-expression>] of

<class-name-expression>

<slot-override>*)


Definstances Construct

• By default, pattern matching does not occur for definstances instances until all the slot overrides have been processed.

• Several commands exist for manipulating definstances:list-definstances – displays list of definstances maintained by CLIPS

ppdefinstances – displays text representations of definstances

undefinstances – deletes definstances

get-definstances-list – returns multifield value containing list of definstances


Classes and Inheritance

• One benefit of using COOL is class inheritance.

• Classes allow us to share common information among multiple classes w/o duplication of information or inclusion of unnecessary information.

• It is possible for a class to redefine a slot that was already defined by one of its superclasses.



• Definitions:– Subclass – class that inherits directly/indirectly from

another class

– Superclass – class from which subclass inherits

• A single-inheritance class hierarchy is one in which each class has only one direct superclass.

• A multiple-inheritance hierarchy (COOL) is where a class may have more than one direct superclass.



• The source slot attribute allows slot attributes to inherit from superclasses.

• The default value for the slot is exclusive – attributes determined by most specific class defining the slot.

– Single inheritance – the class having fewest superclasses

• Source slot composite, attributes not explicitly defined in most specific class defining slot are taken from next most specific that defines the attribute.



• It is possible to disable the inheritance of a slot using the propagation slot attribute:– Inherit (default) – slot will be inherited by subclasses

– No-inherit – slot will not be inherited by subclasses

• It is possible to define classes to be used only for inheritance – abstract classes; instances cannot be created – concrete by default.

• The role class attribute specifies whether a class is abstract or concrete.


Commands to Manipulate Defclasses

1. list-defclasses – displays the current list of defclasses maintained by CLIPS

2. browse-classes – displays the inheritance relationships between a class and its subclasses

3. ppdefclass – displays the text representation of a defclass

4. undefclass – deletes a defclass


Object Pattern Matching

• Single object pattern can match instances from several classes.

• Changes to slot values that are not specified in an object pattern do not retrigger the rule to which the pattern belongs.

• Changes to slot values that are not specified in an object pattern within a logical conditional element do not remove logical support provided by the associated rule.


Object Pattern

General format:

(object <attribute-constraint>*)

where <attribute-constraint> is:

(is-a <constraint>) |

(name <constraint>) |

(<slot-name> <constraint>*)

and <constraint> is the same as the pattern slot constraints that are used in deftemplate patterns.


Object Patterns

• One difference between object patterns and fact patterns is that only those object patterns that explicitly match on a slot are affected when the slot value of an instance is changed.

• It is possible to force a slot or a class not to participate in pattern matching using the pattern-match attribute.

• Object patterns and instance creation can be used in conjunction with the logical conditional element just as facts and facts patterns can.


Object Patterns

• Changes in instance slots do not affect the logical support for a fact or instance if the slot was not referenced in an object pattern within the logical conditional element.

• When using object patterns in a rule, CLIPS will sometimes use the initial-object/fact pattern. If so, an initial-fact pattern is added if the pattern preceding the insertion position is a fact pattern – if an object pattern an initial-object pattern is inserted.


User-Defined Message-Handlers

• In addition to print, delete, put, and get-system-defined message handlers, COOL automatically defines for each class, you can define your own message-handlers using defmessage-handler.

• General format:(defmessage-handler <class-name> <message-name>

[<handler-type>]

[<optional-comment>]

(<regular-parameter>*

[<wildcard-parameter>])

<expression>*)


User-Defined Message-Handlers

• By default, a message-handler is a primary message-handler.

• Each class has its own set of message-handlers.• The body of the message-handler, represented by

<expression>*, behaves like the body of a deffunction.

• The bind function can be used to bind local variables and the last expression evaluated in the body is the value returned.


Slot Shorthand References• A shorthand mechanism allows one to access the slots

of the instances bound to the ?self variable.• The expression: ?self:<slot-name> can be used to

retrieve the value of a slot.• Similarly, (bind ?self:slot-name <expression>*)

can be used to set a slot value.• Both bypass message-passing and directly manipulate

slots and can only be used for slots directly defined by the class.


Encapsulation

• COOL supports object encapsulation – Hiding the details of the class

– Limiting access to the class via a well-defined interface – message-handlers defined for the class

• If the visibility slot attribute is set to private (default), the slot can only be directly accessed by message-handlers of class defining it; if public, slot can be directly accessed by subclasses and superclasses defining it.


Watching Messages & Message Handlers

• If message-handlers or messages are watched with watch, informational messages are printed when a message-handler begins or ends execution.

• Defmessage-handler commands– list-defmessage-handlers – displays current list of

defmessage-handlers maintained by CLIPS

– ppdefmessage-handler – displays text representation of defmessage-handler

– undefmessage-handler – deletes a defmessage-handler

– get-defmessage-handler – returns multifield value containing list of defmessage-handlers for class


Slot Access and Handler Creation

• The access and create-accessor slot attributes control the access of slots.

• Access attribute restricts the type of access allowed to slots – read-write, read-only, initialize only.

• The create-accessor attribute controls the automatic creation of the get- and put-handlers for class slots – read-write, read-only, write-only, and none.


Before/After/AroundMessage-Handlers

• When an existing class does not meet your needs and may depend on other code to maintain its behavior – unfamiliar code or code you don’t want to modify.

• To get around this, you can define a new class that will inherit whatever behavior you want from the existing class.

• Message-handler can be one of four types: primary, before/after, and around.



1. Primary handler – (default) typically the main handler for responding to a message, overrides / shadows primary message-handler for same message inherited from a superclass.

2. Before/After handlers – invoked before and after the primary handler, respectively.

3. Around handlers – must explicitly invoke the other handler types.



4. #2 and #3 handlers of superclasses are now shadowed by subclass definition.

5. It is possible to override the arguments passed to a message-handler by using the override-next-handler command.


Handler Execution Order

• With all the available techniques to modify class behaviors, which is the best approach?

• A class can slightly modify the behavior of a superclass using before and after handler w/o overriding the primary handler.

• Subclass cannot prevent the execution of a before or after handler unless they terminate the message – preventing the execution of all before, after, and primary handlers.


Handler Execution Order

• If an existing class’s behavior is modified by redefining a new class and then overriding the primary handler, the primary handler is also subject to being overridden by a subclass.

• Unless the overriding class calls the call-next-handler function, the primary handler will not be executed.

• See page 670 of the text for steps.


Instance Creation, Initialization, and Deletion Message-Handlers

1. create -- is called after an instance is created but before any default values or slot overrides have been applied.

2. init – is called after slot overrides have been processed to set any remaining slot values that were not overridden to their default values

3. delete – either explicitly called to delete an instance or automatically called when you call make-instance and specify instance name of existing instance.


Modifying / Duplicating Instances

1. modify-instance – slot values are changed directly by the direct-modify message-handler w/o invoking message passing.

2. message-modify-instance – same as #1 but uses message-passing to change slot values.

3. active-modify

4. active-message-modify


Commands for Duplicating Instances

1. duplicate-instance

2. message-duplicate-instance

3. active-duplicate-instance

4. active-message-modify-instance


Instance Set Query Functions

1. Any-instancep function – if a set of instances is found that satisfy the query, then the any-instancep function returns the symbol TRUE; otherwise FALSE.

2. Find-instance query function – returns a multifield value containing the first instance set satisfying the query, then the multifield value will be empty.

3. find-all-instances function – returns a multifield value containing all instance sets satisfying the query.

4. Do-for-instance, do-for-all-instances, and delayed-do-for-all allow actions on the instance sets satisfying a query.


Multiple Inheritance

Specifying:– Single inheritance – a single class specified in the is-a

attribute

– Multiple inheritance – specify more than one class in the is-a attribute


Multiple Inheritance Conflicts

• The most practical examples involve cases where the superclass from which the class is inheriting do not share slots or message-handlers – no conflicts occur here.

• In simple cases where the classes specified in the is-a attribute do not share common user-defined superclasses, the order in which the classes are specified determines the precedence when there are multiple definitions of the same slot or message-handler.


Defclasses and Defmodules

• In a similar manner to other constructs, defclass constructs can be imported and exported by modules.

• The export and import statements previously discussed which export or import all constructs, also apply to defclasses.

• Explicit specifying which defclasses are exported or imported is possible.


Loading and Saving Instances

1. save-instances command – saves instances to a file

2. load-instances command – loads in a group of instances stored in a file

3. bsave- and boad-instances command – similar to #1 and #2, except binary format is used


Summary

• This chapter introduced the CLIPS Object-Oriented Language (COOL)

• Instances (objects) are another data representation provided by CLIPS.

• Instance attributes are specified using the defclass construct.

• Procedural code is implemented using the defmessage-handler construct.

• Inheritance allows classes to make use of slots and message-handlers associated with another class.


Summary

• COOL supports single- and multiple- inheritance.• In addition to the slot attributes provided with

deftemplates, several additional slot attributes are also supported by defclasses.

• Several predefined system message-handlers for creating, initializing, printing, and deleting instances are available.

• User-defined message-handlers can also be created.


Summary

• Message-handlers are invoked by sending an instance a message name along with associated arguments via the send command

• Object pattern matching provides several capabilities not found with fact pattern matching.

• Finally, COOL provides several instance set query functions that allow direct queries on sets of instances satisfying a specified set of conditions.

Documents

Chapter 11: Classes, Instances, and Message-Handlers