Content deleted Content added
Line 131:
! Frame terminology !! OO terminology
|-
| Frame || [[Class (computer programming)|Object class]]
|-
| Slot || Object property or [[Attribute (computing)|attribute]]
|-
| Trigger || Accessor and
|-
| Method (e.g. loom, KEE) || [[Method (computer programming)|Method]]
|}
The primary difference between the two paradigms was in the degree that [[Encapsulation (computer programming)|encapsulation]] was considered a major requirement. For the object-oriented paradigm encapsulation was one of, if not the most, critical requirement. The desire to reduce the potential interactions between software components and hence manage large complex systems was a key driver of object-oriented technology. For the frame language camp this requirement was less critical than the desire to provide a vast array of possible tools to represent rules, constraints, and programming logic. In the object-oriented world everything is controlled by methods and the visibility of methods. So for example, accessing the data value of an object property must be done via an accessor method. This method controls things such as validating the data type and constraints on the value being retrieved or set on the property. In Frame languages these same types of constraints could be handled in multiple ways. Triggers could be defined to fire before or after a value was set or retrieved. Rules could be defined that managed the same types of constraints. The slots themselves could be augmented with additional information (called "facets" in some languages) again with the same type of constraint information.
The other main differentiator between frame and OO languages was [[multiple inheritance]] (allowing a frame or class to have two or more superclasses). For frame languages multiple inheritance was a requirement. This follows from the desire to model the world the way humans do, human conceptualizations of the world seldom fall into rigidly defined non-overlapping taxonomies. For many OO languages, especially in the later years of OO, single inheritance was either strongly desired or required. Multiple inheritance was seen as a possible step in the analysis phase to model a ___domain but something that should be eliminated in the design and implementation phases in the name of maintaining encapsulation and [[modularity]].<ref>{{cite web|title=The Unified Modeling Language|url=http://www.essentialstrategies.com/publications/modeling/uml.htm|work=essentialstrategies.com|publisher=Essential Strategies Inc.|access-date=10 December 2013|year=1999|quote=In your author’s experience, nearly all examples that appear to require multiple inheritance or multiple type hierarchies can be solved by attacking the model from a different direction.}}</ref>
Although the early frame languages such as [[KRL (programming language)|KRL]] did not include [[message passing]], driven by the demands of developers, most of the later frame languages (e.g. Loom, KEE) included the ability to define messages on Frames.<ref>{{cite journal|last=Mettrey|first=William|title=An Assessment of Tools for Building Large Knowledge-Based Systems|journal=AI Magazine|year=1987|volume=8|issue=4|url=http://www.aaai.org/ojs/index.php/aimagazine/article/viewArticle/625|access-date=2013-12-09|archive-url=https://web.archive.org/web/20131110022104/http://www.aaai.org/ojs/index.php/aimagazine/article/viewArticle/625|archive-date=2013-11-10|url-status=dead}}</ref>
On the object-oriented side, standards have also emerged that provide essentially the equivalent functionality that frame languages provided, albeit in a different format and all standardized on object libraries. For example, the [[Object Management Group]] has standardized specifications for capabilities such as associating test data and constraints with objects (analogous to common uses for facets in Frames and to constraints in Frame languages such as Loom) and for integrating rule engines.<ref>{{cite web|last=Macgregor|first=Robert|title=Retrospective on Loom|url=http://www.isi.edu/isd/LOOM/papers/macgregor/Loom_Retrospective.html|work=isi.edu|publisher=Information Sciences Institute|access-date=10 December 2013|date=August 13, 1999|url-status=dead|archive-url=https://web.archive.org/web/20131025063241/http://www.isi.edu/isd/LOOM/papers/macgregor/Loom_Retrospective.html|archive-date=25 October 2013}}</ref><ref>{{cite web|title=OMG Formal Specifications|url=http://www.omg.org/spec/|work=omg.org|publisher=Object Management Group|access-date=10 December 2013}}</ref>
| |||