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

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

Best Way to Pass Info Between Objects?

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

Contents

  Best Way to Pass Info Between Objects? Novice <novice@example..com> - 2012-01-08 16:41 +0000
    Re: Best Way to Pass Info Between Objects? Patricia Shanahan <pats@acm.org> - 2012-01-08 09:08 -0800
      Re: Best Way to Pass Info Between Objects? Novice <novice@example..com> - 2012-01-08 18:22 +0000
        Re: Best Way to Pass Info Between Objects? markspace <-@.> - 2012-01-08 10:45 -0800
        Re: Best Way to Pass Info Between Objects? Lew <noone@lewscanon.com> - 2012-01-08 11:49 -0800
        Re: Best Way to Pass Info Between Objects? Patricia Shanahan <pats@acm.org> - 2012-01-08 14:04 -0800
          Re: Best Way to Pass Info Between Objects? Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-08 22:40 +0000
            Re: Best Way to Pass Info Between Objects? Patricia Shanahan <pats@acm.org> - 2012-01-08 15:56 -0800
              Re: Best Way to Pass Info Between Objects? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-09 06:34 -0400
                Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-09 12:39 -0500
                  Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-09 12:42 -0500
                  Re: Best Way to Pass Info Between Objects? Lew <lewbloch@gmail.com> - 2012-01-09 13:43 -0800
                    Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-09 17:26 -0500
                      Re: Best Way to Pass Info Between Objects? Lew <noone@lewscanon.com> - 2012-01-10 06:47 -0800
                    Re: Best Way to Pass Info Between Objects? Patricia Shanahan <pats@acm.org> - 2012-01-09 14:26 -0800
                  Re: Best Way to Pass Info Between Objects? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-09 19:06 -0400
                    Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-09 18:46 -0500
                      Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-09 19:52 -0500
                      Re: Best Way to Pass Info Between Objects? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 06:43 -0400
                Re: Best Way to Pass Info Between Objects? Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-10 02:11 +0000
                Re: Best Way to Pass Info Between Objects? Gene Wirchenko <genew@ocis.net> - 2012-01-09 20:17 -0800
                Re: Best Way to Pass Info Between Objects? Lew <noone@lewscanon.com> - 2012-01-10 06:43 -0800
                  Re: Best Way to Pass Info Between Objects? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 19:13 -0400
        Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-09 14:30 -0500
          Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-09 17:28 -0500
            Re: Best Way to Pass Info Between Objects? Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-10 02:24 +0000
              Re: Best Way to Pass Info Between Objects? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-10 06:35 -0400
                Re: Best Way to Pass Info Between Objects? Martin Gregorie <martin@address-in-sig.invalid> - 2012-01-10 22:48 +0000
    Re: Best Way to Pass Info Between Objects? v_borchert@despammed.com (Volker Borchert) - 2012-01-08 17:17 +0000
    Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-08 13:43 -0500
      Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-08 19:01 -0500
    Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-08 14:10 -0500
      Re: Best Way to Pass Info Between Objects? Jeff Higgins <jeff@invalid.invalid> - 2012-01-08 14:41 -0500
    Re: Best Way to Pass Info Between Objects? Roedy Green <see_website@mindprod.com.invalid> - 2012-01-09 04:13 -0800

Page 2 of 2 — ← Prev page 1 [2]

#11157

On 9 Jan 2012 12:36:11 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote:

>Arved Sandstrom <asandstrom3minus1@eastlink.ca> writes:
>>1. And how much of one's time one should devote to writing unit tests
>>for _testing_, as opposed to higher-level tests, is a different discussion.
>
>  Once I was giving a C++ class for engine construction
>  students, and I gave them an assignment that requires to
>  write a client (caller) before the service (callee) is
>  written, but (my memory might distort this to some degree)
>  no one was able to understand what they were supposed to do.
>  And so, there was no correct solution to that assignment (or
>  only very few, I am not sure).

     In one of my degree courses, we had to write a secure FTP.  It
was spread out over most of the assignments of the course.  It was
interesting coding.  I ended up implementing complementary bits of
client and server at a time.  I did not go for implementing one side
totally and then the other.  By doing it incrementally, I was able to
use each side to help check out and debug the other.

[snip]

Sincerely,

Gene Wirchenko

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

#11170

Arved Sandstrom wrote:
> I will also point out, neutrally, that what has been advocated here for
> unit tests in support of software component design is test driven
> development (TDD), or *close to it*. Lew and Martin both describe a
> process very close to it; I don't have enough information to say whether
> they are _requiring_ that all of the first tests fail (which is
> necessary in classic TDD), or simply assuming that many/most will.

When you write that up-front test and keep it simple, you don't have to run 
the test to know it'll fail initially.

I, too, write implementation before the unit test.  Or did.  I've learned that 
unit tests save effort and eliminate bugs, the more so earlier you write them, 
up to concurrently with implementation.

Covering your code with unit tests, you are freed of doubt whether you're free 
of unit-level bugs.  (Ducking tomatoes.  Hey, don't get mad at me if you wrote 
insufficient unit tests.  Fix them.)

I'm working on assimilating this lesson properly myself.  New habits displace 
ingrained patterns only by dint of diligence.  My transformation is helped by 
how little overhead a test-propelled approach introduces, and how much faster 
and better development goes.

> In any case the OP could read up on TDD to get more background on what's
> being described here. A salient point is that these are unit tests that
> support software component design; they are not unit tests for defect
> detection [1].
>
...
> 1. And how much of one's time one should devote to writing unit tests
> for _testing_, as opposed to higher-level tests, is a different discussion.

Would you expound on this distinction, please?  I've heard a lot of 
distinctions drawn around tests and unit tests in particular, but never this.


Notes:
1. Annotations.      Annotations.
2. EasyMock - beyond testing, a requirements scripter.  Yes, it's easy.
3. 'assert'.  It's pure Zen.
4. Dependency Injection.
5. Package-private methods.  (No, not every method.  Really?)


-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

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

#11194

On 12-01-10 10:43 AM, Lew wrote:
> Arved Sandstrom wrote:
>> I will also point out, neutrally, that what has been advocated here for
>> unit tests in support of software component design is test driven
>> development (TDD), or *close to it*. Lew and Martin both describe a
>> process very close to it; I don't have enough information to say whether
>> they are _requiring_ that all of the first tests fail (which is
>> necessary in classic TDD), or simply assuming that many/most will.
> 
> When you write that up-front test and keep it simple, you don't have to
> run the test to know it'll fail initially.
> 
> I, too, write implementation before the unit test.  Or did.  I've
> learned that unit tests save effort and eliminate bugs, the more so
> earlier you write them, up to concurrently with implementation.
> 
> Covering your code with unit tests, you are freed of doubt whether
> you're free of unit-level bugs.  (Ducking tomatoes.  Hey, don't get mad
> at me if you wrote insufficient unit tests.  Fix them.)
> 
> I'm working on assimilating this lesson properly myself.  New habits
> displace ingrained patterns only by dint of diligence.  My
> transformation is helped by how little overhead a test-propelled
> approach introduces, and how much faster and better development goes.

I'm cool with the idea of getting unit tests in there early. I'm not too
concerned with writing them first, but when I get the chance to write
them, I try to have unit tests in place immediately after a method that
rates being tested.

Note the "get the chance to write them at all". 90 percent of the code I
write is bespoke stuff, usually done on-site. While there is generally
tolerance for some decent level of testing prior to UAT, clients tend to
heavily favour system and integration and functional testing over unit
tests. There are a bunch of reasons why clients think that way, some of
them justified, and some of the clients who do have a bias against unit
tests have experience with them.

I'm not being judgmental when I point this out, it's simply a fact of my
work environment. It's not a universal client attitude but I believe it
to be a common one. And it's entirely possible to work with clients who
are enthusiastic about functional and higher tests, but go so far as to
forbid unit tests. I've worked with such.

>> In any case the OP could read up on TDD to get more background on what's
>> being described here. A salient point is that these are unit tests that
>> support software component design; they are not unit tests for defect
>> detection [1].
>>
> ...
>> 1. And how much of one's time one should devote to writing unit tests
>> for _testing_, as opposed to higher-level tests, is a different
>> discussion.
> 
> Would you expound on this distinction, please?  I've heard a lot of
> distinctions drawn around tests and unit tests in particular, but never
> this.
[ SNIP ]

It's pretty simple, you've usually got limited time for all testing
activities, much less than you'd like and less than you need. Your
project has X days for unit tests, functional tests, integration tests,
system tests, load tests and acceptance tests. Acceptance tests usually
get a fixed, adequate amount of time. System tests and load tests also
usually get fixed, almost adequate blocks of time. Everything else has
to fight for budget, so of unit or functional or integration testing,
where do you get the most bang for the buck?

I have my own thoughts on the latter, but that's not relevant in
answering your question. I am merely pointing out that in the real world
you almost always have to sacrifice some forms of tests.

AHS
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

#11137

On 01/08/2012 01:22 PM, Novice wrote:
> Patricia Shanahan<pats@acm.org>  wrote in
> news:4dWdnRF6pOQcUJTSnZ2dnUVZ_vidnZ2d@earthlink.com:
>
>> On 1/8/2012 8:41 AM, Novice wrote:
>>> Sorry, that's probably not the best of subject lines but I'm having
>>> trouble coming up with a concise one....
>>>
>>> I'm trying to reason out the best way to pass information from an
>>> instantiating class to an instantiated class. So, let's say class Foo
>>> invokes class Bar to do something. Bar needs some specific
>>> information from Foo to do its job. What is the best way to pass this
>>> information from Foo to Bar?
>> ...
>>> I'm not sure if there is a generally agreed-upon formula here or
>>> whether it is more a case of individual style and preference. I'd be
>>> very interested in your comments on this subject. Right now, I feel
>>> like I'm being pretty inconsistent in my techniques and would like to
>>> standardize them along the best possible lines.
>>>
>>
>> Here is one programming process approach that often simplifies these
>> questions: Write the Bar unit tests in parallel with designing Bar.
>>
>> If the Bar design works well for both unit testing and use by a Foo,
>> it will probably be a reasonably robust module that does not need to
>> be changed too often because of changes to other modules.
>>
>> Patricia
>>
>
> Thanks everyone for the suggestions. Obviously, I'm going to need to
> increase the size of my Java library and allocate some time for reading all
> all of these things....
>
> But in the meantime, are there any general rules I can use to make these
> decisions for code I am developing now? Or do I really need to master
> several books first?
>
Now that you are sufficiently interested in data modelling and software 
design methodologies: here is a good, fast, cheap jumping in point.
<http://www.vogella.de/articles/EclipseEMF/article.html>
It will even do Swing databinding with some extra work (I gather).

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

#11144

On 01/09/2012 02:30 PM, Jeff Higgins wrote:
> On 01/08/2012 01:22 PM, Novice wrote:
>> Patricia Shanahan<pats@acm.org> wrote in
>> news:4dWdnRF6pOQcUJTSnZ2dnUVZ_vidnZ2d@earthlink.com:
>>
>>> On 1/8/2012 8:41 AM, Novice wrote:
>>
>> Thanks everyone for the suggestions. Obviously, I'm going to need to
>> increase the size of my Java library and allocate some time for
>> reading all
>> all of these things....
>>
>> But in the meantime, are there any general rules I can use to make these
>> decisions for code I am developing now? Or do I really need to master
>> several books first?
>>
> Now that you are sufficiently interested in data modelling and software
> design methodologies: here is a good, fast, cheap jumping in point.
> <http://www.vogella.de/articles/EclipseEMF/article.html>
> It will even do Swing databinding with some extra work (I gather).
>
Someone may want to start with designing the UI and then add the data model.
<http://code.google.com/javadevtools/wbpro/features/swing/data_binding/example.html>

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

#11154

On Mon, 09 Jan 2012 17:28:38 -0500, Jeff Higgins wrote:

> On 01/09/2012 02:30 PM, Jeff Higgins wrote:
>> On 01/08/2012 01:22 PM, Novice wrote:
>>> Patricia Shanahan<pats@acm.org> wrote in
>>> news:4dWdnRF6pOQcUJTSnZ2dnUVZ_vidnZ2d@earthlink.com:
>>>
>>>> On 1/8/2012 8:41 AM, Novice wrote:
>>>
>>> Thanks everyone for the suggestions. Obviously, I'm going to need to
>>> increase the size of my Java library and allocate some time for
>>> reading all all of these things....
>>>
>>> But in the meantime, are there any general rules I can use to make
>>> these decisions for code I am developing now? Or do I really need to
>>> master several books first?
>>>
>> Now that you are sufficiently interested in data modelling and software
>> design methodologies: here is a good, fast, cheap jumping in point.
>> <http://www.vogella.de/articles/EclipseEMF/article.html>
>> It will even do Swing databinding with some extra work (I gather).
>>
> Someone may want to start with designing the UI and then add the data
> model.
> <http://code.google.com/javadevtools/wbpro/features/swing/data_binding/
example.html>

If the data model hasn't been specified that's often the best way to go 
about it. Its like the way we used to design tape based systems before 
those new-fangled design methodologies appeared: Start by designing the 
output (typically printed reports) and then work back to design the 
master file(s), adding keys etc as needed to get the file ordering right. 
Following that, you could say what the inputs needed to be knowing that 
you hadn't left any data items out or included any that weren't needed. 

I find the same approach works equally well for interactive systems. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#11160

On 12-01-09 10:24 PM, Martin Gregorie wrote:
> On Mon, 09 Jan 2012 17:28:38 -0500, Jeff Higgins wrote:
> 
>> On 01/09/2012 02:30 PM, Jeff Higgins wrote:
>>> On 01/08/2012 01:22 PM, Novice wrote:
>>>> Patricia Shanahan<pats@acm.org> wrote in
>>>> news:4dWdnRF6pOQcUJTSnZ2dnUVZ_vidnZ2d@earthlink.com:
>>>>
>>>>> On 1/8/2012 8:41 AM, Novice wrote:
>>>>
>>>> Thanks everyone for the suggestions. Obviously, I'm going to need to
>>>> increase the size of my Java library and allocate some time for
>>>> reading all all of these things....
>>>>
>>>> But in the meantime, are there any general rules I can use to make
>>>> these decisions for code I am developing now? Or do I really need to
>>>> master several books first?
>>>>
>>> Now that you are sufficiently interested in data modelling and software
>>> design methodologies: here is a good, fast, cheap jumping in point.
>>> <http://www.vogella.de/articles/EclipseEMF/article.html>
>>> It will even do Swing databinding with some extra work (I gather).
>>>
>> Someone may want to start with designing the UI and then add the data
>> model.
>> <http://code.google.com/javadevtools/wbpro/features/swing/data_binding/
> example.html>
> 
> If the data model hasn't been specified that's often the best way to go 
> about it. Its like the way we used to design tape based systems before 
> those new-fangled design methodologies appeared: Start by designing the 
> output (typically printed reports) and then work back to design the 
> master file(s), adding keys etc as needed to get the file ordering right. 
> Following that, you could say what the inputs needed to be knowing that 
> you hadn't left any data items out or included any that weren't needed. 
> 
> I find the same approach works equally well for interactive systems. 
> 
This is what the BDD (behaviour driven development) folks do, start with
the UI (GUI or otherwise). This is simply a commonsense approach
provided that one knows when to use it, and when not to.

Like I mentioned to Jeff H. in another reply in this thread, there
aren't that many software methodologies really. Although surely a lot of
people are busy churning out new labels for old stuff. The outside-in
aspect of BDD, that's me decades ago writing a new C tool during a
scientific programming contract and devising how I want to configure C
getopt this time. Or even further back doing the same basic things in
FORTRAN 66 [1] or 77.

I don't mind too much the new folks "discovering" "new" methodologies
insofar as it might help to sell old tried-and-true techniques. But I
sure wish they would occasionally acknowledge that they are re-packaging.

AHS

1. Which I'm pretty darned sure everyone referred to as FORTRAN IV.
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

#11193

On Tue, 10 Jan 2012 06:35:48 -0400, Arved Sandstrom wrote:

> Like I mentioned to Jeff H. in another reply in this thread, there
> aren't that many software methodologies really. Although surely a lot of
> people are busy churning out new labels for old stuff. The outside-in
> aspect of BDD, that's me decades ago writing a new C tool during a
> scientific programming contract and devising how I want to configure C
> getopt this time. Or even further back doing the same basic things in
> FORTRAN 66 [1] or 77.
>
I went on at, possibly excessive, length since I remembered a truly 
horrid design methodology whose name I've mercifully forgotten, though I 
have dim memories of it being a JMA product. It FORBADE this sort of 
attribute tracing, even going to some lengths to ensure that its design 
database/repository/thing would not support it. I remember one of their 
alleged expert design consultants getting very upset when I questioned 
this feature because she was quite unable to explain any reason, sensible 
or not, for it. One of the results of this design misfeature was that the 
project collapsed in a heap of attributeless entities, fortunately before 
any code had been written.   
  
> I don't mind too much the new folks "discovering" "new" methodologies
> insofar as it might help to sell old tried-and-true techniques. But I
> sure wish they would occasionally acknowledge that they are
> re-packaging.
>
+1
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

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

#11110

Stefan Ram wrote:
> Novice <novice@example..com> writes:
> >I'm trying to reason out the best way to pass information from an 
> >instantiating class to an instantiated class.
> 
>   This derives from the design patterns used. Read, for example:
> 
>       ...
> 
>   also
> 
>       ...

and for the Java specifics,

      Effective Java by Bloch

-- 

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mccoy@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert  <v_borchert@despammed.com>

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

#11112

On 01/08/2012 11:41 AM, Novice wrote:
> Sorry, that's probably not the best of subject lines but I'm having trouble
> coming up with a concise one....
>
> I'm trying to reason out the best way to pass information from an
> instantiating class to an instantiated class. So, let's say class Foo
> invokes class Bar to do something. Bar needs some specific information from
> Foo to do its job. What is the best way to pass this information from Foo
> to Bar?
>
Look at the API of an open source project similar to yours. Or even a 
dissimilar one. I use Eclipse, others Netbeans, both have an API that 
you can study.

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

#11119

On 01/08/2012 01:43 PM, Jeff Higgins wrote:
> On 01/08/2012 11:41 AM, Novice wrote:
>> Sorry, that's probably not the best of subject lines but I'm having
>> trouble
>> coming up with a concise one....
>>
>> I'm trying to reason out the best way to pass information from an
>> instantiating class to an instantiated class. So, let's say class Foo
>> invokes class Bar to do something. Bar needs some specific information
>> from
>> Foo to do its job. What is the best way to pass this information from Foo
>> to Bar?
>>
> Look at the API of an open source project similar to yours. Or even a
> dissimilar one. I use Eclipse, others Netbeans, both have an API that
> you can study.
For instance in the Eclipse API: Resources have Markers, Markers are 
displayed in many Views including Tasks view, Problems view, to name two 
table views. In these cases the IMarkers are displayed as records(rows). 
Notice the editing interface exposed on these views.
org.eclipse.core.resources.IResource
org.eclipse.core.resources.IMarker
org.eclipse.ui.views.tasklist
org.eclipse.ui.views.markers

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

#11114

On 01/08/2012 11:41 AM, Novice wrote:
> Sorry, that's probably not the best of subject lines but I'm having trouble
> coming up with a concise one....
>
> I'm trying to reason out the best way to pass information from an
> instantiating class to an instantiated class. So, let's say class Foo
> invokes class Bar to do something. Bar needs some specific information from
> Foo to do its job. What is the best way to pass this information from Foo
> to Bar?
>
> For instance, Foo is a class that is used to edit a table of information
> presented as a JTable. Bar is a class that is used when a new row needs to
> be inserted into the table. The person using Foo right-clicks, chooses
> "Insert" on the context menu, and Bar gets instantiated to display a dialog
> with input fields so that the user can supply the values for a new row of
> the JTable.
>
> Bar needs various things to do its job. Among these are:
> - the locale to be used since Bar can display its text in various languages
> - the logger to be used for error messages
> - a reference to Foo since Bar wants to know the parent JFrame
> - the title of the dialog
>
> There are obviously various techniques for passing information from Foo to
> Bar. You can put the information in the paramater list. You can use getters
> to obtain the information from Foo. You can make values in Foo accessible
> to Bar by making the public so that Bar can access them directly. All of
> these methods can and do get used in Java.
>
> What are the rules of thumb to use in deciding which techniques to use in
> any given case?
>
> Clearly parameter passing is used widely but parameter lists tend to be
> short, mostly in the 0 to 4 parameter range. How do you decide which of the
> possibly many things needed by class Bar get passed as parameters and which
> get passed via getters or accessed directly from Foo?
>
> My strong impression is that it's bad form to access variables directly in
> Foo and that getters are preferred, but please correct me if I'm wrong. But
> I still don't quite see when you prefer passing something in a parameter
> list rather than via a getter.
>
> I'm not sure if there is a generally agreed-upon formula here or whether it
> is more a case of individual style and preference. I'd be very interested
> in your comments on this subject. Right now, I feel like I'm being pretty
> inconsistent in my techniques and would like to standardize them along the
> best possible lines.
>
 From your posts asking for help with your table, one thing hasn’t 
become clear to me. What about your 'information'? Surely the be-all and 
end-all of your information is not display in a table. Who uses the 
information, where do you store it, how do you access it? If you are 
very clear on the structure and use of your information the CRUD will be 
much easier to visualize.

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

#11115

On 01/08/2012 02:10 PM, Jeff Higgins wrote:
> On 01/08/2012 11:41 AM, Novice wrote:
>>
>  From your posts asking for help with your table, one thing hasn’t
> become clear to me. What about your 'information'? Surely the be-all and
> end-all of your information is not display in a table. Who uses the
> information, where do you store it, how do you access it? If you are
> very clear on the structure and use of your information the CRUD will be
> much easier to visualize.
>
Often when you are considering a UI widget the best place to start 
designing is the widget's data model. The widget's data model is a 
temporary store for information coming into your application or out for 
display.

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

#11123

On Sun, 8 Jan 2012 16:41:52 +0000 (UTC), Novice <novice@example..com>
wrote, quoted or indirectly quoted someone who said :

>. What is the best way to pass this information from Foo 
>to Bar?

the most common way is with parms to a method.

Other possibilities. 
1. in parm to constructor.
2. with exposed variables (not recommended)
3. with a delegate object. See
http://mindprod.com/jgloss/delegate.html
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
If you can't remember the name of some method, 
consider changing it to something you can remember.
 

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web