Object design question (two, actually)

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I'm working on a rewrite of our employee database. I plan to implement a
fairly heavyweight base class, which includes 20 or 30 fields, including
address and phone number collections and the like. (I'll use lazy init to
fill the collections when needed.) More specialized employee types would
inherit from the base class.

Sometimes, though, all I need is the employee name and ID number - for
example, when filling a DDL - and I hate to have all the overhead of creating
a heavyweight class object every time I want to look up an employee name by
ID. My question is: what's the best practice for doing very small lookups
like this? Should I create a small helper class, or use a lookup method in
the full class and just live with the overhead?

Along the same lines, I want to have an overloaded method that returns
various lists of employees (by role, active/inactive, etc). Do most people
feel that it breaks abstraction to have a method that returns multiple rows
in an object that represents a single entity? If so, where would a method
such as this live in the object hierarchy? I don't want to have to create
several classes for each separate type of object, but I want to do this the
right way.

Any thoughts would be appreciated..
 
Roger Bonine said:
I'm working on a rewrite of our employee database. I plan to implement a
fairly heavyweight base class, which includes 20 or 30 fields, including
address and phone number collections and the like. (I'll use lazy init to
fill the collections when needed.) More specialized employee types
would
inherit from the base class.

Sometimes, though, all I need is the employee name and ID number - for
example, when filling a DDL
Click to expand...

That sounds like a static GetEmployeeSummaries method, that returns a
collection of {ID, Name} tuples.
- and I hate to have all the overhead of creating
a heavyweight class object every time I want to look up an employee name
by
ID.
Click to expand...

This sounds like a different usage - look up a single employee by ID. That
_does_ sound like it's time to instantiate the full Employee object.
My question is: what's the best practice for doing very small lookups
like this? Should I create a small helper class, or use a lookup method
in
the full class and just live with the overhead?
Click to expand...

What overhead? I'd put it in the base class, to the extent that the base
class should understand the various sets of Employees. For instance, it
makes sense for a base Employee class to be able to enumerate all employees,
but it doesn't make sense for it to be able to enumerate some subset of
Employees where the criteria aren't held in the base class.
Along the same lines, I want to have an overloaded method that returns
various lists of employees (by role, active/inactive, etc). Do most
people
feel that it breaks abstraction to have a method that returns multiple
rows
in an object that represents a single entity?
Click to expand...

No, it doesn't break abstraction, because ...
If so, where would a method
such as this live in the object hierarchy? I don't want to have to
create
several classes for each separate type of object, but I want to do this
the
right way.
Click to expand...

.... because you need to have some sort of factory system. If you're going to
have multiple types of Employee, you're going to need a way to create the
correct derived class instance based on the data in the database. So, it
wouldn't break abstraction, because anything the base Employee class does
about creating lists of Employees would be in terms of the factory, which
could create whatever kind of employee was necessary.

On the other hand, you'll want to consider whether these lists of Employees
need to be lists of Employees, or whether they could be lists of
EmployeeSummary objects (ID, Name), from which the real Employee could be
retrieved if necessary. Hmm... Maybe the base Employee class could use lazy
init to load its 30 fields but always get the id and name?

John Saunders
 
John Saunders said:
This sounds like a different usage - look up a single employee by ID. That
_does_ sound like it's time to instantiate the full Employee object.
Click to expand...

By instantiate the full object, do you mean do a full Get(), or just have
some sort of LookupNameByID method? A full Get seems pretty wasteful if I
don't need most of the information. I was actually thinking of just
overriding ToString in this particular case, with overloads for the different
name types (LastFirst, etc).
What overhead? I'd put it in the base class, to the extent that the base
class should understand the various sets of Employees. For instance, it
makes sense for a base Employee class to be able to enumerate all employees,
but it doesn't make sense for it to be able to enumerate some subset of
Employees where the criteria aren't held in the base class.
Click to expand...

The overhead that I was concerned about is mostly having to declare the
member variables for the properties. If I have, say, 45 properties, I didn't
want to have to declare all of those member vars for no reason when I only
care about a couple of values. It may not be a big deal in the grand scheme
of things, but I just wasn't sure about the best practice.

Thanks for your help!
 
Roger Bonine said:
By instantiate the full object, do you mean do a full Get(), or just have
some sort of LookupNameByID method? A full Get seems pretty wasteful if I
don't need most of the information. I was actually thinking of just
overriding ToString in this particular case, with overloads for the
different
name types (LastFirst, etc).
Click to expand...

I misread your post. I thought you said "look up an employee", but I now see
that you said "look up an employee name".

No, just have a static Employee.GetNameByID(id) method, or something like
that.
The overhead that I was concerned about is mostly having to declare the
member variables for the properties. If I have, say, 45 properties, I
didn't
want to have to declare all of those member vars for no reason when I only
care about a couple of values. It may not be a big deal in the grand
scheme
of things, but I just wasn't sure about the best practice.
Click to expand...

Ok, now that I see that you were just talking about the name, forget I asked
that!

John Saunders
 
John Saunders said:
I misread your post. I thought you said "look up an employee", but I now see
that you said "look up an employee name".

No, just have a static Employee.GetNameByID(id) method, or something like
that.


Ok, now that I see that you were just talking about the name, forget I asked
that!

John Saunders
Click to expand...

Thanks for your help!
 
Back
Top