OO class design question (logic placement)...

  • Thread starter Thread starter Brad Pears
  • Start date Start date
B

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.Save(me.txtContractNo)

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
 
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?
Click to expand...

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.
 
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??
Click to expand...

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

1) If I am NEW and MARKED_FOR_DELETION, 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_DELETION, 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,

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, databindernavigator and so on...


It all depends the context of the application...


ASP.Net: http://www.ondotnet.com/pub/a/dotnet/2003/02/24/aspdatactl.html
Windows: http://www.codeproject.com/csharp/BindSourceBindingNavCS.asp
 
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
 
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)
Click to expand...

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
 
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
 
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...
Click to expand...

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 <> MyPropertyValue Then
Me.State = Enum.Dirty
End If

value = MyProperty
End Set
 
A static method can be called without having that object exist. A singleton
is something separate... Type "singleton skeet" in google to find some good
documentation by Jon Skeet on singletons and how to use them.

I was thinking something like thins

public class myObject

public shared function Exists(string objectName) as boolean
end function

... other methods

end class
 
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
 
In the line of code...
"me.state = Enum.dirty", what class is enum from ? Can you elaborate
there a bit?
Click to expand...

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
Click to expand...

Yes, that pretty much covers it.
 
A static method can be called without having that object exist. A
singleton is something separate... Type "singleton skeet" in google to
find some good documentation by Jon Skeet on singletons and how to use
them.
Click to expand...

However a singleton often uses a shared method in it's implementation as
I demonstrated.

My appologies.

I am familiar with the concepts of Singleton and Simple shared/static method.

However I didn't read enough (my lazyness) of the previous post to understand
the purpose of your shared/static method.

I therefore used a singleton to illustrate the use of *a* shared method.

My intent was not to re-explain "Exists" but to translate "static"

Again my appologies if anyone's understanding got caught in the crossfire. :)
 
Ok, next retarded question... How/where do I create these "enums" you are
referring to??

Thanks, Brad
 
Ok, next retarded question... How/where do I create these "enums"
you are referring to??
Click to expand...

An example of an enumeration:
-------------------------------------------------------------
Public Enum CleanOrDirty
Clean
Dirty
End enum

Public Sub X()
Dim Y as CleanOrDirty ' Defaults to Clean
Y = CleanOrDirty.Dirty
y = CleanOrDirty.Clean

if y = CleanOrDirty.Clean then
messagebox.Show("Y is Clean")
Endif

End Sub
 
Back
Top