{"id":2250,"date":"2023-12-14T14:01:40","date_gmt":"2023-12-14T13:01:40","guid":{"rendered":"https:\/\/oopm.org\/?page_id=2250"},"modified":"2025-01-24T11:12:39","modified_gmt":"2025-01-24T10:12:39","slug":"54-visibility-representative-elements-information-hiding","status":"publish","type":"page","link":"https:\/\/oopm.org\/?page_id=2250","title":{"rendered":"14. Representative and non-representative parts"},"content":{"rendered":"
\"image_pdf\"<\/a>\"image_print\"<\/a><\/div>\n

In this chapter, we discuss representative and non-representative parts of a program with respect to modeling a given domain.<\/p>\n\n\n\n

A primary focus of this book has been to emphasize that programming is modeling in the sense that programming is about creating a model of the relevant aspects of the application domain. This implies that one should attempt to represent descriptions of phenomena and their properties by corresponding language elements in the program.<\/p>\n\n\n\n

There will, however be elements in a given program that do not relate to phenomena or concepts from the application domain. This is due to the fact that it must be possible to execute the program on a computer. To do this, a program will have elements that implement the elements that relate to the model of the application domain.<\/p>\n\n\n\n

The part of the program that describes phenomena and concepts from the application domain is called the representative part.<\/em> The part which is not representative is called non-representative<\/em>.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Non-representative parts of class Account<\/code><\/h2>\n\n\n\n

In the following we consider class Account<\/code> in the bank domain with respect to representative and non-representative parts.<\/p>\n\n\n\n

\"\"
Representation of concepts and phenomena in the bank domain<\/figcaption><\/figure>\n\n\n\n

In the previous versions of Account<\/code> there is at a first glance no attributes that cannot be considered representative. All of owner<\/code>, balance<\/code>, interestRate<\/code>, deposit<\/code>, withdraw<\/code>, etc. are meaningful in the bank domain.<\/p>\n\n\n\n

We originally introduced assignments like:<\/p>\n\n\n\n

account_1010.balance := 523.07<\/code><\/pre>\n\n\n\n
and said that such an assignment may be considered a deposit on the account. And further assignments like:<\/p>\n\n\n\n
account_1010.balance := account_1010.balance + 200\naccount_1010.balance := account_1010.balance - 300<\/code><\/pre>\n\n\n\n
may also be considered deposits or withdrawals.<\/p>\n\n\n\n
However, we have methods\u00a0deposit<\/code>\u00a0and\u00a0withdraw<\/code>, which are supposed to represent deposits and withdrawals of money on the account. And from a\u00a0modeling point of view these conflict with assigning to\u00a0balance<\/code>\u00a0directly.<\/p>\n\n\n\n
In addition, there is more to a deposit<\/code> and withdraw<\/code> than just updating balance<\/code>. In section