OO class design question (logic placement)...

[Brad Pears]

Here is a simple OO design question...

I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then save a
"new" contract.

I have a method in my contract class called "Save" which is called like
this...

dim oContract as new Contract
objContract.Sav e(me.txtContrac tNo)

when the user clicks the 'Save" icon on the contract form.

As you can see from the above code, the contract number is a paramter of the
"Save" method.

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the save
operation or should it be left to the programmer to add logic to do this on
the form's save button?

I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.

I think that it makes the most sense to place that logic within the class -
then the programmer does not need to do any checking - as it will always be
done by the class "Save" method...

Does this makes sense??

Thanks Brad

[Spam Catcher]

Re: OO class design question (logic placement)...

"Brad Pears" <bradp@truenort hloghomes.comwr ote in
news:u1uiSAAxHH A.4612@TK2MSFTN GP04.phx.gbl:

My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a
new one?? WOuld this be placed in the Contract class that is handling
the save operation or should it be left to the programmer to add logic
to do this on the form's save button?

I would place the data inside the contact object. The contact object should
be aware of it's present state (i.e. new vs. update).

Take a look at LLBLGen Pro - it's DAL framework does this sort of thing.

[Mr. Arnold]

Re: OO class design question (logic placement)...

>
I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...
>
Does this makes sense??

The object should be able to set its state upon instantiate.

Upon the instantiation of the object, the object state is I am NEW, and I am
not DIRTY. I am not DIRTY, because no change has taken place within me.

If a change has taken place within me (the object), then I am marked DIRTY.

I the object will be OLD, if data from the database has populated me. I will
be DIRTY, because the database logic has populated me. I will be marked not
DIRTY.

I have another state called MARKED_FOR_DELE TION too.

1) Upon the instantiation of me (the object), my state will be NEW. I am
NEW no data from the database has populated me, so when I am saved, my data
will be added/inserted into the database.

2) Upon instantiation I (the object), I am NEW and not DIRTY, but data has
populated me so I am going to be marked as OLD and not DIRTY. When I am
saved, I am going to update the database with my data.


Oh, my Save method has been invoked.

What is my state me (the object)?

1) I am DIRTY some change as taken place with in me. If I am not DIRTY, then
don't do anything with me and ignore me.

2) I am NEW and DIRTY, so add my data to the database.

3) I am OLD and DIRTY, so update my data in the database.

Hey, I am none of that. I am MARKED_FOR_DELE TION.

1) If I am NEW and MARKED_FOR_DELE TION, don't do anything with me (the
object) as I have no data that needs to be deleted from the database.

2) If I am OLD and MARKED_FOR_DELE TION, I have data in the database so
delete my data.

Hey, me (the object) those could possibly be my states and how my Save
method might work.

[Daniel Bass]

Re: OO class design question (logic placement)...

Brad,

I'd suggest it's not really an OO question as much as general forms decision
making.

One approach is to vear from the other answers you have (although not to
contradict anything that's been said) and suggets that you split up the
concept of the Contract object and the Contract form.

The object understands how to load itself, save itself, and you could even
(for example) have a static method on the contract obect that checks whether
an instance of this object already exists.

The form simply gets data from the user and closes down once the form has
been "OK'd". From here, your code would query properties on the Contract
form object, passing them to a contract object. The final step is to call
save on the contract object, which decides whether it needs to create a new
object, update/overwrite to an existing object...

The File object works this way. There's the open dialog, save dialog, and
the File object.... When you open a file you first query what file is to be
opened using the file open dialog, and then use the file object's filename
property to open that file, read from it etc.


The second approach would be to simply use the data controls to build your
form, and use the view/edit/save funcationality that comes with the
gridview, databindernavig ator and so on...


It all depends the context of the application...


ASP.Net: http://www.ondotnet.com/pub/a/dotnet...spdatactl.html
Windows: http://www.codeproject.com/csharp/Bi...ndingNavCS.asp


"Brad Pears" <bradp@truenort hloghomes.comwr ote in message
news:u1uiSAAxHH A.4612@TK2MSFTN GP04.phx.gbl...

Here is a simple OO design question...
>
I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then save
a "new" contract.
>
I have a method in my contract class called "Save" which is called like
this...
>
dim oContract as new Contract
objContract.Sav e(me.txtContrac tNo)
>
when the user clicks the 'Save" icon on the contract form.
>
As you can see from the above code, the contract number is a paramter of
the "Save" method.
>
My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the save
operation or should it be left to the programmer to add logic to do this
on the form's save button?
>
I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.
>
I think that it makes the most sense to place that logic within the
class - then the programmer does not need to do any checking - as it will
always be done by the class "Save" method...
>
Does this makes sense??
>
Thanks Brad
>

[Brad Pears]

Re: OO class design question (logic placement)...

Very well written. Thanks for that... Make some sense now...

Thanks, Brad

"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
news:uDnYo7ExHH A.4464@TK2MSFTN GP02.phx.gbl...

>

>>
>I think that it makes the most sense to place that logic within the
>class - then the programmer does not need to do any checking - as it will
>always be done by the class "Save" method...
>>
>Does this makes sense??

>
The object should be able to set its state upon instantiate.
>
Upon the instantiation of the object, the object state is I am NEW, and I
am not DIRTY. I am not DIRTY, because no change has taken place within me.
>
If a change has taken place within me (the object), then I am marked
DIRTY.
>
I the object will be OLD, if data from the database has populated me. I
will be DIRTY, because the database logic has populated me. I will be
marked not DIRTY.
>
I have another state called MARKED_FOR_DELE TION too.
>
1) Upon the instantiation of me (the object), my state will be NEW. I am
NEW no data from the database has populated me, so when I am saved, my
data will be added/inserted into the database.
>
2) Upon instantiation I (the object), I am NEW and not DIRTY, but data
has populated me so I am going to be marked as OLD and not DIRTY. When I
am saved, I am going to update the database with my data.
>
>
Oh, my Save method has been invoked.
>
What is my state me (the object)?
>
1) I am DIRTY some change as taken place with in me. If I am not DIRTY,
then don't do anything with me and ignore me.
>
2) I am NEW and DIRTY, so add my data to the database.
>
3) I am OLD and DIRTY, so update my data in the database.
>
Hey, I am none of that. I am MARKED_FOR_DELE TION.
>
1) If I am NEW and MARKED_FOR_DELE TION, don't do anything with me (the
object) as I have no data that needs to be deleted from the database.
>
2) If I am OLD and MARKED_FOR_DELE TION, I have data in the database so
delete my data.
>
Hey, me (the object) those could possibly be my states and how my Save
method might work.

[Brad Pears]

Re: OO class design question (logic placement)...

Hmmm sounds intertesting enough...

I do have another question though...

You mentioned about having a static method on the contract object that
checks whether an instance of the object already exisits or not...
How would you code such a method?? How could you call this method if in
fact the object does not exist? ( I am assuming this is where the static
part comes in - I just don;t understand what you mean) Since I am very new
to OO design, I do not quite understand that one...

I do like the idea of having a property on the object once instantiated that
is the object's "state" which would indicate once the save button is hit
what should be done with the object ... i.e. save new, save existing,
delete me, do nothing etc.. as meniotned by the fellow who wrote the 2nd
response...

Thanks, Brad

"Daniel Bass" <danREMOVEbass@ blueCAPSbottle. comFIRSTwrote in message
news:ejoPRfHxHH A.3816@TK2MSFTN GP05.phx.gbl...

Brad,
>
I'd suggest it's not really an OO question as much as general forms
decision making.
>
One approach is to vear from the other answers you have (although not to
contradict anything that's been said) and suggets that you split up the
concept of the Contract object and the Contract form.
>
The object understands how to load itself, save itself, and you could even
(for example) have a static method on the contract obect that checks
whether an instance of this object already exists.
>
The form simply gets data from the user and closes down once the form has
been "OK'd". From here, your code would query properties on the Contract
form object, passing them to a contract object. The final step is to call
save on the contract object, which decides whether it needs to create a
new object, update/overwrite to an existing object...
>
The File object works this way. There's the open dialog, save dialog, and
the File object.... When you open a file you first query what file is to
be opened using the file open dialog, and then use the file object's
filename property to open that file, read from it etc.
>
>
The second approach would be to simply use the data controls to build your
form, and use the view/edit/save funcationality that comes with the
gridview, databindernavig ator and so on...
>
>
It all depends the context of the application...
>
>
ASP.Net: http://www.ondotnet.com/pub/a/dotnet...spdatactl.html
Windows: http://www.codeproject.com/csharp/Bi...ndingNavCS.asp
>
>
"Brad Pears" <bradp@truenort hloghomes.comwr ote in message
news:u1uiSAAxHH A.4612@TK2MSFTN GP04.phx.gbl...

>Here is a simple OO design question...
>>
>I have a Contract class. The user can either save an existing contract or
>they start off fresh with a blank contract, fill in the data and then
>save a "new" contract.
>>
>I have a method in my contract class called "Save" which is called like
>this...
>>
>dim oContract as new Contract
>objContract.Sa ve(me.txtContra ctNo)
>>
>when the user clicks the 'Save" icon on the contract form.
>>
>As you can see from the above code, the contract number is a paramter of
>the "Save" method.
>>
>My question is this... Where should the code be placed that actually
>determines whether we are saving an existing contract or creating a new
>one?? WOuld this be placed in the Contract class that is handling the
>save operation or should it be left to the programmer to add logic to do
>this on the form's save button?
>>
>I am thinking that it would be best to place this code in the Contract
>class. Basically the logic is that if the contract number being passed to
>the Save method is empty then we need to get the next available contract
>number and save the contract using that #. If the contract number being
>passed in has a value, then we will simply save the exisiting contract.
>>
>I think that it makes the most sense to place that logic within the
>class - then the programmer does not need to do any checking - as it will
>always be done by the class "Save" method...
>>
>Does this makes sense??
>>
>Thanks Brad
>>

>
>

[Brad Pears]

Re: OO class design question (logic placement)...

Where can I take a look at what you mentioned there - the LLBLGen Pro?

Thanks, Brad


"Spam Catcher" <spamhoneypot@r ogers.comwrote in message
news:Xns996AC27 708BD7usenethon eypotrogers@127 .0.0.1...

"Brad Pears" <bradp@truenort hloghomes.comwr ote in
news:u1uiSAAxHH A.4612@TK2MSFTN GP04.phx.gbl:
>

>My question is this... Where should the code be placed that actually
>determines whether we are saving an existing contract or creating a
>new one?? WOuld this be placed in the Contract class that is handling
>the save operation or should it be left to the programmer to add logic
>to do this on the form's save button?

>
I would place the data inside the contact object. The contact object
should
be aware of it's present state (i.e. new vs. update).
>
Take a look at LLBLGen Pro - it's DAL framework does this sort of thing.

[Rory Becker]

Re: OO class design question (logic placement)...

You mentioned about having a static method on the contract object that

checks whether an instance of the object already exisits or not...
How would you code such a method?? How could you call this method if
in
fact the object does not exist? ( I am assuming this is where the
static
part comes in - I just don;t understand what you mean)

It sounds like you are talking about the singleton pattern

In this case Static means Shared (Static is the c# keyword)

Thus:
-----------------------------------------------------------
Private Shared Singleton as SomeClass
Public Shared Function GetSingleton() as SomeClass
If Singleton is nothing then
Singleton = New SomeClass
Endif
return Singleton
End Function
-----------------------------------------------------------


--
Rory

[Rory Becker]

Re: OO class design question (logic placement)...

Where can I take a look at what you mentioned there - the LLBLGen Pro?

>

https://www.llblgen.com

--
Rory

[Brad Pears]

Re: OO class design question (logic placement)...

That was very well written. I had never thought of having a property 'State'
that is set for the object but I think it makes sense...

Basically what I have happeneing now is that the "Save" method on the
business class "contract" object calls an "update" method on the contract
"data class" object. ( I split the object so that I have a business object
"contract" and a data object "contract_data" ). This update method in turn
runs a stored procedure to do the job. The stored procedure itself
determines whether or not to "update" the data or "insert" the data. There
is a completely separate method to "delete" a contract which in turn runs a
stored procedure to specifically do just that...

So implementing a state property really doesn't buy me anything in this
instance BUT I do like the idea of having a state on every object and I
think it makes sense. Is this a common thing to have?? I have not seen a lot
of this in reading OO material or viewing OO design techniques/coding
techniques...

Thanks, Brad

"Mr. Arnold" <MR. Arnold@Arnold.c omwrote in message
news:uDnYo7ExHH A.4464@TK2MSFTN GP02.phx.gbl...

>

>>
>I think that it makes the most sense to place that logic within the
>class - then the programmer does not need to do any checking - as it will
>always be done by the class "Save" method...
>>
>Does this makes sense??

>
The object should be able to set its state upon instantiate.
>
Upon the instantiation of the object, the object state is I am NEW, and I
am not DIRTY. I am not DIRTY, because no change has taken place within me.
>
If a change has taken place within me (the object), then I am marked
DIRTY.
>
I the object will be OLD, if data from the database has populated me. I
will be DIRTY, because the database logic has populated me. I will be
marked not DIRTY.
>
I have another state called MARKED_FOR_DELE TION too.
>
1) Upon the instantiation of me (the object), my state will be NEW. I am
NEW no data from the database has populated me, so when I am saved, my
data will be added/inserted into the database.
>
2) Upon instantiation I (the object), I am NEW and not DIRTY, but data
has populated me so I am going to be marked as OLD and not DIRTY. When I
am saved, I am going to update the database with my data.
>
>
Oh, my Save method has been invoked.
>
What is my state me (the object)?
>
1) I am DIRTY some change as taken place with in me. If I am not DIRTY,
then don't do anything with me and ignore me.
>
2) I am NEW and DIRTY, so add my data to the database.
>
3) I am OLD and DIRTY, so update my data in the database.
>
Hey, I am none of that. I am MARKED_FOR_DELE TION.
>
1) If I am NEW and MARKED_FOR_DELE TION, don't do anything with me (the
object) as I have no data that needs to be deleted from the database.
>
2) If I am OLD and MARKED_FOR_DELE TION, I have data in the database so
delete my data.
>
Hey, me (the object) those could possibly be my states and how my Save
method might work.

[Spam Catcher]

Re: OO class design question (logic placement)...

"Brad Pears" <bradp@truenort hloghomes.comwr ote in
news:#iYGnQJxHH A.5028@TK2MSFTN GP04.phx.gbl:

So implementing a state property really doesn't buy me anything in
this instance BUT I do like the idea of having a state on every object
and I think it makes sense. Is this a common thing to have?? I have
not seen a lot of this in reading OO material or viewing OO design
techniques/coding techniques...

Yes, having a state is common.

In fact, it might be a good idea to update the state property whenever
the field changes :-)

For example:

Public Property MyProperty as String
Get
Return MyPropertyValue
End Get
Set(Byval value as string)
If value <MyPropertyValu e Then
Me.State = Enum.Dirty
End If

value = MyProperty
End Set

[Brad Pears]

Re: OO class design question (logic placement)...

Thanks, I will take a look see!

Brad

"Rory Becker" <RoryBecker@new sgroup.nospamwr ote in message
news:b0ac48a016 56f8c992b3b7018 020@msnews.micr osoft.com...

>Where can I take a look at what you mentioned there - the LLBLGen Pro?
>>

https://www.llblgen.com

>
--
Rory
>
>

[Brad Pears]

Re: OO class design question (logic placement)...

Ok, maybe I will get you to elaborate a bit on that code... just becasue I
don't want to second guess what you are doing being so new to this and
all... and I
like what you are proposing with updating the state whenever a property
changes...

In the line of code...
"me.state = Enum.dirty", what class is enum from ? Can you elaborate there a
bit?

Also, as far as the object states go - These are really the states I need to
worry about correct?
1) I am new so insert me
2) I am old and dirtry so update me
3) I am old and not dirty so ignore me
4) marked for deletion so delete me

Thanks, Brad


"Spam Catcher" <spamhoneypot@r ogers.comwrote in message
news:Xns996B77B A4B217usenethon eypotrogers@127 .0.0.1...

"Brad Pears" <bradp@truenort hloghomes.comwr ote in
news:#iYGnQJxHH A.5028@TK2MSFTN GP04.phx.gbl:
>

>So implementing a state property really doesn't buy me anything in
>this instance BUT I do like the idea of having a state on every object
>and I think it makes sense. Is this a common thing to have?? I have
>not seen a lot of this in reading OO material or viewing OO design
>techniques/coding techniques...

>
Yes, having a state is common.
>
In fact, it might be a good idea to update the state property whenever
the field changes :-)
>
For example:
>
Public Property MyProperty as String
Get
Return MyPropertyValue
End Get
Set(Byval value as string)
If value <MyPropertyValu e Then
Me.State = Enum.Dirty
End If
>
value = MyProperty
End Set
>

[Spam Catcher]

Re: OO class design question (logic placement)...

"Brad Pears" <bradp@truenort hloghomes.comwr ote in
news:#5zvL9JxHH A.276@TK2MSFTNG P06.phx.gbl:

In the line of code...
"me.state = Enum.dirty", what class is enum from ? Can you elaborate
there a bit?

You'll need to create your own list of enums for whatever states you want
to track (i.e. New, Update, etc).

Also, as far as the object states go - These are really the states I
need to worry about correct?
1) I am new so insert me
2) I am old and dirtry so update me
3) I am old and not dirty so ignore me
4) marked for deletion so delete me

Yes, that pretty much covers it.

[sloan]

Re: OO class design question (logic placement)...


You can read my take on it here:
http://sholliday.space s.live.com/Blog/cns!A68482B9628 A842A!139.entry

I believe in Controller or Manager classes to seperate the objects from the
code that saves/creates them.



"Brad Pears" <bradp@truenort hloghomes.comwr ote in message
news:u1uiSAAxHH A.4612@TK2MSFTN GP04.phx.gbl...

Here is a simple OO design question...
>
I have a Contract class. The user can either save an existing contract or
they start off fresh with a blank contract, fill in the data and then save

a

"new" contract.
>
I have a method in my contract class called "Save" which is called like
this...
>
dim oContract as new Contract
objContract.Sav e(me.txtContrac tNo)
>
when the user clicks the 'Save" icon on the contract form.
>
As you can see from the above code, the contract number is a paramter of

the

"Save" method.
>
My question is this... Where should the code be placed that actually
determines whether we are saving an existing contract or creating a new
one?? WOuld this be placed in the Contract class that is handling the save
operation or should it be left to the programmer to add logic to do this

on

the form's save button?
>
I am thinking that it would be best to place this code in the Contract
class. Basically the logic is that if the contract number being passed to
the Save method is empty then we need to get the next available contract
number and save the contract using that #. If the contract number being
passed in has a value, then we will simply save the exisiting contract.
>
I think that it makes the most sense to place that logic within the

class -

then the programmer does not need to do any checking - as it will always

be

done by the class "Save" method...
>
Does this makes sense??
>
Thanks Brad
>
>