OO Design Debate

[Nate]

Scenario:

In a commerce application, there is a Product class. Along with the Product
class there is a form (the text that goes in the labels of the input
controls) for inputting and updating existing instances of existing Product
objects. We'll call the second a ProductForm. Both would be data-driven.

I view these as 2 distinct classes. Product and ProductForm. Where Product
contains the business end and ProductForm contains the presentation end.

My coworker vehemently disagrees with me on this. He believes they should
be in the same class since they deal with one object, the Product. And he
has good arguments.

So, we figure perhaps hearing arguments from outside experts would shed some
light on the subject. Things that we are considering is readability,
maintainability , accessibility, and scalability.

[Bruce Wood]

Nate wrote:

Scenario:

In a commerce application, there is a Product class. Along with the Product
class there is a form (the text that goes in the labels of the input
controls) for inputting and updating existing instances of existing Product
objects. We'll call the second a ProductForm. Both would be data-driven.

I view these as 2 distinct classes. Product and ProductForm. Where Product
contains the business end and ProductForm contains the presentation end.

My coworker vehemently disagrees with me on this. He believes they should
be in the same class since they deal with one object, the Product. And he
has good arguments.

So, we figure perhaps hearing arguments from outside experts would shed some
light on the subject. Things that we are considering is readability,
maintainability , accessibility, and scalability.

I don't want to misunderstand, here: Is ProductForm an instance of
Form? Is it an actual WinForms (or ASP.NET) form?

Or is it some class providing information to a generic form for
maintaining products?

All I can offer is the architecture I have used in my (small) WinForms
system: I have _three_ classes:

1. Product, which contains purely the business logic for a product. In
particular, Product does not permit any of its fields to have invalid
contents, nor does it permit invalid combinations of fields. So, every
Product is a valid product that you could use in the business.

2. ProductForm, which is the actual WinForms form:

public class ProductForm : Form { ... }

3. ProductValidato r, which is the "brains" behind ProductForm.
ProductValidato r tells ProductForm when fields should be enabled or
disabled, shown or hidden. It allows invalid values for the Product
fields, and returns nicely worded error messages to the ProductForm
whenever the user enters something invalid.

When ProductValidato r gives the thumbs up on user input, the calling
application can then ask it to return the Product instance
corresponding to the user inputs.

An important point here is that you don't really want all sorts of
heavy user input validation floating around with all of your Products
that you use day-to-day. Neither do you want those Products to be
allowed to contain invalid information, and force all of your business
logic to check myProduct.IsVal id at every turn. By splitting the user
input checking / validation out into a separate object I can create
simple Products that are only concerned with business rules and that
can never contain invalid information, which simplifies my business
layer.

Anyway, I'm not sure if that answered your question.

You may want to look into the "Model / View / Presenter" design pattern
for some industry standard avice on these points.

[Greg Young]

I will disagree with him (and recommend also recommend a look at the MVP/MVC
design patterns).

here are some reasons. btw I do not believe he is talking about form in the
context of a winform/webform ..

1) The product form can be re-used I don't need a new instance every time I
draw a screen

public class ProductForm {
private static ProductForm engish;
public static ProductForm English {
get { return english; }
}
//all product form behaviors .. I would also make ProductForm an
immutable object.
}

Product p = ProductReposito ry.GetProduct(S omeCriteria);
CreateViewFor(p , ProductForm.Eng lish)

This is a simple example .. more likely you would end up with a method that
takes culture to get the correct object (but you get the point).

By doing this we only create a new object for the product itself (and save a
good deal of memory by not continually re-creating all of the strings which
will remain the same).
2) The product form is not describing the product .. it is describing the
metadata for the editting interface for the product. These two items should
be able to differ independently (I should be able to have a product with a
different editting interface)

3) What if other business logic lets say logic in another class needs to
access product information (i.e. get a product object)? Kind of silly for it
to go through the overhead of also acquiring the the product form info (that
it will never use)

4) I under a number of circumstances might want to serialize a product (or
the information describing the product form) putting them together forces me
to serialize both (even if I only need one or the other)

5) as I mentioned I would make product form immutable, product would be
mutable ...

Cheers,

Greg Young
MVP - C#
http://geekswithblogs.net/gyoung

"Nate" <Na**@discussio ns.microsoft.co m> wrote in message
news:AD******** *************** ***********@mic rosoft.com...

Scenario:

In a commerce application, there is a Product class. Along with the
Product
class there is a form (the text that goes in the labels of the input
controls) for inputting and updating existing instances of existing
Product
objects. We'll call the second a ProductForm. Both would be data-driven.

I view these as 2 distinct classes. Product and ProductForm. Where
Product
contains the business end and ProductForm contains the presentation end.

My coworker vehemently disagrees with me on this. He believes they should
be in the same class since they deal with one object, the Product. And he
has good arguments.

So, we figure perhaps hearing arguments from outside experts would shed
some
light on the subject. Things that we are considering is readability,
maintainability , accessibility, and scalability.

[Joanna Carter [TeamB]]

"Nate" <Na**@discussio ns.microsoft.co m> a écrit dans le message de news:
AD************* *************** **...icrosof t.com...

| In a commerce application, there is a Product class. Along with the
Product
| class there is a form (the text that goes in the labels of the input
| controls) for inputting and updating existing instances of existing
Product
| objects. We'll call the second a ProductForm. Both would be data-driven.
|
| I view these as 2 distinct classes. Product and ProductForm. Where
Product
| contains the business end and ProductForm contains the presentation end.
|
| My coworker vehemently disagrees with me on this. He believes they should
| be in the same class since they deal with one object, the Product. And he
| has good arguments.
|
| So, we figure perhaps hearing arguments from outside experts would shed
some
| light on the subject. Things that we are considering is readability,
| maintainability , accessibility, and scalability.

From many years of experience "helping" "co-workers", I can honestly say,
this one is definitely wrong!

Although the Product and the form are dealing with the same type of thing,
they are dealing with different aspects of that thing.

As Bruce and Greg have both recommended, MVP is an ideal example of how the
UI should be separated from the business layer.

In MVP, the Model holds the Value, in this case a Product. It can also hold
a Command Set and a Selection, although this is more common when dealing
with lists of objects.

The View holds a reference to the UI element and "adapts" the UI control to
fit the requirements of being an Observer to the Value in the Model, so that
when the Value changes state, the View is notified and updates itself.

The Presenter hold both the Model and the View and is responsible for
creating the Observer relationship between them. The Presenter also holds
one or more Interactors, which are responsible for translating user
"gestures" (clicks, mouse moves, etc) in the UI into calls to the
Model/Value.

Following the MVP pattern, at least as I implement it, means that there is
absolutely *no* code on the form apart from that put there by the designer.

The benefits of designing applications using this "layering" technique is
that you would be able to replace anything to do with the UI without having
to touch your tried and tested business classes.

Having said all this, you'd better not tell your colleague about the idea of
creating Object Persistence Frameworks so that the database code is entirely
separate from the business class. He could have an apoplectic fit ! :-))

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[mail]

I would also suggest that I would architect my app to have a 'forms
manager' class that created forms, managed their hosting, and stood
between the UI and the Application Framework.

In simplified terms: The form would raise a new, changed, deleted etc.
event which would be caught by the form manager class that could then
refer the event data to a validator class - and if okay - raise a
request event back to the Application Framework for all its interested
listeners to respond to.

One of those Framework listeners would (in this example) be the Product
Manager (or it's relevant manager!), that would attempt to make the
requested product change.

When the request succeeded (or failed), the product manager would raise
an event that would be consumed by the forms manager and in turn
relayed back the UI. I would also make sure that all of this activity
was via versioned interfaces that would allow the maximum flexibility
in change of architecture and reuse of assemblies / classes. For
instance: the form data might in future come in via a web service call
from an internet source and that manager would want to follow the same
procedure as the UI forms manager. The product manager simply
implements its advertised IProductManager X interface. The losely
coupled publish and subscribe framework is the key to maximum
flexibility, in my opinion, and naturally encourages the use of mvc
type patterns.

[Alvin Bruney]

Yes, not to disagree with the others that the MVC (not MVP by the way) model
is the best, I'd take into account the scale and complexity of the app. If
it's a two line app what's the sense of the overkill with an MVC hammer? MVC
brings a level of complexity that can easily increase the burden of
maintainability on the project that may simple by unnecessary. On the other
hand, if you are building with some intention to scale or this is a
moderately sized app, then yes by all means.

--

_______________ _________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------

"Nate" <Na**@discussio ns.microsoft.co m> wrote in message
news:AD******** *************** ***********@mic rosoft.com...

Scenario:

In a commerce application, there is a Product class. Along with the
Product
class there is a form (the text that goes in the labels of the input
controls) for inputting and updating existing instances of existing
Product
objects. We'll call the second a ProductForm. Both would be data-driven.

I view these as 2 distinct classes. Product and ProductForm. Where
Product
contains the business end and ProductForm contains the presentation end.

My coworker vehemently disagrees with me on this. He believes they should
be in the same class since they deal with one object, the Product. And he
has good arguments.

So, we figure perhaps hearing arguments from outside experts would shed
some
light on the subject. Things that we are considering is readability,
maintainability , accessibility, and scalability.

[Joanna Carter [TeamB]]

"Alvin Bruney" <www.lulu.com/owc> a écrit dans le message de news:
OS************* *@TK2MSFTNGP03. phx.gbl...

| Yes, not to disagree with the others that the MVC (not MVP by the way)
model
| is the best,

The reason we use MVP is because it allows a greater variety of "points of
separation" between the business layer and the UI, depending on whether you
use WinForms or web UIs, thick or thin clients.

| I'd take into account the scale and complexity of the app. If
| it's a two line app what's the sense of the overkill with an MVC hammer?
MVC
| brings a level of complexity that can easily increase the burden of
| maintainability on the project that may simple by unnecessary. On the
other
| hand, if you are building with some intention to scale or this is a
| moderately sized app, then yes by all means.

I would certainly agree that MVC/P caould be overkill on very small
projects; FMPOV, the reason for covering it was to reinforce the "normality"
of separation of concerns between UI and business layers.

I have been designing and refining MVP for about 5 years now, first for
Delphi and now for .NET.

I am finding that .NET 2.0 generics, together with the data binding classes
provided in the framework, have encouraged me to greatly slim down the
amount of code in the MVP framework. The Binding class especially allows me
to remove the Observer pattern between the UI element and the business
object property.

I still use my slimmed down MVP as it allows me to remove all non-designer
code from form classes. This is the purpose of the Interactor part of MVP;
to hold the Binding and capture the Validating event, thus allowing
validation, etc to take place after the UI input but before the value gets
passed to the connected property. We set the DataSourceUpdat eMode to Never,
thus preventing automatic updating of the property unitl we are ready to
call WriteValue().

IMO, whatever technology you use, it is of paramount importance to be able
to remove all trace of business code from the UI, thus giving flexibility of
UI and protection of business logic.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Alvin Bruney]

>IMO, whatever technology you use, it is of paramount importance to be able

to remove all trace of business code from the UI, thus giving flexibility
of
UI and protection of business logic.
Yes, this is the nitty gritty of the matter. Well said.

--

_______________ _________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------

"Joanna Carter [TeamB]" <jo****@not.for .spam> wrote in message
news:uZ******** ******@TK2MSFTN GP02.phx.gbl... "Alvin Bruney" <www.lulu.com/owc> a écrit dans le message de news:
OS************* *@TK2MSFTNGP03. phx.gbl...

| Yes, not to disagree with the others that the MVC (not MVP by the way)
model
| is the best,

The reason we use MVP is because it allows a greater variety of "points of
separation" between the business layer and the UI, depending on whether
you
use WinForms or web UIs, thick or thin clients.

| I'd take into account the scale and complexity of the app. If
| it's a two line app what's the sense of the overkill with an MVC hammer?
MVC
| brings a level of complexity that can easily increase the burden of
| maintainability on the project that may simple by unnecessary. On the
other
| hand, if you are building with some intention to scale or this is a
| moderately sized app, then yes by all means.

I would certainly agree that MVC/P caould be overkill on very small
projects; FMPOV, the reason for covering it was to reinforce the
"normality"
of separation of concerns between UI and business layers.

I have been designing and refining MVP for about 5 years now, first for
Delphi and now for .NET.

I am finding that .NET 2.0 generics, together with the data binding
classes
provided in the framework, have encouraged me to greatly slim down the
amount of code in the MVP framework. The Binding class especially allows
me
to remove the Observer pattern between the UI element and the business
object property.

I still use my slimmed down MVP as it allows me to remove all non-designer
code from form classes. This is the purpose of the Interactor part of MVP;
to hold the Binding and capture the Validating event, thus allowing
validation, etc to take place after the UI input but before the value gets
passed to the connected property. We set the DataSourceUpdat eMode to
Never,
thus preventing automatic updating of the property unitl we are ready to
call WriteValue().

IMO, whatever technology you use, it is of paramount importance to be able
to remove all trace of business code from the UI, thus giving flexibility
of
UI and protection of business logic.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Kevin Spencer]

> Yes, this is the nitty gritty of the matter. Well said.

I agree about the nitty-gritty of the matter. I don't agree about the "well
said" part. It distresses me when someone answers a basic common-sense
architecture problem by suggesting a pattern. Patterns are all well and
good, but without an understanding of the simple underlying principles,
patterns are as useful to programming as Templates are to a Word document.
Using a pattern simplifies the process of high-level design of the app, but
it doesn't have the overall benefit of understanding the basic principle,
which applies at any level of the development process. On the other hand,
understanding the basic underlying principles of programming has a universal
effect on one's ability to develop solid applications.

Patterns grow out of principles, which apply to all aspects of development.
Simple principles like separation of UI from business logic, loose coupling,
etc, these are the meat and potatoes of good development. While one might
derive a pattern from a principle, it is nearly impossible to derive a
principle from a pattern.

Big things are made up of lots of little things. And complex things are made
up of lots of simple things. As the OP is obviously confused about some of
the basics, it would be best to start from there, and allow him to fully
digest that before moving on, in much the same way that learning calculus is
much easier if one has mastered arithmetic, then algebra, geometry, and
trigonometry, in that order.

--
IMHO,

Kevin Spencer
Microsoft MVP
Professional Development Numbskull

Nyuck nyuck nyuck
"Alvin Bruney" <www.lulu.com/owc> wrote in message
news:Ok******** ******@TK2MSFTN GP02.phx.gbl...

IMO, whatever technology you use, it is of paramount importance to be
able
to remove all trace of business code from the UI, thus giving flexibility
of
UI and protection of business logic.

Yes, this is the nitty gritty of the matter. Well said.

--

_______________ _________
Warm regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
Professional VSTO.NET - Wrox/Wiley
The O.W.C. Black Book with .NET
www.lulu.com/owc, Amazon
Blog: http://www.msmvps.com/blogs/alvin
-------------------------------------------------------

"Joanna Carter [TeamB]" <jo****@not.for .spam> wrote in message
news:uZ******** ******@TK2MSFTN GP02.phx.gbl...

"Alvin Bruney" <www.lulu.com/owc> a écrit dans le message de news:
OS************* *@TK2MSFTNGP03. phx.gbl...

| Yes, not to disagree with the others that the MVC (not MVP by the way)
model
| is the best,

The reason we use MVP is because it allows a greater variety of "points
of
separation" between the business layer and the UI, depending on whether
you
use WinForms or web UIs, thick or thin clients.

| I'd take into account the scale and complexity of the app. If
| it's a two line app what's the sense of the overkill with an MVC
hammer?
MVC
| brings a level of complexity that can easily increase the burden of
| maintainability on the project that may simple by unnecessary. On the
other
| hand, if you are building with some intention to scale or this is a
| moderately sized app, then yes by all means.

I would certainly agree that MVC/P caould be overkill on very small
projects; FMPOV, the reason for covering it was to reinforce the
"normality"
of separation of concerns between UI and business layers.

I have been designing and refining MVP for about 5 years now, first for
Delphi and now for .NET.

I am finding that .NET 2.0 generics, together with the data binding
classes
provided in the framework, have encouraged me to greatly slim down the
amount of code in the MVP framework. The Binding class especially allows
me
to remove the Observer pattern between the UI element and the business
object property.

I still use my slimmed down MVP as it allows me to remove all
non-designer
code from form classes. This is the purpose of the Interactor part of
MVP;
to hold the Binding and capture the Validating event, thus allowing
validation, etc to take place after the UI input but before the value
gets
passed to the connected property. We set the DataSourceUpdat eMode to
Never,
thus preventing automatic updating of the property unitl we are ready to
call WriteValue().

IMO, whatever technology you use, it is of paramount importance to be
able
to remove all trace of business code from the UI, thus giving flexibility
of
UI and protection of business logic.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Joanna Carter [TeamB]]

"Kevin Spencer" <ke***@DIESPAMM ERSDIEtakempis. com> a écrit dans le message
de news: %2************* ***@TK2MSFTNGP0 5.phx.gbl...

| I agree about the nitty-gritty of the matter. I don't agree about the
"well
| said" part. It distresses me when someone answers a basic common-sense
| architecture problem by suggesting a pattern.

My example of the MVP pattern was in order to demonstrate how separation of
concerns (the principle) can involve, not only two classes, but sometimes
more than you might expect.

| Patterns grow out of principles, which apply to all aspects of
development.
| Simple principles like separation of UI from business logic, loose
coupling,
| etc, these are the meat and potatoes of good development. While one might
| derive a pattern from a principle, it is nearly impossible to derive a
| principle from a pattern.

Precisely, but sometimes a concrete example can help to demonstrate a
principle.

| Big things are made up of lots of little things. And complex things are
made
| up of lots of simple things. As the OP is obviously confused about some of
| the basics, it would be best to start from there, and allow him to fully
| digest that before moving on, in much the same way that learning calculus
is
| much easier if one has mastered arithmetic, then algebra, geometry, and
| trigonometry, in that order.

The hope is, as we do in the Borland OO groups, that the OP would not stop
at asking one question, but would follow on if they don't understand with
further questions.

May I make the suggestion that a separate discussion group could be made
available on this forum for the discussion of basic and/or advanced
principles of OO design and practice ? That way it would be easier to
separate principles from hundreds of messages about everything from the
language to the framework.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer