OO Design

  • Thread starter Thread starter mavrick_101
  • Start date Start date
M

mavrick_101

Hi,

I'm writing an application for clubs. So I make a class called 'ClubsCS'.
Ideally I want to write a contructor where I would provide the ClubId and all
the related fields will be updated for that club, like club name, club
members, club flag etc. So I can use club properties for these attributes.

Would it be wise to have the same class provide functionality to add a new
Club? But if I write another contructor with no ClubId, would that be
confusing for other developers who may want to use the class. What if they
instantiate the class with a contructor with no clubid and expect to use the
club properties like clubName?

What would be a good design? should the same class provide functionality to
add new club and at the same time if the user provides a club id then provide
all the club properties? or should I write two sepearte classes each to serve
just one purpose?

Thanks
 
mavrick_101 said:
Hi,

I'm writing an application for clubs. So I make a class called 'ClubsCS'.
Ideally I want to write a contructor where I would provide the ClubId and
all
the related fields will be updated for that club, like club name, club
members, club flag etc. So I can use club properties for these attributes.

You don't have to write the constructor . I know you don't have to do it
with VS 2008, as along as you have public properties in the class, you can
do var clubs = new Clubs(ClubId = 1), without any constructor in the
class.
Would it be wise to have the same class provide functionality to add a new
Club? But if I write another contructor with no ClubId, would that be
confusing for other developers who may want to use the class. What if they
instantiate the class with a contructor with no clubid and expect to use
the
club properties like clubName?

So? They don't give anything in the constructor. So what? It would
clubs.ClubId = 1; and populate it that way.

You can also do this too.

var clubs = new Clubs
{
ClubID = 1,
Name = "Help"
};
What would be a good design? should the same class provide functionality
to
add new club and at the same time if the user provides a club id then
provide
all the club properties? or should I write two sepearte classes each to
serve
just one purpose?

One object Clubs.cs should be able to take care of itself with its own
properties and methods. The object should be able to persist itself to a
database, with corresponding methods of Add(), Update(), Get() or Delete().
It should also be able to provide a list of Clubs, like GetAllClubs().





__________ Information from ESET NOD32 Antivirus, version of virus signature database 4128 (20090603) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
 
mavrick_101 said:
Hi,

I'm writing an application for clubs. So I make a class called 'ClubsCS'.
Ideally I want to write a contructor where I would provide the ClubId and all
the related fields will be updated for that club, like club name, club
members, club flag etc. So I can use club properties for these attributes.

Would it be wise to have the same class provide functionality to add a new
Club? But if I write another contructor with no ClubId, would that be
confusing for other developers who may want to use the class. What if they
instantiate the class with a contructor with no clubid and expect to use the
club properties like clubName?

What would be a good design? should the same class provide functionality to
add new club and at the same time if the user provides a club id then provide
all the club properties? or should I write two sepearte classes each to serve
just one purpose?

Thanks

You should try to write the class so that it's not possible to create an
instance that is incomplete or unusable.

You don't need to use a constructor to provide functionality to add a
new club. You can use a static method that takes all the parameters
needed to create a club, and then either return the id of the newly
created club, or a ClubCS instance that is populated with all the data.
 
Back
Top