class design questions

  • Thread starter Thread starter John Lee
  • Start date Start date
J

John Lee

Hi,

I was trying to find an elegant way of implementing/modelling the following
scenario:

student, borrower, reference and cosigner are all human beings - we would
think to create a person base class and then create one class for each of
the person type inheriting from person class - student is "IS-A" person, ...
but there is chances that the student and the borrower will be the same
person, how could we implement this in C#?

Any suggestions and tips will be greatly appreciated!

Thanks very much!
John
 
Just have one class called Person and depending on which collection they are
in, they are of that type. At some other place in your code you might have
a class called FinancialInstitution. This class might have properties that
point to some collections such as Students, Borrowers, References, and
Cosigners. That way a person object can be a part of the Students and
Borrowers collection. Without knowing more about your requirments, this is
the best that I can come up with. The idea being that inheritance does not
necessarily cause two objects to relate.

Try to think if there is a reason that you need to create a class for all
nouns because something you can implement a better architecture with
composition.
 
Can all students borrow?

If so Then have borrower, reference and cosigner (I'm not sure about
'reference' in terms of functionality) as derived from person and student
derived from borrower.

Are all Borrowers students?(Most cases this is not the case)

If so use the same solution as above but with student directly derived from
person and borrower derived from student.

Otherwise the solution I prefer is to have an abstract role class that
borrower, student, reference and cosigner are all derived from. The role
would then either point to the person or the person would have an array of
roles. Either way
 
Another way to do this would be to create a Person class with a bit coded
Roles poperty of type Role.
<flags()> Enum Role {student = 1, borrower = 2, reference = 4, cosigner =
8}.
Then you could just combine the roles you need with the & operator. Of
course you would need to do checks to ensure that a borrower is not their
own reference and other checks.

Robby
 
I would say interfaces.

If a person as you said is the base class, each type of person (student,
borrower) adds a certain (or many) functionalities to the person calss.
plus, if you say that a person can be a student, a borrower, both or
neither, that might be best since there is mutiple interface implementaions
but no multiple inheritance in this newsgroup.
 
Thanks very much!

The role concept might work well - a person could be a student and also a
borrower, so the person will be assigned to roles, either role will contain
role specific information, such as student role will contain
"schoolAssignedId".

I will look into this approach!

John
 
Take a look at the Decorator pattern.
http://www.dofactory.com/Patterns/PatternDecorator.aspx

Define your base 'person' class as an interface and inherit the concrete
class that implements the interface. For your 'student', 'borrower' etc
classes, inherit from the same base class and include a protected field
internally to a concrete person object. For each 'person' method in the
interface, pass the call through to the contained object. Handle other
calls yourself.

You get code reuse. You get the ability to add other methods. Yet, all
your objects derive from the same 'Person' class, you you can treat them the
same in your methods. For example, you could hold an arraylist that
contains 20 students, and 20 borrowers, and you can use the list as
containing simply 40 Person objects.

It is not perfect, but it is not bad either.

If you just can't stomach the idea of writing a bunch of methods that turn
around and call the same method on the contained class, you can split this
up. Create a Person class with basic functionality. Then create an
interface that simply defines a method that returns a Person object when a
particular method or property is called. All your other objects inherit
this interface. Their constructors would create the internal object and
each would define a method for returning the contained properties.

Your 'student' class wouldn't have access to the private and protected
members of the person class, but you would have less typing when defining
the class.

good luck,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
Back
Top