OO Design Debate

[Guest]

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]

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. ProductValidator, which is the "brains" behind ProductForm.
ProductValidator 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 ProductValidator 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.IsValid 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 = ProductRepository.GetProduct(SomeCriteria);
CreateViewFor(p, ProductForm.English)

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

 

[Joanna Carter [TeamB]]

"Nate" <[email protected]> a écrit dans le message de (e-mail address removed)...

| 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

 

[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 IProductManagerX 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

 

[Joanna Carter [TeamB]]

"Alvin Bruney" <www.lulu.com/owc> a écrit dans le message de (e-mail address removed)...

| 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 DataSourceUpdateMode 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

 

[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

 

[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

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

"Alvin Bruney" <www.lulu.com/owc> a écrit dans le message de (e-mail address removed)...

| 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 DataSourceUpdateMode 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]]

"Kevin Spencer" <[email protected]> a écrit dans le message
de %[email protected]...

| 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

 

[Azrael Seraphin]

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 ?

Excellent idea. I'm amazed that there isn't one already.

Azrael

 

[Frans Bouma [C# MVP]]

Excellent idea. I'm amazed that there isn't one already.

Well, there is, for years already. It's called comp.object.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Joanna Carter [TeamB]]

"Frans Bouma [C# MVP]" <[email protected]> a écrit dans le
message de news: (e-mail address removed)...

| Well, there is, for years already. It's called comp.object.

Ok, I just took a peek in there and found messages by a certain RDBMS zealot
who takes great delight in ruining any OO discussion by insisting that OO is
utter rubbish and that the whole world can be run with a non-OO RDBMS.
Anyone who disagrees, it seems, is not allow to discuss OO principles :-(
We, in the Borland groups, have already banned this guy for being too
disruptive.

Seeing as we in TeamB were responsible for his eviction, no, I don't think I
will take up that offer. However, I was thinking that it would be good to
have an OO design group here on the MS server that allowed folks to discuss
how OO design works in C#, or even VB, seeing that .NET is such a massive OO
framework.

Joanna

 

[Lebesgue]

"Frans Bouma [C# MVP]" <[email protected]> a écrit dans le
message de news: (e-mail address removed)...

| Well, there is, for years already. It's called comp.object.

Ok, I just took a peek in there and found messages by a certain RDBMS
zealot
who takes great delight in ruining any OO discussion by insisting that OO
is
utter rubbish and that the whole world can be run with a non-OO RDBMS.
Anyone who disagrees, it seems, is not allow to discuss OO principles :-(
We, in the Borland groups, have already banned this guy for being too
disruptive.

Seeing as we in TeamB were responsible for his eviction, no, I don't think
I
will take up that offer. However, I was thinking that it would be good to
have an OO design group here on the MS server that allowed folks to
discuss
how OO design works in C#, or even VB, seeing that .NET is such a massive
OO
framework.

Joanna

This RDBMS zealot is well known on the internet.. he is flaming everywhere.

I couldn't agree more, a group devoted to OO design on this server would be
a great thing to have. It seems every single topic goes to the
languages.csharp group, so having one explicitly aimed at OO principles
would be really great

 

[Frans Bouma [C# MVP]]

Ok, I just took a peek in there and found messages by a certain RDBMS
zealot who takes great delight in ruining any OO discussion by
insisting that OO is utter rubbish and that the whole world can be
run with a non-OO RDBMS. Anyone who disagrees, it seems, is not
allow to discuss OO principles :-( We, in the Borland groups, have
already banned this guy for being too disruptive.

hehe, yeah I admit, comp.object is a group which is erm... quite
hostile sometimes (as well as other comp.* newsgroups, like the lovely
newsgroup comp.databases.theory). But avoiding the filth there, you can
find some very good discussions.

Seeing as we in TeamB were responsible for his eviction, no, I don't
think I will take up that offer. However, I was thinking that it
would be good to have an OO design group here on the MS server that
allowed folks to discuss how OO design works in C#, or even VB,
seeing that .NET is such a massive OO framework.

I'll see if I can contact this newsserver admin and forward your
request.

Frans

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[james.curran]

Getting back to your original question, I agree with everyone else
here: You're right, your coworker is wrong. The best argument I have
for the separation is: What if you want to use Product in a console
application? or a WebForm app? Do you stuff the UI for all of those
into the one class?

 

[Alvin Bruney [MVP]]

i don't really agree that we need a separate group. it can be discussed here
as is and you can get real input from people who have intelligent opinions
but dont necessarily subscribe to OO newsgroups

--

________________________
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
-------------------------------------------------------

"Frans Bouma [C# MVP]" <[email protected]> a écrit dans le
message de news: (e-mail address removed)...

| Well, there is, for years already. It's called comp.object.

Ok, I just took a peek in there and found messages by a certain RDBMS
zealot
who takes great delight in ruining any OO discussion by insisting that OO
is
utter rubbish and that the whole world can be run with a non-OO RDBMS.
Anyone who disagrees, it seems, is not allow to discuss OO principles :-(
We, in the Borland groups, have already banned this guy for being too
disruptive.

Seeing as we in TeamB were responsible for his eviction, no, I don't
think I
will take up that offer. However, I was thinking that it would be good to
have an OO design group here on the MS server that allowed folks to
discuss
how OO design works in C#, or even VB, seeing that .NET is such a massive
OO
framework.

Joanna

This RDBMS zealot is well known on the internet.. he is flaming
everywhere.

I couldn't agree more, a group devoted to OO design on this server would
be a great thing to have. It seems every single topic goes to the
languages.csharp group, so having one explicitly aimed at OO principles
would be really great

 

[Azrael Seraphin]

Well, there is, for years already. It's called comp.object.

Let me rephrase that: Having an OO discussion group hosted on the Microsoft
newsgroups to discuss object oriented design and practice and how these
relate to and are implemented using C# and the .Net framework is an
excellent idea and I'm amazed that there isn't already a group for these
types of discussions.

The Delphi OO group Joanna discussed was a brilliant source of information
regarding OO design principles and their implementation using Delphi and the
VCL. Sure, OO design principles are generic and transcend languages and
frameworks, but in the end you have to implement your design in a language
and framework. There may be aspects of a framework that simplifies the
implementation of a certain OO design, such as the application blocks, that
warrants discussion of generic OO design in relation to a specific
language/framework.

The .Net framework itself is a huge implementation, example and repository
of OO design. A discussion group about OO design and C#/.Net would be
immensely valuable. I am particularly surprised that there isn't a Microsoft
hosted newsgroup about this given the focus of the Patterns and Practices
group at Microsoft.

Azrael

 

[Mark Wilden]

Not that anyone asked me, but I'd prefer this group be about C#. Not .NET,
not Windows programming, not OOP - but C#. As it is, only a minority of
messages are on-topic for the group's stated purpose.

///ark

 

[Joanna Carter [TeamB]]

"Alvin Bruney [MVP]" <www.lulu.com/owc> a écrit dans le message de (e-mail address removed)...

|i don't really agree that we need a separate group. it can be discussed
here
| as is and you can get real input from people who have intelligent opinions
| but dont necessarily subscribe to OO newsgroups

The problem with this group is the sheer volume of traffic, a lot of which
isn't really even about the C# language, the stated aim of this group. There
are other groups which support questions on the framework, databindings,
forms, etc but, as we find in the Borland groups, you need to police groups
quite strictly in order to direct folks to the appropriate group for their
questions.

The Borland OO design group is one of the groups for which I have special
responsibility and I try to ensure that it doesn't get used for anything
other than its stated purpose. I also keep an eye on the general and
language groups to try and pick up topics that would be better served in the
OO group, redirecting people there if necessary.

The result is a history of excellent, in-depth discussions that are archived
for future referral of new readers.

Joanna