One form accesses controls on a different form - good practice?

  • Thread starter Thread starter trebor
  • Start date Start date
T

trebor

I'm learning dotNet, although I first learned programming back in the
days when structured programming was all the rage. In both my books and
courses, I've seen something like this:

Public Class FormA
Inherits System.Windows.Forms.Form

Private Sub Button_Click(ByVal etc., etc.) Handles btnCalculate.Click
FormB.Textbox.Text = "some updated value"
End Sub

Is this good programming practice? Somehow, it just feels wrong to
access a form's controls FROM A DIFFERENT form.

Isn't this no different from A accessing B's local variables? I know
compilers will let you to do it, but I learned that was not good
programming practice because (among other things) a ripple effect could
introduce subtle and difficult bugs.

And if this IS good programming practice, what's the rationale behind
it? What changed over the past 15 years?
 
Trebor,
I am from before the time of structured programming but a Dijkstra follower
(One of the first inventors of structured programming)

One of the main reasons for structured programming was to keep your program
readable.
(Small parts that could be handled. For that OO programming has no
difference in my opinion).
Public Class FormA
Inherits System.Windows.Forms.Form

Private Sub Button_Click(ByVal etc., etc.) Handles btnCalculate.Click
FormB.Textbox.Text = "some updated value"
End Sub
Click to expand...
We often say in this newsgroup that one of the advantage's of VB.net is,
that it has the possibility to do it in your own way.
But I don't think this is good practise I never saw it in that way been
described by someone.
(Sometimes people ask how to do it in this way, but they never get that
answer).

Some thoughts

Cor
 
Since VB.Net is fully object-oriented, it is time to change your thinking
about "structured" programming. Object oriented programming is different
from structured programming in both design and implementation. In
object-oriented designs, it is best to keep the knowledge about an objects
"internals" private. This principle is called "Information hiding" and
allows objects to be very reusable. If you have form A knowing about form
B's internals, this is called "tight-coupling" between the objects.
Tight-coupling between two objects reduces their reusability and is
generally not a good OO practice. "Loose-coupling" is the preferred way to
design and implement in OO programs, since this promotes the maximum reuse
of the "business" objects. There are times when tight-coupling is used as
part of a pattern, and at these times it is considered acceptable. For
example, the Model-View-Controller pattern allows the View to know
completely about the internals of the Model. This is very sensible since
the View is responsible for "displaying" the current internal state of the
Model. However, the Model knows nothing about a View or its internals, this
allows the Model to be reusable.
The Model-View pattern is a common way to organize a windows application. A
model or models should contain your "business" logic for the application.
The view then has the sole responsiblility of displaying the model's current
state. In your example the FormB.Textbox.Text should be displaying some
value contained in a Model. For example, if your model is a Person, and you
have a Name property on Person, the FormB.Textbox.Text could be responsible
for displaying the Name property of your Person object. If FormA is also
displaying the Name property of your Person object then both forms would be
"looking" at the same property, and if that value changes, it would
"automatically" be updated on both forms.
I recommend a good Programming Patterns book as a good place to start
looking at how to design and implement OO applications.

Hope this helps,
Gary
 
Gary Owsiany said:
Since VB.Net is fully object-oriented, it is time to change your thinking
about "structured" programming. Object oriented programming is different
from structured programming in both design and implementation. In
object-oriented designs, it is best to keep the knowledge about an objects
"internals" private. This principle is called "Information hiding" and
allows objects to be very reusable. If you have form A knowing about form
B's internals, this is called "tight-coupling" between the objects.
Tight-coupling between two objects reduces their reusability and is
generally not a good OO practice.
Click to expand...

Thanks. Good information.
 
Back
Top