Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #32182 > unrolled thread

How to access properties of a class from another class?

Back to article view | Back to comp.lang.java.programmer

Contents

  How to access properties of a class from another class? Xue Feng <xf.lotus@yahoo.com> - 2015-07-29 03:45 +0800
    Re: How to access properties of a class from another class? Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-07-28 16:58 -0400
    Re: How to access properties of a class from another class? Jeff Higgins <jeff@invalid.invalid> - 2015-07-28 16:59 -0400
    Re: How to access properties of a class from another class? Nigel Wade <nmw@ion.le.ac.uk> - 2015-07-29 15:24 +0100
      Re: How to access properties of a class from another class? Xue Feng <xf.lotus@yahoo.com> - 2015-08-01 16:10 +0800

#32182 — How to access properties of a class from another class?

Hi,

Beg your pardon for this silly question.I am familiar with the concept 
of encapsulation indeed. However, for some problems, I think there must 
be better solutions.

My question comes from a feature of Netbeans which is well-known for its 
wonderful GUI design facilities. However, for all GUI components, 
Netbeans likes to cram them into a single source file of the main frame. 
A direct result for this is all code pertain to definition of GUI 
component objects and event handling are concentrated in a source file, 
and it meants to flate rapidly. For large-scale projects, this is not a 
good idea.(I have only little experience with Netbeans for two weeks. 
There mybe other options I don't know. Tell me please.)

To practice MVC schema, it is necessary to design separate control class 
and view class. Both of them have occasions to interact with GUI 
components. However, all of components are defined in the main frame 
class as private members. Therefore, control class and view class need 
to access these components encapsulated in the main frame class. I think 
there mybe some ways to achieve the goal as follows:

(1) Define control class and veiw class as inner class of the main frame 
class. But, this practice will result in a huge souce file obviously.
(2) Define components as public members. However, it seems that Netbeans 
does not allow this way.
(3) Define many 'get' methods for the main frame class, and invoke them 
from  control class and view class to get references of component 
needed. This is an ordinary pratice, but somewhat tedious. Moreover, it 
also lacks flexibility especially when the GUI design changes frequently.
(4) Take some language construct such as friend class from C++. I don't 
konw whether Java has this kind of construct.
(5) Is there any way to dynamically generate an object at runtime in 
terms of the main frame class as template? This object wraps up all 
components' reference as its public member. Then, pass the object to 
control object and view object. Maybe reflection can help, but I am not 
sure about it.

For the above specific situation, I wonder whether there are ways to 
circument encasulation to make programming more convenient and flexibiable.

[toc] | [next] | [standalone]

#32183

On 7/28/2015 3:45 PM, Xue Feng wrote:
> Hi,
>
> Beg your pardon for this silly question.I am familiar with the concept
> of encapsulation indeed. However, for some problems, I think there must
> be better solutions.
>
> My question comes from a feature of Netbeans which is well-known for its
> wonderful GUI design facilities. However, for all GUI components,
> Netbeans likes to cram them into a single source file of the main frame.
> A direct result for this is all code pertain to definition of GUI
> component objects and event handling are concentrated in a source file,
> and it meants to flate rapidly. For large-scale projects, this is not a
> good idea.(I have only little experience with Netbeans for two weeks.
> There mybe other options I don't know. Tell me please.)

     Speaking for myself, I prefer to write plain Java code to build
my Swing UI's.  I've tried NetBeans' GUI builder but found it tedious:
To accomplish what four lines of code would have done, NetBeans requires
me to click and scroll and tab from menu to menu to menu -- and even
with all that, I need to look at the generated code to be sure I haven't
forgotten to click something!

     I have (occasionally) used the GUI builder to create a dummy or
mock-up of my UI, just to see how something unfamiliar is done.  For
example, I find some of the newer layout managers quite intricate and
hard to use.  So, I'll make a dummy UI in the builder and then study the
generated code; with a working example in front of me it's then much
easier to write what I actually wind up using.

     But that's just my personal taste; others may differ.

> To practice MVC schema, it is necessary to design separate control class
> and view class. Both of them have occasions to interact with GUI
> components. However, all of components are defined in the main frame
> class as private members. Therefore, control class and view class need
> to access these components encapsulated in the main frame class. I think
> there mybe some ways to achieve the goal as follows:

     As an aside, note that Swing doesn't use a "pure" MVC architecture.
Roughly speaking, it combines V and C to get an "M+VC" architecture.
<http://www.oracle.com/technetwork/java/architecture-142923.html> has
a more detailed explanation.

> (1) Define control class and veiw class as inner class of the main frame
> class. But, this practice will result in a huge souce file obviously.

     Sounds like an unattractive solution.

> (2) Define components as public members. However, it seems that Netbeans
> does not allow this way.

     You *can* change the access for a component: Select the component,
go to the Code tab on the Properties menu, find the Variable Modifiers
line, click on the ... button, click on the Access drop-down of the
dialog that opens, choose "public", and click on OK.  (That's the sort
of thing that makes me complain about finding the GUI builder "tedious"
to use: Instead of six keystrokes p u b l i c, I must do at least six
separate mouse actions in three sub-windows.  I'm a poor typist, but
even so I can type p u b l i c much more quickly and easily than I can
get through all this clickety-clacking!)

     Besides, making everything public seems a poor idea to begin with.

> (3) Define many 'get' methods for the main frame class, and invoke them
> from  control class and view class to get references of component
> needed. This is an ordinary pratice, but somewhat tedious. Moreover, it
> also lacks flexibility especially when the GUI design changes frequently.

     Using public access would suffer from the same lack of flexibility.

> (4) Take some language construct such as friend class from C++. I don't
> konw whether Java has this kind of construct.

     Not really, but sometimes "package-private" access (that's what you
get if you don't use any of public, protected, or private) will serve.
It means that any other class in the same package can see (and touch!)
the component, which seems rather permissive -- but since you're the
person who decides what's in your package, you can limit the exposure.

> (5) Is there any way to dynamically generate an object at runtime in
> terms of the main frame class as template? This object wraps up all
> components' reference as its public member. Then, pass the object to
> control object and view object. Maybe reflection can help, but I am not
> sure about it.

     I'm not sure what you're proposing here, so I won't comment.

     I'm sorry I can't help you more with the GUI builder -- but, as I
said, my experiences of using it have not been happy.  It's tedious to
use, and I don't like the code it generates any more than you seem to.
Perhaps you'll learn to use it more smoothly than I have managed ...

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#32184

On 07/28/2015 03:45 PM, Xue Feng wrote:
> Hi,
>
> Beg your pardon for this silly question.I am familiar with the concept
> of encapsulation indeed. However, for some problems, I think there must
> be better solutions.
>
> My question comes from a feature of Netbeans which is well-known for its
> wonderful GUI design facilities. However, for all GUI components,
> Netbeans likes to cram them into a single source file of the main frame.
> A direct result for this is all code pertain to definition of GUI
> component objects and event handling are concentrated in a source file,
> and it meants to flate rapidly. For large-scale projects, this is not a
> good idea.(I have only little experience with Netbeans for two weeks.
> There mybe other options I don't know. Tell me please.)
>
> To practice MVC schema, it is necessary to design separate control class
> and view class.

The reason you use a GUI builder is to free yourself from having to deal
with the architecture of the GUI model and concentrate on your problem
domain.
Let it do its job.

> Both of them have occasions to interact with GUI
> components. However, all of components are defined in the main frame
> class as private members. Therefore, control class and view class need
> to access these components encapsulated in the main frame class. I think
> there mybe some ways to achieve the goal as follows:
>
> (1) Define control class and veiw class as inner class of the main frame
> class. But, this practice will result in a huge souce file obviously.
> (2) Define components as public members. However, it seems that Netbeans
> does not allow this way.
> (3) Define many 'get' methods for the main frame class, and invoke them
> from  control class and view class to get references of component
> needed. This is an ordinary pratice, but somewhat tedious. Moreover, it
> also lacks flexibility especially when the GUI design changes frequently.
> (4) Take some language construct such as friend class from C++. I don't
> konw whether Java has this kind of construct.
> (5) Is there any way to dynamically generate an object at runtime in
> terms of the main frame class as template? This object wraps up all
> components' reference as its public member. Then, pass the object to
> control object and view object. Maybe reflection can help, but I am not
> sure about it.
>
> For the above specific situation, I wonder whether there are ways to
> circument encasulation to make programming more convenient and flexibiable.

Yes, ditch the GUI builder and build it all yourself.

[toc] | [prev] | [next] | [standalone]

#32195

On 28/07/15 20:45, Xue Feng wrote:
> Hi,
>
> Beg your pardon for this silly question.I am familiar with the concept of encapsulation indeed. However, for some
> problems, I think there must be better solutions.
>
> My question comes from a feature of Netbeans which is well-known for its wonderful GUI design facilities. However, for
> all GUI components, Netbeans likes to cram them into a single source file of the main frame.  A direct result for this is
> all code pertain to definition of GUI component objects and event handling are concentrated in a source file, and it
> meants to flate rapidly. For large-scale projects, this is not a good idea.(I have only little experience with Netbeans
> for two weeks. There mybe other options I don't know. Tell me please.)

Two weeks is barely enough to begin to climb the learning curve.

It isn't true that NetBeans likes to cram everything into a single file. NetBeans does what you tell it to. If that's 
the way you design your GUI then that's what NetBeans will do. But it's not the only way to do it.

You can build your GUI from multiple smaller elements, each within its own class. You can then build these smaller 
elements into a larger GUI.
Whether NetBeans can actually manipulate your smaller elements within the matisse GUI design tool depends on how much 
effort you put into correctly designing the smaller elements. If they can be imported as Beans then matisse will use them.

Even if your smaller GUI elements cannot be imported as Beans, and manipulated by matisse, it doesn't preclude you from 
utilizing them in your main GUI. You will, however, have to create them yourself and embed them into the design using 
the code section of the component properties or add the relevant code, normally just after the init_components() method 
has been invoked.

>
> To practice MVC schema, it is necessary to design separate control class and view class. Both of them have occasions to
> interact with GUI components. However, all of components are defined in the main frame class as private members.
> Therefore, control class and view class need to access these components encapsulated in the main frame class. I think
> there mybe some ways to achieve the goal as follows:
>
> (1) Define control class and veiw class as inner class of the main frame class. But, this practice will result in a huge
> souce file obviously.
> (2) Define components as public members. However, it seems that Netbeans does not allow this way.

Eric has already explained how to change this. Whether you want to do that is another matter.
I have only very, very occasionally modified the access of a matisse generated component.

> (3) Define many 'get' methods for the main frame class, and invoke them from  control class and view class to get
> references of component needed. This is an ordinary pratice, but somewhat tedious. Moreover, it also lacks flexibility
> especially when the GUI design changes frequently.

NetBeans makes this operation fairly trivial. The key-binding (at least on Linux) Alt-Insert (alternatively the menu 
Source->Insert code...) brings up a popup menu where you can select what type of code you want to insert. This includes 
getters and setters,. From the dialog displayed select which private elements you want NetBeans to construct the 
getters/setters for and then let NetBeans do the boiler plating.

[toc] | [prev] | [next] | [standalone]

#32237

on 2015/7/29 22:24, Nigel Wade wrote:

> You can build your GUI from multiple smaller elements, each within its
> own class. You can then build these smaller elements into a larger GUI.
> Whether NetBeans can actually manipulate your smaller elements within
> the matisse GUI design tool depends on how much effort you put into
> correctly designing the smaller elements. If they can be imported as
> Beans then matisse will use them.
>
> Even if your smaller GUI elements cannot be imported as Beans, and
> manipulated by matisse, it doesn't preclude you from utilizing them in
> your main GUI. You will, however, have to create them yourself and embed
> them into the design using the code section of the component properties
> or add the relevant code, normally just after the init_components()
> method has been invoked.
>

I am really interested in this part. Is there any hints about it?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web