Object design question (two, actually)

[Roger Bonine]

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

[John Saunders]

"Roger Bonine" <Ro*********@discussions.microsoft.com> wrote in message
news:6A**********************************@microsof t.com...

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
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.
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?
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?
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.

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

[Roger Bonine]

"John Saunders" wrote:

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

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).

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?

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.

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!

[solex]

Sounds like you would like to implement a proxy design pattern
http://c2.com/cgi/wiki?ProxyPattern.

Not really sure what you want to avoid in your second question, perhaps an
example would help me.

Warm Regards,
Dan
"Roger Bonine" <Ro*********@discussions.microsoft.com> wrote in message
news:6A**********************************@microsof t.com...

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

[John Saunders]

"Roger Bonine" <Ro*********@discussions.microsoft.com> wrote in message
news:56**********************************@microsof t.com...

"John Saunders" wrote:

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

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.

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).

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.

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

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.

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.

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

John Saunders

[Roger Bonine]

"John Saunders" wrote:

"Roger Bonine" <Ro*********@discussions.microsoft.com> wrote in message
news:56**********************************@microsof t.com...

"John Saunders" wrote:

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

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.

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).

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.

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

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.

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.

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

John Saunders

Thanks for your help!