By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,694 Members | 2,121 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,694 IT Pros & Developers. It's quick & easy.

OO Design Debate

P: n/a
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.
Jun 2 '06 #1
Share this Question
Share on Google+
34 Replies


P: n/a

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

Jun 2 '06 #2

P: n/a
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

"Nate" <Na**@discussions.microsoft.com> wrote in message
news:AD**********************************@microsof t.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.

Jun 3 '06 #3

P: n/a
"Nate" <Na**@discussions.microsoft.com> a écrit dans le message de news:
AD**********************************@microsoft.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
Jun 3 '06 #4

P: n/a
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.

Jun 3 '06 #5

P: n/a
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**@discussions.microsoft.com> wrote in message
news:AD**********************************@microsof t.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.

Jun 3 '06 #6

P: n/a
"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 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]
Consultant Software Engineer
Jun 4 '06 #7

P: n/a
>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**************@TK2MSFTNGP02.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 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]
Consultant Software Engineer

Jun 4 '06 #8

P: n/a
> 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**************@TK2MSFTNGP02.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**************@TK2MSFTNGP02.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 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]
Consultant Software Engineer


Jun 5 '06 #9

P: n/a
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> a écrit dans le message
de news: %2****************@TK2MSFTNGP05.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
Jun 5 '06 #10

P: n/a

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:OK*************@TK2MSFTNGP05.phx.gbl...
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
Jun 6 '06 #11

P: n/a
Azrael Seraphin wrote:

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:OK*************@TK2MSFTNGP05.phx.gbl...
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.


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#)
------------------------------------------------------------------------
Jun 6 '06 #12

P: n/a
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: xn***************@news.microsoft.com...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer
Jun 6 '06 #13

P: n/a

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:eh****************@TK2MSFTNGP02.phx.gbl...
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: xn***************@news.microsoft.com...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer


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
Jun 6 '06 #14

P: n/a
Joanna Carter [TeamB] wrote:
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans
le message de news: xn***************@news.microsoft.com...
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.


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#)
------------------------------------------------------------------------
Jun 6 '06 #15

P: n/a
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?
Nate wrote:
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.


Jun 6 '06 #16

P: n/a
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
-------------------------------------------------------

"Lebesgue" <le******@gmail.com> wrote in message
news:et****************@TK2MSFTNGP02.phx.gbl...

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:eh****************@TK2MSFTNGP02.phx.gbl...
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: xn***************@news.microsoft.com...

| 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

--
Joanna Carter [TeamB]
Consultant Software Engineer


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

Jun 7 '06 #17

P: n/a
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> wrote in message
news:xn***************@news.microsoft.com...
Azrael Seraphin wrote:
"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:OK*************@TK2MSFTNGP05.phx.gbl...
> 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.


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
Jun 7 '06 #18

P: n/a
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
Jun 7 '06 #19

P: n/a
"Alvin Bruney [MVP]" <www.lulu.com/owc> a écrit dans le message de news:
O0**************@TK2MSFTNGP03.phx.gbl...

|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

--
Joanna Carter [TeamB]
Consultant Software Engineer
Jun 7 '06 #20

P: n/a
"Mark Wilden" <Ma********@newsgroups.nospam> a écrit dans le message de
news: On**************@TK2MSFTNGP04.phx.gbl...

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

Certainly would be nice to see.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Jun 7 '06 #21

P: n/a
V
A lot has been said already... but i couldn't help giving my two bits
for the question.

Summary: The two are separate classes PERIOD.

Reason:
1. your UI may be a Web Form instead of Windows, and the Product class
does not have to change.
2. your Product class may be exposed through a web service for data
transfer between distributed systems, but the ProductForm will probably
not.
3. Your ProductForm class is just a consumer of the Product Class in a
manner of speaking and not the Product itself.
4. Product is the entity in the system, and not the ProductForm.

It would be good to hear your co-worker's arguments on this.

Also, to get a good idea on OO Design (and specifically for .Net also)
I recommend two resources:
1. Object Oriented Analysis and Design - Grady Booch -> good for
understanding OO concepts
2. CSLA.Net - Rockford Lhotka (www.lhotka.net) -> Good coverage of OO
Concepts and their relevance to .Net Programming

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


Jun 7 '06 #22

P: n/a
+1

--
Saad Rehmani / Prodika / Dallas / TX / USA
"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:OK*************@TK2MSFTNGP05.phx.gbl...
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

Jun 7 '06 #23

P: n/a
Saad Rehmani wrote:
+1


I've asked through my MVP lead for this newsgroup, it's now a matter
of 'if they think it's necessary it will be made available' ;)

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#)
------------------------------------------------------------------------
Jun 8 '06 #24

P: n/a
So, what we're really waiting for at this point is for Microsoft to let us
know whether they consider design important or not.

Given some of the stuff they've been doing in the p&p group and the overall
direction, one would hope this decision is a no-brainer ...

I wonder if DSL / MDD vs. DDD types of discussions will be included.

This could be fun :)

Waiting ...
--
Saad Rehmani / Prodika / Dallas / TX / USA
Saad Rehmani wrote:
+1

I've asked through my MVP lead for this newsgroup, it's now a matter
of 'if they think it's necessary it will be made available' ;)

FB

Jun 8 '06 #25

P: n/a
Mmmm I hope so too !!!!

If not there are occasionally some on the architecture forum :)

Cheers,

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

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
So, what we're really waiting for at this point is for Microsoft to let us
know whether they consider design important or not.
Given some of the stuff they've been doing in the p&p group and the
overall direction, one would hope this decision is a no-brainer ...

I wonder if DSL / MDD vs. DDD types of discussions will be included.

This could be fun :)

Waiting ...
--
Saad Rehmani / Prodika / Dallas / TX / USA
Saad Rehmani wrote:
+1

I've asked through my MVP lead for this newsgroup, it's now a matter
of 'if they think it's necessary it will be made available' ;)

FB


Jun 8 '06 #26

P: n/a
Sorry about the ignorance, but where be this Architecture forum ye talk about?

--
Saad Rehmani / Prodika / Dallas / TX / USA
Mmmm I hope so too !!!!

If not there are occasionally some on the architecture forum :)

Cheers,

Greg Young
MVP - C#
http://geekswithblogs.net/gyoung
"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
So, what we're really waiting for at this point is for Microsoft to
let us
know whether they consider design important or not.
Given some of the stuff they've been doing in the p&p group and the
overall direction, one would hope this decision is a no-brainer ...
I wonder if DSL / MDD vs. DDD types of discussions will be included.

This could be fun :)

Waiting ...

-- Saad Rehmani / Prodika / Dallas / TX / USA
Saad Rehmani wrote:

+1

I've asked through my MVP lead for this newsgroup, it's now a matter
of 'if they think it's necessary it will be made available' ;)

FB

Jun 8 '06 #27

P: n/a
I should also add that DDD is a form of MDD :)

so arguing DDD vs MDD is kind of silly :)
"Greg Young" <dr*******************@hotmail.com> wrote in message
news:uj**************@TK2MSFTNGP03.phx.gbl...
Mmmm I hope so too !!!!

If not there are occasionally some on the architecture forum :)

Cheers,

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

"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
So, what we're really waiting for at this point is for Microsoft to let
us know whether they consider design important or not.
Given some of the stuff they've been doing in the p&p group and the
overall direction, one would hope this decision is a no-brainer ...

I wonder if DSL / MDD vs. DDD types of discussions will be included.

This could be fun :)

Waiting ...
--
Saad Rehmani / Prodika / Dallas / TX / USA
Saad Rehmani wrote:

+1

I've asked through my MVP lead for this newsgroup, it's now a matter
of 'if they think it's necessary it will be made available' ;)

FB



Jun 8 '06 #28

P: n/a
In the msdn forums .. there are alot of matching groups between here and
there, but some groups only exist there

http://forums.microsoft.com/msdn/default.aspx?siteid=1

Cheers,

Greg
"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
Sorry about the ignorance, but where be this Architecture forum ye talk
about?

--
Saad Rehmani / Prodika / Dallas / TX / USA
Mmmm I hope so too !!!!

If not there are occasionally some on the architecture forum :)

Cheers,

Greg Young
MVP - C#
http://geekswithblogs.net/gyoung
"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
So, what we're really waiting for at this point is for Microsoft to
let us
know whether they consider design important or not.
Given some of the stuff they've been doing in the p&p group and the
overall direction, one would hope this decision is a no-brainer ...
I wonder if DSL / MDD vs. DDD types of discussions will be included.

This could be fun :)

Waiting ...

-- Saad Rehmani / Prodika / Dallas / TX / USA

Saad Rehmani wrote:

> +1
>
I've asked through my MVP lead for this newsgroup, it's now a matter
of 'if they think it's necessary it will be made available' ;)

FB


Jun 8 '06 #29

P: n/a
I would argue that all O/R mappers achieve the same objective, but those
that provide the most flexibility while maintaining clarity are (at least)
first amongst equals.

Even amongst those that are forms of each other ... :)

I wonder if there's an 'is-a' relationship between DDD / MDD.

I shall now look up the forum and continue my rambling there.

I hope they have an RSS feed, I really like being able to aggregate the information
I'm interested in.

Thanks Greg :)

--
Saad Rehmani / Prodika / Dallas / TX / USA
I should also add that DDD is a form of MDD :)

so arguing DDD vs MDD is kind of silly :)

"Greg Young" <dr*******************@hotmail.com> wrote in message
news:uj**************@TK2MSFTNGP03.phx.gbl...
Mmmm I hope so too !!!!

If not there are occasionally some on the architecture forum :)

Cheers,

Greg Young
MVP - C#
http://geekswithblogs.net/gyoung
"Saad Rehmani" <sa**********@gmail.com> wrote in message
news:44**************************@msnews.microsoft .com...
So, what we're really waiting for at this point is for Microsoft to
let
us know whether they consider design important or not.
Given some of the stuff they've been doing in the p&p group and the
overall direction, one would hope this decision is a no-brainer ...
I wonder if DSL / MDD vs. DDD types of discussions will be included.

This could be fun :)

Waiting ...

-- Saad Rehmani / Prodika / Dallas / TX / USA

Saad Rehmani wrote:

> +1
>
I've asked through my MVP lead for this newsgroup, it's now a
matter of 'if they think it's necessary it will be made available'
;)

FB

Jun 8 '06 #30

P: n/a
Saad Rehmani wrote:
I would argue that all O/R mappers achieve the same objective, but
those that provide the most flexibility while maintaining clarity are
(at least) first amongst equals. Even amongst those that are forms
of each other ... :)
Often it's not that simple, but that's not unique to o/r mappers or
data-access solutions in general. There are still people writing
software with toolkits which aren't really toolkits which help them get
more productive (i.e.: cutting down development cost/testing cost
etc.), but only make the developer do things differently, without any
real gain.
I wonder if there's an 'is-a' relationship between DDD / MDD.


they both derive from the abstract supertype Buzzword, so they have a
common ancestor, though I wouldn't call it an is-a relationship as
they're more or less siblings. ;)

But perhaps if you move away from the practical aspects of DDD and far
into hardcore theory-land, you might be able to argue that DDD and MDD
have a lot in common, however in that context I always get a slight
feeling that it's a lot of fuss about hot air, creating a lot of
overhead and consuming a lot of time while producing very little to
move the project forward. (in short: design for the sole purpose of
'doing it through design')

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#)
------------------------------------------------------------------------
Jun 9 '06 #31

P: n/a
On Tue, 6 Jun 2006 09:20:06 +0100, "Joanna Carter [TeamB]"
<jo****@not.for.spam> wrote:
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: xn***************@news.microsoft.com...

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


LMAO X-DDD

I like your decision. comp.object does not need more people like you.
Jun 9 '06 #32

P: n/a

FB wrote:
Saad Rehmani wrote:
I would argue that all O/R mappers achieve the same objective, but
those that provide the most flexibility while maintaining clarity are
(at least) first amongst equals. Even amongst those that are forms
of each other ... :)
Often it's not that simple, but that's not unique to o/r mappers or
data-access solutions in general. There are still people writing
software with toolkits which aren't really toolkits which help them
get more productive (i.e.: cutting down development cost/testing cost
etc.), but only make the developer do things differently, without any
real gain.
I wonder if there's an 'is-a' relationship between DDD / MDD.

they both derive from the abstract supertype Buzzword, so they have a
common ancestor, though I wouldn't call it an is-a relationship as
they're more or less siblings. ;)


Hmmm .... Buzzword is probably closer to an interface since it obviously
has no implementation ;)

But perhaps if you move away from the practical aspects of DDD and
far into hardcore theory-land, you might be able to argue that DDD and
MDD have a lot in common, however in that context I always get a
slight feeling that it's a lot of fuss about hot air, creating a lot
of overhead and consuming a lot of time while producing very little to
move the project forward. (in short: design for the sole purpose of
'doing it through design')
I think 'keep your design coupled with your code so both can evolve without
leaving the other behind' is probably a nicer way to say that :)

The thing that blows me away with the Generation-XP methodologies is that
all they're really doing is approaching problems from a different perspective.
'Improve your dev velocity / reliability / number of defects etc, etc. just
by thinking of the process of developing software in a different way', is
a pretty darn cool sell.

At the end of the day, most of these methodologies are really best practices
that someone (Eric Evans?) learnt over the course of their career. There's
no harm in learning about them and maybe gaining something from another person's
experience.

Then again, I might just like them because I hate meetings about spiraling
waterfalls :)

FB


--
Saad Rehmani / Prodika / Dallas / TX / USA
Jun 9 '06 #33

P: n/a
"Frans Bouma [C# MVP]" <pe******************@xs4all.nl> a écrit dans le
message de news: xn***************@news.microsoft.com...

| > I wonder if there's an 'is-a' relationship between DDD / MDD.
|
| they both derive from the abstract supertype Buzzword, so they have a
| common ancestor, though I wouldn't call it an is-a relationship as
| they're more or less siblings. ;)

Wow man, too many TLAs :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Jun 9 '06 #34

P: n/a
"Saad Rehmani" <sa**********@gmail.com> a écrit dans le message de news:
44**************************@msnews.microsoft.com...

| Hmmm .... Buzzword is probably closer to an interface since it obviously
| has no implementation ;)

Heheh :-)

| At the end of the day, most of these methodologies are really best
practices
| that someone (Eric Evans?) learnt over the course of their career. There's
| no harm in learning about them and maybe gaining something from another
person's
| experience.

That's what I found so annoying about UML; it started out as a language for
communicating ideas, then someone turned it into a methodology, which seems
to approach the traditional waterfall with the odd eddy :-)

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer
Jun 9 '06 #35

This discussion thread is closed

Replies have been disabled for this discussion.