classes and sub classes?

[Morten Guldager]

'Aloha Friends!

I'm about to write an API against a huge propitiatory Oracle based network
inventory database. The database have many different concepts stored in
it's tables, can one concept can span over multiple tables.

I would like to write a class for accessing each concept, but only have a
single database connection throughout the whole program.

I imagine some code along these lines, but cant figure out how to declare
the classes that will make it work:

# create a connection to the database and perform come basic login and
initialization
nib = NwInvDb("scott/tiger@ora")
# find a device by ip
interesting_device = nib.Device.lookup_by_ip("192.168.1.1")

In this example I access the concept Device.

Should I make the Device class inherit from NwInvDb? Or should I keep them
separate? Later on I think I will even have to make some sort of
sub-concepts, but lets postpone that game until I really have really seen
the need!

 

[Steven D'Aprano]

'Aloha Friends!

I'm about to write an API against a huge propitiatory Oracle based
network inventory database. The database have many different concepts
stored in it's tables, can one concept can span over multiple tables.

I would like to write a class for accessing each concept, but only have
a single database connection throughout the whole program.

Sounds reasonable.

I imagine some code along these lines, but cant figure out how to
declare the classes that will make it work:

# create a connection to the database and perform come basic login and
initialization
nib = NwInvDb("scott/tiger@ora")
# find a device by ip
interesting_device = nib.Device.lookup_by_ip("192.168.1.1")

What's "nib" mean? And "NwInvDb"? I can imagine that the "Db" at the end
stands for Database, but the rest is just word-salad. I can guess that
NwInvDb is some sort of database connection. Am I close?

In this example I access the concept Device.

Should I make the Device class inherit from NwInvDb? Or should I keep
them separate?

Why are you asking us? We don't know what functionality you expect NwInvDb
and Device to have, what they represent, or whether a Device can be
meaningfully considered an instance of a NwInvDb, whatever that is.

But given my *guess* that NwInvDb represents a database connection, and
that Device represents data fetched from that database, then no of course
you should not inherit. Inheritance implies an "is-a" relationship. If
you inherit from NwInvDb for Device, that implies:

- interesting_device Is-A database;

- anywhere you can use a NwInvDb database object, you can use
a Device object.

And the same would apply to every other concept in the database.

That does not sound like a clean and useful design to me.

 

[Morten Guldager]

On Tue, Apr 9, 2013 at 9:08 AM, Steven D'Aprano <

Sounds reasonable.


What's "nib" mean? And "NwInvDb"? I can imagine that the "Db" at the end
stands for Database, but the rest is just word-salad. I can guess that
NwInvDb is some sort of database connection. Am I close?

NwInvDb = NetworkInventoryDatabase, yes you are correct, it creates the
database handle and makes it ready for use.

In this example I access the concept Device.

Why are you asking us? We don't know what functionality you expect NwInvDb
and Device to have, what they represent, or whether a Device can be
meaningfully considered an instance of a NwInvDb, whatever that is.

But given my *guess* that NwInvDb represents a database connection, and
that Device represents data fetched from that database, then no of course
you should not inherit. Inheritance implies an "is-a" relationship. If
you inherit from NwInvDb for Device, that implies:

- interesting_device Is-A database;

which it is not.

- anywhere you can use a NwInvDb database object, you can use

a Device object.

which you can not.

And the same would apply to every other concept in the database.

That does not sound like a clean and useful design to me.

Good. I think I agree with you so far. Maybe that's why I'm asking, because
I'm not perfectly sure which path to follow to achieve what I want.

Yes, I need some sort of database connection instance, if it wasn't because
I later on will be needing to access both test and production database I
_could_ have made it global, even if we easily could agree that globals
suck most of the time!

The concept classes like the Device one, will be using the database
instance, I just don't know how to pass db into the concept class. - should
I do it explicit making constructors accept an argument? Like:

nib = NwInvDb("scott/tiger@ora")
dev = NwInvDb.Device(nib)
interesting_device = dev.lookup_by_ip("192.168.1.1")

 

[Jason Friedman]

NwInvDb = NetworkInventoryDatabase, yes you are correct, it creates the
database handle and makes it ready for use.

I am interested in opinions. I for one dislike abbreviations on the theory
that programs are read more than they are written. I would probably use
this variable name:

network_inventory_db_connection = ...

And yes, I'm aware that "db" is an abbreviation. I believe I am following
a few Zen principles:

Beautiful is better than ugly.
Explicit is better than implicit.
Readability counts.
Special cases aren't special enough to break the rules, Although
practicality beats purity.

What would others use?

 

[MRAB]

the database handle and makes it ready for use.

I am interested in opinions. I for one dislike abbreviations on the
theory that programs are read more than they are written. I would
probably use this variable name:

network_inventory_db_connection = ...

And yes, I'm aware that "db" is an abbreviation. I believe I am
following a few Zen principles:

Beautiful is better than ugly.
Explicit is better than implicit.
Readability counts.
Special cases aren't special enough to break the rules, Although practicality beats purity.

What would others use?

"network" could be abbreviated to "net", "inventory" to "inv" (maybe OK
in this context; in another context it could an abbreviation for
"inverse"), and "connection" to "con" (maybe), giving "net_inv_db_con",
or "net_inv_db_connection".

The trick, of course, is to make it clear, but not annoyingly long.
Python itself has "def", "len", and "lstrip", not "define", "length"
and "left_strip".

 

[Dennis Lee Bieber]

"network" could be abbreviated to "net", "inventory" to "inv" (maybe OK
in this context; in another context it could an abbreviation for
"inverse"), and "connection" to "con" (maybe), giving "net_inv_db_con",
or "net_inv_db_connection".

Of course, given both "net" and "con", it would be easy to read
"inv" as "inverse" -- if one interprets "net_db_con" to carry data
moving one direction, the inverse connection would be the return data
<G>

This may be one of those situations wherein the first use of the
name carries an explanatory comment.

 

[Peter Otten]

database handle and makes it ready for use.

I am interested in opinions. I for one dislike abbreviations on the
theory
that programs are read more than they are written. I would probably use
this variable name:

network_inventory_db_connection = ...

And yes, I'm aware that "db" is an abbreviation. I believe I am following
a few Zen principles:

Beautiful is better than ugly.
Explicit is better than implicit.
Readability counts.
Special cases aren't special enough to break the rules, Although
practicality beats purity.

What would others use?

inventory_db

The rest should be clear from the context.

 

[Neil Cerutti]

inventory_db

The rest should be clear from the context.

How long and descriptive a name is ought to depend on the
wideness of its visibility. n might be acceptable in a short
comprehension, while network_inventory_db_connection might be
apposite for a module-level name.