A design question

  • Thread starter Thread starter Tony Johansson
  • Start date Start date
T

Tony Johansson

Hello!

If I want to store a product and remove a product on a file will it be
suitable to use two classes ?

One class for the actual product and
one class which is accessing the file and storing the passed object into the
file.


//Tony
 
IMHO, yes.

public class Product

public class ProductController
//Or ProductManager


You can see an example of this here:
 
Tony,

Imo not, a product is an entity, that entity has methods, but it still stays
the same entity.

Cor
 
Unless I misunderstood he just asked

"Shall I have a Product class, and a class for loading/storing its state in
a file"

Did you read the question differently, or are you saying he should put
persistence into the Product class?
 
Peter,

When I was reading it the first time, I probably have read a comma on a
different place (it is exactly there broken in my reader), now you point me
on it and I read it again, then I see it in another way. However I do not
see a reason for two classes in this. The product class can have its methods
doing the reading and writing. But you are right , as you tell that the
entity has nothing to do with it.

Cor
 
Hello!

If I want to store a product and remove a product on a file will it be
suitable to use two classes ?

One class for the actual product and
one class which is accessing the file and storing the passed object into the
file.

//Tony
Click to expand...

Hi
It depends of the design you are using. You can have a design where
the class Product just hold its basic data and you have another
classes (like Service) which take care of saving/Load operations. or
you can have method in the same class that takes care of that
 
If I want to store a product and remove a product on a file will it be
suitable to use two classes ?

One class for the actual product and
one class which is accessing the file and storing the passed object into
the file.
Click to expand...

I think this is basically a good idea, but unless you may need to store the
product in different formats, I say let the product be in control of its own
on-disc representation. In other words, let the product serialize itself.
Then all your "product writer" class worries about is opening, seeking, and
writing to the file. It will just ask the product to serialize itself and
then write the received bytes out.

All that said, I recently wrote something where there was a base object
which could be saved in either 1.0 or 2.0 format. In this case, I had a
formatter class for each output type which was responsible for creating the
byte stream to represent the object in that particular format.

So, as always, "it depends."
 
This is how I would see it and the choice comes down to your Project Brief.

Designing Objects with responsibilities has some advantages especially
around information expert and low coupling, but it becomes clumsy and when
it eventualy ends up doing everything has poor Cohesion. However creating a
Pure Fabrication for say storage will increase Cohesion and in my opinion
Coupling can be kept low by good use of interfaces / facade.

Below shows a layered approach with the model just a set of properties.
Interfaces have been left out its just to give an idea.

UI

M Business Logic Layer (Order
Handler)

O STORAGE STRATEGY

D Database Storage Strategy(DAL) File Storage Strategy
(FAL)

E ADO.NET Oracle.NET System.IO
System.XML System.Serialization

L


Alternative Model does the work.

UI

MODEL

ADO.NET Oracle.NET System.IO System.XML
System.Serialization


You can see the advantage of the Layer Structure immediately. Adding say a
product to a basket goes from UI code of (lets face it a user clicking on a
button rarely in USE CASE/ BLL terms just relates to storing an object for
the purpose of saving an object)

-load basket from storage
-add product to basket
-basket.Calculate Total
-basket.Calculate discounts
-basket .back to storage

and whetever else you would do

to a call to the BLL of

AddProductToBasket which then calls each seperate piece of code that
specializes in a funtion.

Not quite MVC but IMHO not that far off and it also reflects USE CASES so
testing the BLL can be done without the UI as in MVC.

The rule I tend to follow is the more complex you make any object the more
likely it is to fail, so small pockets of highly cohesive
objects/applications once unit tested are more likely to stand the test of
time. But obviously there is some development overhead, and very differing
opinions on this trust me. ;-)
 
Back
Top