{"id":5895,"date":"2024-06-27T17:09:58","date_gmt":"2024-06-27T15:09:58","guid":{"rendered":"https:\/\/oopm.org\/?page_id=5895"},"modified":"2025-03-18T22:12:48","modified_gmt":"2025-03-18T21:12:48","slug":"17-1-adressable-aspect","status":"publish","type":"page","link":"https:\/\/oopm.org\/?page_id=5895","title":{"rendered":"18.1 Addressable aspect"},"content":{"rendered":"
\"image_pdf\"<\/a>\"image_print\"<\/a><\/div>\n

The fact that a number objects from different classes may be addressable is represented by defining a class Address<\/code>:<\/p>\n\n\n\n

class<\/strong> Address:\n   country: var<\/strong> String \n   town: var<\/strong> String\n   street: var<\/strong> String\n   streetNo: var<\/strong> Integer\n   print:\n      country.print\n      town.print\n      street.print\n      streetNo.print \n   change(newAddr: ref<\/strong> Address):\n      country := newAddr.country\n      town := newAddr.town\n      street := newAddr.street\n      streetNo := newAddr.streetNo<\/code><\/pre>\n\n\n\n
Address<\/code> objects have the data-items country<\/code>, town<\/code>, street<\/code>, and streetNo<\/code>. The address may be changed by the change<\/code> method, and it may be printed by the print<\/code> method.<\/p>\n\n\n\n
Customers being addressable is represented by Customer<\/code> objects having an Address<\/code> <\/mark>object:<\/p>\n\n\n\n
class<\/strong> Customer:\n   -\"-\n   addr: obj<\/strong> Address<\/code><\/pre>\n\n\n\n
The fact that a Customer<\/code> object has an addr<\/code> object as above implies that the attributes of the Address<\/code> object are “kind of attributes of the Customer<\/code> as well”, however, they are only indirect attributes as they have to be accessed through addr<\/code>, like e.g.<\/p>\n\n\n\n
aCustomer.addr.print<\/code><\/pre>\n\n\n\n
where aCustomer<\/code> is a reference to a Customer<\/code> object. The same would be the case inside the class Customer<\/code>:<\/p>\n\n\n\n
class<\/strong> Customer: Person\n   -\"-\n   addr: obj<\/strong> Address\n   ...\n   addr.print\n   ...<\/code><\/pre>\n\n\n\n
One could argue that for Address<\/code> to be an aspect of Customer<\/code>, the properties of Address<\/code> should be directly accessible and not via the name addr<\/code> of the part object. This would have been the case if Customer<\/code> had been a subclass of Address<\/code>, but that is obviously a wrong way to model this situation. A customer would typically be a type<\/em> of e.g. person and it will have<\/em> an address. From a modeling approach, a customer is not<\/em> an address, but a customer has<\/em> an address.<\/p>\n\n\n\n
The addr<\/code> object is a simple means to represent an aspect like address, as we use an already known mechanism of an intrinsic object (obj<\/code><\/strong>). However, it should be possible not only to apply a given aspect like Address<\/code> to any class of object, but also to tailor the aspect to the class to which it is applied.<\/p>\n\n\n\n
The print<\/code> method of Address<\/code> simply prints the address. If we also would like to print the name of the costumer, then we can not define addr<\/code> simply as an Address<\/code> object. <\/p>\n\n\n\n
The usual way of making the print<\/code> method so that it can be tailored in different Address<\/code> aspects of different classes or objects is to define it as a virtual method:<\/p>\n\n\n\n
class<\/strong> Address:\n   -:-\n   print:<\n      inner(print)  -- whatever to print from the class\/object that has\n                    -- an Address aspect\n      country.print\n      town.print\n      street.print\n      streetNo.print   <\/code><\/pre>\n\n\n\n
Instead of representing an Address<\/code> aspect just by an Address<\/code> object, the aspect is then rather represented by a singular intrinsic object with Address<\/code> as a superclass and with an extension of the virtual print<\/code>:<\/p>\n\n\n\n
class<\/strong> Customer: Person\n   -\"-\n   addr: obj<\/strong> Address\n      print::\n         name.print<\/code><\/pre>\n\n\n\n
Because print<\/code> is extended in the context of Customer<\/code>, i.e. nested in the description of Customer<\/code>, the name<\/code> data-item of Customer<\/code> is visible and can therefore be printed in the extension of print<\/code>.<\/p>\n\n\n\n
Aspects may typically be applied to more than one class. Here it is applied to class Bank<\/code>:<\/p>\n\n\n\n
class<\/strong> Bank:\n   name: var<\/strong> String\n   addr: obj<\/strong> Address\n      print::\n         name.print<\/code><\/pre>\n\n\n\n
In this case print<\/code> will print the name of the bank.<\/p>\n\n\n\n
Suppose that we have a class BankCustomer<\/code> that is subclass of Customer<\/code>:<\/p>\n\n\n\n
class<\/strong> BankCustomer: Customer\n   bankName: var<\/strong> String  -- the name of the bank \n                         -- where the bank customer is a customer<\/code><\/pre>\n\n\n\n
Suppose that we still want to represent the Address<\/code> as an aspect of Customer<\/code>, and<\/em> as an aspect of class BankCustomer<\/code>, but still so that the aspect is tailorable in both Customer<\/code>, in BankCustomer<\/code>, and in further subclasses of BankCustomer<\/code>. Then the above definition of addr<\/code> will not do; we vill then have to define the class of addr<\/code> by a virtual class AddrType<\/code>:<\/p>\n\n\n\n
class<\/strong> Customer: Person\n   class<\/strong> AddrType:< Address\n      print::<\n         inner(print)\n         name.print\n\n   addr: obj<\/strong> AddrType  \n\nclass<\/strong> BankCustomer: Customer\n   bankName: var<\/strong> String  \n   class<\/strong> AddrType::<\n      print::<\n         inner(print)\n         bankName.print<\/code><\/pre>\n\n\n\n
As the virtual class AddrType<\/code> is defined defined in the context of Customer<\/code>, the virtual print has access to the name<\/code> of Customer<\/code>, so name.print<\/code> will print the name<\/code> of the Customer<\/code>. Note that the print<\/code> method of AddrType<\/code> is an extension of print<\/code> in Address<\/code>, but still virtual (::<<\/code>) so that it can be further extended in the extension of AddrType<\/code> in BankCustomer<\/code>. This extension of AddrType<\/code> is defined in the context of BankCustomer<\/code>, and bankName<\/code> is therefore visible in the further extension of print<\/code>.<\/p>\n
\n\t\t<\/a>\n\t\t<\/div>","protected":false},"excerpt":{"rendered":"
The fact that a number objects from different classes may be addressable is represented by defining a class Address: Address objects have the data-items country, town, street, and streetNo. The address may be changed by the change method, and it may be printed by the print method. Customers being addressable is represented by Customer objects […]<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":3511,"menu_order":1,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-5895","page","type-page","status-publish","hentry"],"mb":[],"mfb_rest_fields":["title","gutenberg_elementor_mode"],"_links":{"self":[{"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/5895","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/oopm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5895"}],"version-history":[{"count":16,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/5895\/revisions"}],"predecessor-version":[{"id":11368,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/5895\/revisions\/11368"}],"up":[{"embeddable":true,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/3511"}],"wp:attachment":[{"href":"https:\/\/oopm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5895"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}