Re: Object Orientation in VB.NET

Responding to Persophen...

You are really huge. Thank you so much for your serious approach and
professioinal thinking. I really appreciate all your time and effort.

I am not sure my being overweight is relevant here. B-)

That's what these forums are for. Besides, over the years I have accumulated an oversupply of opinions and I have to get rid of them somewhere.

I've got some further questions. The thing is that i Still will have to
implement the arraylist, because i would further parse the data on
tenants and rooms into the database tables. But in your option with 3
Relationships, I can't really see the way to implement the Students
arraylist. Because I used to implement it in the Dormitory class, now I
will have to implement it in the Rooms class?

Student here = Tenant from the original?


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

Actually, I forgot an important reason for needing R2. One might have need a specific ordering of the Students for sequential access when they are accessed through the Dormitory and ordering might be different than the one for sequential access of Rooms.

Anyway, R2, if needed, would <usually> be implemented as a collection class for Dormitory, just as you originally proposed.

The introduction of a database opens an entirely different can of worms. If (and it is a big IF, as I will get to in a moment) your OOA/D model maps directly to RDB tables on a 1:1 basis, the equivalent Data Model for the above would be:

[Dormitory]
+ dormID <--------+------------+
| |
[Room] | |
+ number | |
+ dormID ---------+ R1 |
+ tenantID | R2
| |
| |
| [Tenant] |
R3 +-----> + name |
+ roomNumber |
+ dormID ---------+

Since R1 and R2 are both 1:*, the referential attribute needs to be on the '*' side. For R3 it is <presumably> convenient to put the referential attribute on the Room side.

However, a cardinal rule of OO development is: solve the customer problem first and then worry about how to map that solution into persistence mechanisms. The reason is that OO solutions do not usually map 1:1 to RDB tables despite that fact that the relational data model underlies both views. The reason lies in different levels of abstraction and specific tailoring of the OO solution to a specific problem in hand. [For the situations where the mapping will be 1:1, usually CRUD/USER applications, RAD approaches are probably simpler to use. So one only uses OO techniques for more complex problems where persistence and UI are secondary concerns. In those case the specific problem-oriented OO view will likely be different than the generic data storage view of the RDB.]

My suspicion is that your problem is a rather simple academic problem so you can design the RDB tables to match the OO solution 1:1 as I did above. However, when that is not the case one usually wants to isolate the persistence access in a subsystem. Then that subsystem is responsible for providing the conversion rules between the two views (as well as the low-level muck like constructing SQL queries). That is, the interface to that subsystem is designed to accommodate the problem solution's needs (e.g., "I want to store this pile of data I call X so I can get it back later by asking you for X."). The subsystem's job is to convert such requests into appropriate SQL queries with the right Table/Attribute names.

There are a couple of reasons for doing that. Foremost is that the specific persistence mechanisms are invisible to the problem solution. That allows one to change the persistence mechanisms (to flat files, OODB, or clay tablets) without touching the problem solution logic in any way. (The subsystem's interface remains the same while its implementation is reworked.) Similarly, any changes to schemas and whatnot are completely hidden from the problem solution logic. That makes the problem solution much more robust over time.

A second value that is almost as important is separation of concerns. You are not distracted in developing the problem solution by a host of details (e.g., SQL syntax) that have nothing to do with the functional requirements. That makes life simpler and, consequently, the problem solution is more likely to be correct. Similarly, when writing the persistence access subsystem, one is concerned only with converting the interface requests into the RDB paradigm, not why the requests are made. That allows one to more easily recognize the invariants of persistence access, which simplifies the code. That, again, reduces opportunities for inserting defects.

<aside>
It's going a bit far afield but separation of concerns and the use of invariants leads to large scale reuse. The RDB paradigm is very well defined in terms of Schema/Table/Tuple/Atribute. That mathematical precision allows one to describe detailed context differences in terms of configuration data while encoding the paradigm invariants. Once one does that, then one can reuse the subsystem across different applications by simply supplying different configuration data to map identity in the interface to identity in the RDB. (In fact, this is pretty much what RAD IDEs do with the schemas.) Of course it requires more thinking to extract the invariants properly, but that extra effort is spread over multiple applications.
</aside>


*************
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



.

Quantcast