Difficult Problem with Objects 
Author Message
 Difficult Problem with Objects

Hi,
I have an application, where a customer can have a number of different
'things' associated with them. For the sake of simplicity, assume they are
fruits. So, we have lots of components, CBanana, CApple etc. all
implementing the IFruit interface.

What we have at the moment, is a seperate form for the modification,
creation of specific fruits. For example, there is a frmBanana which lets
the user assign properties of the bananas (e.g. curvature ;-).

What we want, is a common user interface - say with a treeview down the left
showing all the fruits that a customer has. When they click on a fruit, the
details will be shown in the right hand pane. My question is how can I make
the fruit component responsible for the creation of its' user-interface?

What I'd really like is for the main application to have no knowledge of
particular fruits - all interaction would be through the IFruit interface. I
can do it with seperate forms (e.g. have a ShowForm method on IFruit), but
how can I do it with a single maintenance screen that gets tailored for
particular fruits? I'd really like to avoid using control arrays with one
default control per control type. Can I do this with user controls? Can you
create user controls dynamically at run-time without having to add each one
to the project at compile-time?

Any thoughts greatly appreciated,
Jon Rowland



Fri, 07 Sep 2001 03:00:00 GMT  
 Difficult Problem with Objects
I understand what you are trying to do. And if only VB supported true OO
principles, your task would be routine. However, since you have chosen VB to
solve this particular problem, you will have to accept a few undesirable
consequences.

First of all, as you know, VB does not support inheritance. It only supports
interfaces. Second, form objects do not support interfaces. Therefore the
messaging that you wish to occur between your domain objects and you UI will
have to be set up precariously. Each form that you wish to create in this
manner will (most likely) need to have a standard interface for
communicating back to the domain object. (to tell the object to save itself,
etc.) Thus you will have to use VB's poor man's inheritance (copy the method
manually to all of your form objects.)

Ok, having said that, how about I answer your question. The way that I would
design this so that the domain object (CBanana, CApple, ...) is adequately
de-coupled from its display is this. By using a VB bastardized version of
the Factory design pattern (Gamma, Helm, Johnson, Vlissides [1995]), you
could de-couple the responsibility for knowing which form to create from the
domain object and assign this responsibility to the Factory object. However,
as far as I know (disclaimer), you would not be able to build(place controls
on) these forms at runtime. The Factory object would simply look at the
Typename of the object sending the message, and then in a case statement it
would instantiate the correct (designed at runtime) form to maintain the
object. (for more info on the Factory pattern, see _Design Patterns:
Elements of Reusable OO Software_ by G, H, J & V)

Hope this helps.

Mike Schaefer

Note: to reply by email, remove nospam from the address above

Quote:

>Hi,
>I have an application, where a customer can have a number of different
>'things' associated with them. For the sake of simplicity, assume they are
>fruits. So, we have lots of components, CBanana, CApple etc. all
>implementing the IFruit interface.

>My question is how can I make
>the fruit component responsible for the creation of its' user-interface?

[snip]


Sat, 08 Sep 2001 03:00:00 GMT  
 Difficult Problem with Objects
First of all, it is not that VB does not support 'true' OO principles. COM
is the one who does not (and since VB is COM, it does not either). It was
designed that way. Actually, if you really want to discuss 'pure' OO, not
supporting true inheritance enforces encapsulation. What is the purpose of
encapsulation if you can totally inherit a sub and redefine it? Anyway, that
was just a little talk from my 'anti-VB-OO' hater side. Also, don't forget
about delegation...

As far as forms and interfaces. They can have them. A form can implement an
interface like any other object.

Rob --


Quote:
> I understand what you are trying to do. And if only VB supported true OO
> principles, your task would be routine. However, since you have chosen VB
to
> solve this particular problem, you will have to accept a few undesirable
> consequences.

> First of all, as you know, VB does not support inheritance. It only
supports
> interfaces. Second, form objects do not support interfaces. Therefore the
> messaging that you wish to occur between your domain objects and you UI
will
> have to be set up precariously. Each form that you wish to create in this
> manner will (most likely) need to have a standard interface for
> communicating back to the domain object. (to tell the object to save
itself,
> etc.) Thus you will have to use VB's poor man's inheritance (copy the
method
> manually to all of your form objects.)

> Ok, having said that, how about I answer your question. The way that I
would
> design this so that the domain object (CBanana, CApple, ...) is adequately
> de-coupled from its display is this. By using a VB bastardized version of
> the Factory design pattern (Gamma, Helm, Johnson, Vlissides [1995]), you
> could de-couple the responsibility for knowing which form to create from
the
> domain object and assign this responsibility to the Factory object.
However,
> as far as I know (disclaimer), you would not be able to build(place
controls
> on) these forms at runtime. The Factory object would simply look at the
> Typename of the object sending the message, and then in a case statement
it
> would instantiate the correct (designed at runtime) form to maintain the
> object. (for more info on the Factory pattern, see _Design Patterns:
> Elements of Reusable OO Software_ by G, H, J & V)

> Hope this helps.

> Mike Schaefer

> Note: to reply by email, remove nospam from the address above


> >Hi,
> >I have an application, where a customer can have a number of different
> >'things' associated with them. For the sake of simplicity, assume they
are
> >fruits. So, we have lots of components, CBanana, CApple etc. all
> >implementing the IFruit interface.

> >My question is how can I make
> >the fruit component responsible for the creation of its' user-interface?

> [snip]



Fri, 14 Sep 2001 03:00:00 GMT  
 Difficult Problem with Objects

Quote:



>> I'd really like to avoid using control arrays with one
>> default control per control type. Can I do this with user controls? Can
you
>> create user controls dynamically at run-time without having to add each
one
>> to the project at compile-time?

>The only disadvantage to this approach is that your toolbox gets littered
with
>nondescript usercontrol icons. Just create a new toolbox tab and move these
>controls over so they aren't littering up your General tab.

>A final caveat: Don't marry your ojbects to a view! Your object should

have....
<CHOP>

There is another more serious caveat that you should know about.  This
dynamic-creation strategy will not work if your custom usercontrols contain
any 3rd party ActiveX controls that have runtime licenses.  This is, in my
opinion, a HUGE flaw in the way VB implements dynamic control creation.

The only way that you can dynamically create ActiveX controls that contain
3rd party controls with runtime licenses is to explicitly reference your
usercontrol from within your project.  If you reference the usercontrol,
then VB will compile the license key into your code at compile time.  If you
don't explicitly reference your usercontrol... well, you can just forget
about dynamic creation.

There is an article in the KB about this very behavior.  I don't remember
the exact number, but try searching on "dynamic, VB, ActiveX" and that might
hit it.  This behavior is "by design".  I think that it is a pain in the
patoot!

Peter



Sat, 15 Sep 2001 03:00:00 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Difficult Problem with Objects

2. Simple problem with movenext, and slightly more difficult bonus question

3. A difficult problem ...

4. My ? is difficult to categorize (Program problem)

5. Very difficult problem

6. A problem MUCH too difficult for YOU!

7. Difficult problem

8. Difficult Problem

9. please help me difficult problem

10. subtle + extremely difficult problem

11. A Much More Difficult Problem!

12. A problem MUCH too difficult for YOU!

 

 
Powered by phpBB® Forum Software