Re: Object Orientation in VB.NET

Responding to Persophen...

I have got a program where I should extensively implement
object-oriented features of the vb.net. I have got a class tenant and a
class room, both belong to some dormitory. In that dormitory class i
have 2 array lists to store objects of class tenant and room
respectively. In class tenant I created association with the class
room, so I may see in which room every tenant lives. However I did not
create association in the room class in order to avoid data
duplication.

So you have:

1 lives in *
[Dormitory] ---------------- [Tenant]
| 1 R2 + roomNumber
| exists in
|
| R1
|
| *
[Room]
+ number

where the R1 and R2 relationships are implemented with collection classes. R2's implementation is two-way, so you implement a back-reference in [Tenant] via roomNumber.


Instead if I want to lookup which tenant lives in some particular room,
I first get the room number from the rooms array list and then I lookup
the same room no in the tents list and retrieve the corresponding
tenant's name.

The problem is that to solve the problem you need to know which Tenants live in which Rooms. So there is definitely a relationship between [Room] and [Tenant] that is relevant to solving the problem in hand. Without it you end up with an inefficient solution because every time you want to find the Tenant for a particular Room, you have to search the entire R2 collection of Tenants.

Your concern is duplication of information, but you can get around both problems easily be reorganizing the relationships:

[Dormitory]
| 1
| exists in
|
| R1
|
| *
[Room]
+ number
| 1
| lives in
|
| R3
|
| 1
[Tenant]

In fact, we have eliminated one of the collections entirely. Note that you also no longer need to have the room number in [Tenant].


I am not sure whether this approach is fine, anyway it provides me info
I need. But I am not sure whether it is object oriented enough? Should
I create an association to tenant class in the room class?

You may still need the R2 collection for other aspects of the problem. (Presumably finding the tenant of a given room is not the only requirement that the application addresses.) That's fine because the relationships capture quite different rules about the structure of the problem space, which is reflected in the multiplicity here:

1 lives in
[Dormitory] ----------------+
| 1 |
| exists in |
| |
| R1 |
| |
| * |
[Room] | R2
+ number |
| 1 |
| lives in |
| |
| R3 |
| |
| 1 |
[Tenant] ------------------+
*

Basically this says that in the problem context one wants to access the tenants of a dormitory without caring about which room they live in.

Someone told me that class should be a complete entity and hold all the
info it is supposed to hold. I would like to get your opinion in that.

The statement is correct, so far as it goes. However, one needs to abstract the problem space to suit the particular problem in hand. The issue here is not really about information; it is about what relationships exist among entities in the problem space.

When in doubt identity all the relationships that could possibly be useful to solving the problem first. Then you can prune them based upon the specific context. For example, the R2 relationship is not necessary if one just needs to "walk" a list of all Tenants of a Dormitory. One can navigate R1 -> R3 by "walking" the list of Rooms and, for each Room, navigating the R3 relationship. One only needs the R2 relationship for <unlikely but conceivable> run time efficiency, because the set of Tenants reached via R2 is different than that reached via R1 -> R3 (e.g., staff have separate accommodations from those in <student> Rooms), or the context of accessing dormitory tenants directly is so important to the problem that it warrants highlighting in the design.

BTW, your original solution is very much like a Data Modeling solution. That leads to Tenant.roomNumber and the search. However, in the OO paradigm one tends to do things differently. That becomes most clear if there are multiple instances of [Dormitory]. In the Data Modeling world one would instantiate the relationships at the class (table) level but in an OO application R1 and R2 would typically be instantiated at the object level. Among other things, that eliminates the need to explicit referential identity attributes.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.