newbie style question

  • Thread starter Thread starter gazza67
  • Start date Start date
G

gazza67

Hi Everyone,

I have two quick questions about programming style for oo programming.
i guess they are probably generic questions but as i am only interested
in c# i thought i would post here.

I have written an application, it has a main form with a menu and one
of the menu items allows me to create a car object. When I select this
option a dialog window comes up with a series of options that let me
set the characteristics of the car object that I will create.

1. where should u call the constructor for the car - should it be in
the create car dialog code or should it be in the mainscreen code?

2. the list of characteristics for a car is growing longer than i first
thought. i am having to pass more and more parameters to the contructor
code and it is starting to look ugly (ie there are so many parameters
to pass). Is there an alternative to having many params being passed to
a constructor - and if so, at what point should I start to look at
these alternative.

Thanks in advance,

Gary
 
Hi,

1. If you want the form to be more "generic", and to be able both
create and modify the car object, the best way is to define a property
in the form that will be set by the caller (exisiting instance, or
newly created one - using empty c'tor), and contain an instance of the
car class, the form will "bind" the controls to the propetries of this
class (using build in binding mechanism or manually).

2. Use empty constructor and properties for setting the values.

Hope it helped.
 
1. where should u call the constructor for the car - should it be in
the create car dialog code or should it be in the mainscreen code?

To reply to your first question I picked up the following pattern when I saw
it and would recommend it to others.

As an example:

public class CarForm:Form
{
private TextBox txtName = new TextBox();
public CarForm()
{
// inits and places the textbox somewhere
}

public string Name
{
get{return txtName.Text;}
}

// there also needs to be code to handle the dialog result
}

// in code
// create new car

CarForm cf = new CarForm();
if(cf.ShowDialog() == DialogResult.OK)
{
Car car = new Car(cf.Name);
}

So no code is in the CarForm apart from the properties and the DialogResult
handling.
As it should be. :)

HTH

Simon
 
2. the list of characteristics for a car is growing longer than i first
thought. i am having to pass more and more parameters to the contructor
code and it is starting to look ugly (ie there are so many parameters
to pass). Is there an alternative to having many params being passed to
a constructor - and if so, at what point should I start to look at
these alternative.

In addition to other suggestions, you might want to look at a sort of
CarSettings class or enum that specifies all the options. You can then build
that class, set its properties, and pass it into a Car constructor. I'd look
at that when either the number of parameters and overloads got terrible(8+)
or if I was using a factory that had to decide the specific subclass of car
based on the parameters you pass.

I'm not a big fan of building a Car and setting its properties because you
end up with multiple points of faliure and to much risk of requiring
specific order of operations. A Car with bad state due to setting various
properties might cause a problem down the road and there is really no way to
ensure the state is valid without doing a check after ever assignment(and
potentially exceptions after every assignment). By passing a single object
containing all of your settings to a constructor or factory method, you can
author a single code point that validates settings instead of having it
happen at some point in the future.
 
I tried:

MyCar mc= MyCar.GetInstance(v8,50mpg,
0toGo.<5seconds,
Style.Convertible,
Seating.8)

returned null

:)

Regards,
Jeff
A Car with bad state due to setting various
properties might cause a problem down the road and there is really no
way to
ensure the state is valid without doing a check after ever
assignment(and
potentially exceptions after every assignment).<
 
Back
Top