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 1 of 2  [1] 2  Next page →

#11106 — Best Way to Pass Info Between Objects?

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.

-- 
Novice

[toc] | [next] | [standalone]

#11109

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

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

#11111

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?

-- 
Novice

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

#11113

On 1/8/2012 10:22 AM, Novice wrote:

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


Loose Coupling is one such general rule.

<http://en.wikipedia.org/wiki/Loose_coupling>

This is basically what Patricia is advocating, as classes that are 
loosely coupled tend also to be easier to unit test.

For example, you seem to have a lot of different (and fairly complex) 
classes running around your code right now.  One way to simplify unit 
testing is to use mock objects.

<http://www.ibm.com/developerworks/library/j-mocktest/index.html>

There's some good links in both of those articles to get you started.

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

#11116

Novice wrote:
> Patricia Shanahan<pats@acm.org>  wrote :
>> Novice wrote:
>>> ...
>>> 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.

Parameters.

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

Mastery can occur in a flash.  Knowledge takes longer, but key points will 
carry you as far as you need in the short term.

If you read /Effective Java/ as Volker Borchert recommended, you will have 
enough to make you competent, provided you understand and practice Joshua 
Bloch's suggestions.

What follows is a long and detailed answer that incorporates what others have 
told you and provides specific examples.  I have not actually compiled these 
examples, but I intended them to be compilable.

Summary:

It's all about the model (types, attributes, behaviors).

You should program in terms of interfaces and generics with interface parameters.

Express your model in terms of experiments to try to break it.  Those are tests.
Write an interface for each type you're modeling.  Too much in the interface? 
  Refactor.  A type should be cohesive.
Write a test class for the interface.  You can write it one test method at a 
time, but the test class will eventually cover all public (and protected) 
methods of the implementation.
Write the minimum compilable implementation of the interface so you can run 
the tests.
Observe the test failures.
Fix it.
Often fixing the test failure means a modification to the test class, just as 
we added the explicit test for the constructor failure in the example.
Repeat until the whole type passes all tests.

That cycle applies any time the type or an implementation of it changes.  A 
smart developer uses a continuous-integration tool like Hudson or many others 
to rerun a test suite any time changes are checked in to version control.

One last thing - be pretty familiar with the classes in the java.lang.* and 
java.util.* packages, especially the collections framework.

Long answer:

You have to map out the behaviors correctly, then the methods and constructors 
make sense.  Don't send a person's name, address, favorite color, medical 
history and descriptions of pets as discrete parameters, but as properly 
modeled objects:

   register(Person person, Collection<Pet> pets)

The signature is concise and easy to read, yet the parameters can manipulate 
quite a lot of data.  Constructors can be a little hairier because they 
assemble such disparate particles, but even those should be modeled:

   public Person(Name name, Calendar dob,
                 Collection<Relationship> relationships)

Where you absolutely must specify lots of teeny little things to build an 
object, use a builder that ultimately returns the desired type, preferably as 
an immutable target.

   String message = new StringBuilder("This is the ").append(count)
       .append("th inference since ").append(formatter.format(rememberWhen))
       .append('.').toString();

Programming is as much or more a way of thinking about problems as it is 
coding.  Anyone can write code, but you still need the right code.

This comes from how you model the scenario or process or whatever you seek to 
express in a program.  As you model your problem space, look for patterns as 
Stefan Ram recommended, not just the formal ones in the literature but in 
general terms.  I call it "nouns and verbs" - what are the actors (nouns) and 
their attributes (adjectives) and their behaviors (action verbs).  Nouns are 
types, attributes are getters (accessor methods) and setters (mutator 
methods), and action verbs are behavioral methods.

Here's a Person type (noun) with just one attribute (adjective), how it's named:

   public interface Person
   {
     String getName();
   }

Without a very good reason otherwise, all attributes should be 'getX()' only, 
not 'setX(X x)'.  Then you make the underlying variable 'final' and immutable 
as well.

Now express your model as experiments, or tests - "if I return a person's name 
(attribute 'getName()') I will never get a 'null'."  For this you'll need an 
interface to express the type:

and a unit test:

   import static org.junit.Assert.assertNotNull;
   import org.junit.Before;
   import org.junit.Test;

   public class PersonTest
   {
     Person person;
     @Before public void initialize()
     {
       person = new PersonImpl();
     }

     @Test public void testGetName()
     {
       assertNotNull("null name", person.getName());
     }
   }

Oh, that means you need a 'PersonImpl'.  Go barebones at first; let the test 
fail with the very minimum code needed to compile.

   public class PersonImpl implements Person
   {
     @Override
     public String getName()
     {
       return null;
     }
   }

Gosh, how can you make the test pass?  Guess you'd better give that Person a 
name.  Better make it read-only!

   public class PersonImpl implements Person
   {
     private static final String name;

     public Person(String name)
     {
       this.name = name;
     }

     @Override
     public String getName()
     {
       return name;
     }
   }

That forces a change to the test:

   public class PersonTest
   {
     Person person;
     @Before public void initialize()
     {
       person = new PersonImpl();
     }

     @Test public void testGetName()
     {
       Person person = new Person(null);
       assertNotNull("null name", person.getName());
     }
   }

Oh, we really should expect an exception if you try to instantiate a 'null' 
name.  Write the test first.

   public class PersonTest
   {
     private static final String TEST_NAME = "Jan Doe";

     Person person;

     @Test(expected=IllegalArgumentException.class)
     public void testGetNameNull()
     {
       Person person = new Person(null);
     }

     @Test public void testGetName()
     {
       Person person;
       try
       {
         person = new Person(TEST_NAME);
       }
       catch (Exception exception)
       {
         fail("unexpected exception. " + exception.getLocalizedMessage());
       }
       assertNotNull("null name", person.getName());
     }
   }

Now change the implementation to pass the test:

   public class PersonImpl implements Person
   {
     private static final String name;

     public Person(String name)
     {
       if (name == null)
       {
         throw new IllegalArgumentException("null name");
       }
       this.name = name;
       assert this.name != null
     }

     @Override
     public String getName()
     {
       assert this.name != null
       return name;
     }
   }

The 'assert' keyword marks where the algorithm depends on certain facts, in 
this case the non-nullity of the 'name' attribute.  It's a postcondition of 
the constructor and a precondition of the getter.

It's a lot of frakkin boilerplate in the implementation, or concrete class.  I 
prefer to think of it as armor plate.  Anyway, once you've set all the castle 
guards at the concrete class, you use the interface for general programming:

   public class CountryClub
   {
     private final Set<Person> members = new HashSet<Person>();

     public boolean addMember(Person person)
     {
       if (isUnqualified(person))
       {
         throw new SnobException("We do not find " + person + " suitable.");
       }
       return members.add(person);
     }

     public String showMembers()
     {
       return members.toString();
     }

     private boolean isUnqualifed(person)
     {
       return person.getName().equals("Lew");
     }
   }

By the way, that SnobException message and 'showMembers()' show us the need 
for a 'Person#toString()' method, and if you read /Effective Java/ you see 
that that goes hand-in-glove with 'equals(Object other)', 'hashCode()' and 
'compareTo(Person other)' (if the type is 'Comparable').  All four (or three 
if not 'Comparable') methods must agree on what makes one 'Person' different 
from another.  (Hint: In this simple model the name attribute should be 
unique, so equality and hash will be based entirely on the name, and 
'toString()' will return the name.)

You can write a test for that.

There you go, mastery in a flash.

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

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

#11117

On 1/8/2012 10:22 AM, 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?
>

That is why I suggested unit test during design, as a complement to the
book recommendations. I have no problem with the books that have been
proposed, but it will take time to read, absorb, and apply them. You can
apply unit test during design immediately.

Patricia

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

#11118

On Sun, 08 Jan 2012 14:04:05 -0800, Patricia Shanahan wrote:

> On 1/8/2012 10:22 AM, 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?
>>
>>
> That is why I suggested unit test during design, as a complement to the
> book recommendations. I have no problem with the books that have been
> proposed, but it will take time to read, absorb, and apply them. You can
> apply unit test during design immediately.
>
+1

..but don't forget that the unit tests *must* be written from the 
specifications and *NEVER* from looking at the code. A good half-way 
house, which I use a lot, is to write what's effectively an abstract 
class with the entire class specification spelled out in the class- and 
method-level comments, with just enough meat in the methods, i.e. return 
statements, to allow the resulting source file to be compiled. Then I 
generate the javadocs and use only these as the basis for writing the 
unit tests.

Actually, I've usually completed and compiled the class before I write 
the unit tests, but I'd suggest you write the tests first until you get 
into the required 'no peeking' frame of mind needed for writing the tests 
from the specifications and only the specifications. There are two 
additional benefits: (1) you get into the habit of writing worth-while 
class and method documentation and (2) this forces you to think about how 
your new class will actually be used. This will probably improve both the 
design and documentation if you alter the design to overcome usability 
problems as you find them. 


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

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

#11120

Martin Gregorie wrote:
> On Sun, 08 Jan 2012 14:04:05 -0800, Patricia Shanahan wrote:
> 
>> On 1/8/2012 10:22 AM, 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?
>>>
>>>
>> That is why I suggested unit test during design, as a complement to the
>> book recommendations. I have no problem with the books that have been
>> proposed, but it will take time to read, absorb, and apply them. You can
>> apply unit test during design immediately.
>>
> +1
> 
> ..but don't forget that the unit tests *must* be written from the 
> specifications and *NEVER* from looking at the code. A good half-way 
> house, which I use a lot, is to write what's effectively an abstract 
> class with the entire class specification spelled out in the class- and 
> method-level comments, with just enough meat in the methods, i.e. return 
> statements, to allow the resulting source file to be compiled. Then I 
> generate the javadocs and use only these as the basis for writing the 
> unit tests.
> 
> Actually, I've usually completed and compiled the class before I write 
> the unit tests, but I'd suggest you write the tests first until you get 
> into the required 'no peeking' frame of mind needed for writing the tests 
> from the specifications and only the specifications. There are two 
> additional benefits: (1) you get into the habit of writing worth-while 
> class and method documentation and (2) this forces you to think about how 
> your new class will actually be used. This will probably improve both the 
> design and documentation if you alter the design to overcome usability 
> problems as you find them. 
> 
> 

+1

I actually typed a paragraph along these lines, but decided to stick to
the idea of unit tests as a way of encouraging good module design.

Patricia

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

#11121

On 12-01-08 07:56 PM, Patricia Shanahan wrote:
> Martin Gregorie wrote:
>> On Sun, 08 Jan 2012 14:04:05 -0800, Patricia Shanahan wrote:
[ SNIP ]

>>>>
>>> That is why I suggested unit test during design, as a complement to the
>>> book recommendations. I have no problem with the books that have been
>>> proposed, but it will take time to read, absorb, and apply them. You can
>>> apply unit test during design immediately.
>>>
>> +1
>>
>> ..but don't forget that the unit tests *must* be written from the
>> specifications and *NEVER* from looking at the code. A good half-way
>> house, which I use a lot, is to write what's effectively an abstract
>> class with the entire class specification spelled out in the class-
>> and method-level comments, with just enough meat in the methods, i.e.
>> return statements, to allow the resulting source file to be compiled.
>> Then I generate the javadocs and use only these as the basis for
>> writing the unit tests.
>>
>> Actually, I've usually completed and compiled the class before I write
>> the unit tests, but I'd suggest you write the tests first until you
>> get into the required 'no peeking' frame of mind needed for writing
>> the tests from the specifications and only the specifications. There
>> are two additional benefits: (1) you get into the habit of writing
>> worth-while class and method documentation and (2) this forces you to
>> think about how your new class will actually be used. This will
>> probably improve both the design and documentation if you alter the
>> design to overcome usability problems as you find them.
>>
> 
> +1
> 
> I actually typed a paragraph along these lines, but decided to stick to
> the idea of unit tests as a way of encouraging good module design.
> 
> Patricia

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.

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

AHS

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.
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

#11130

On 01/09/2012 07:36 AM, Stefan Ram wrote:
> Arved Sandstrom<asandstrom3minus1@eastlink.ca>  writes:
>    TDD is not the only methodology,

:) <http://en.wikipedia.org/wiki/List_of_software_development_philosophies>

:) "This list is incomplete; you can help by expanding it."

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

#11131

On 01/09/2012 12:39 PM, Jeff Higgins wrote:
> On 01/09/2012 07:36 AM, Stefan Ram wrote:
>> Arved Sandstrom<asandstrom3minus1@eastlink.ca> writes:
>> TDD is not the only methodology,
>
> :) <http://en.wikipedia.org/wiki/List_of_software_development_philosophies>
>
> :) "This list is incomplete; you can help by expanding it."
>
Note that the Spiral method is not to be confused with the Helical method.

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

#11138

On Monday, January 9, 2012 9:39:42 AM UTC-8, Jeff Higgins wrote:
Stefan Ram wrote:
> Arved Sandstrom writes:
>>    TDD is not the only methodology,
> 
> :) <http://en.wikipedia.org/wiki/List_of_software_development_philosophies>
> 
> :) "This list is incomplete; you can help by expanding it."

A complete list would have one entry per practitioner.

-- 
Lew

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

#11143

On 01/09/2012 04:43 PM, Lew wrote:
> On Monday, January 9, 2012 9:39:42 AM UTC-8, Jeff Higgins wrote:
> Stefan Ram wrote:
>> Arved Sandstrom writes:
>>>     TDD is not the only methodology,
>>
>> :)<http://en.wikipedia.org/wiki/List_of_software_development_philosophies>
>>
>> :) "This list is incomplete; you can help by expanding it."
>
> A complete list would have one entry per practitioner.
>
I'm very tempted to a an item to that list: "Lew's Method", with a link 
to your excellent exposition. Thanks for that, much appreciated.

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

#11171

Jeff Higgins wrote:
> Lew wrote:
>> Jeff Higgins wrote:
>> Stefan Ram wrote:
>>> Arved Sandstrom writes:
>>>> TDD is not the only methodology,
>>>
>>> :)<http://en.wikipedia.org/wiki/List_of_software_development_philosophies>
>>>
>>> :) "This list is incomplete; you can help by expanding it."
>>
>> A complete list would have one entry per practitioner.
>>
> I'm very tempted to a an item to that list: "Lew's Method", with a link to
> your excellent exposition. Thanks for that, much appreciated.

You're welcome, but it really isn't my method, just an example of what's 
documented out there.  I'm glad you found it useful.

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

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

#11145

On 1/9/2012 1:43 PM, Lew wrote:
> On Monday, January 9, 2012 9:39:42 AM UTC-8, Jeff Higgins wrote:
> Stefan Ram wrote:
>> Arved Sandstrom writes:
>>>     TDD is not the only methodology,
>>
>> :)<http://en.wikipedia.org/wiki/List_of_software_development_philosophies>
>>
>> :) "This list is incomplete; you can help by expanding it."
>
> A complete list would have one entry per practitioner.
>

Only one?

Patricia

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

#11146

On 12-01-09 01:39 PM, Jeff Higgins wrote:
> On 01/09/2012 07:36 AM, Stefan Ram wrote:
>> Arved Sandstrom<asandstrom3minus1@eastlink.ca>  writes:
>>    TDD is not the only methodology,
> 
> :) <http://en.wikipedia.org/wiki/List_of_software_development_philosophies>
> 
> :) "This list is incomplete; you can help by expanding it."
> 

I didn't make the comment you attributed to me, Stefan did. And in fact
Stefan would be mis-quoted if you don't add his "where one writes the
calls before one write the callee".

Stefan is right: it's quite common to use top-down coding in procedural
languages especially. But TDD is neutral when it comes to "top-down" and
"bottom-up"; one could just as easily be building bottom-up when using TDD.

As far as software development *methodologies* go, as opposed to
"philosophies", there aren't that many primary types, probably less than
a dozen. Nobody's doing anything new, except for coining labels.

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

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

#11148

On 01/09/2012 06:06 PM, Arved Sandstrom wrote:
> On 12-01-09 01:39 PM, Jeff Higgins wrote:
>> On 01/09/2012 07:36 AM, Stefan Ram wrote:
>>> Arved Sandstrom<asandstrom3minus1@eastlink.ca>   writes:
>>>     TDD is not the only methodology,
>>
>> :)<http://en.wikipedia.org/wiki/List_of_software_development_philosophies>
>>
>> :) "This list is incomplete; you can help by expanding it."
>>
>
> I didn't make the comment you attributed to me, Stefan did. And in fact
> Stefan would be mis-quoted if you don't add his "where one writes the
> calls before one write the callee".
Yep, I did. I apologize for the misattribution.
I'm hoping Stefan will accept the misquote in the spirit in which it was 
misquoted.
>
> Stefan is right: it's quite common to use top-down coding in procedural
> languages especially. But TDD is neutral when it comes to "top-down" and
> "bottom-up"; one could just as easily be building bottom-up when using TDD.
>
> As far as software development *methodologies* go, as opposed to
> "philosophies", there aren't that many primary types, probably less than
> a dozen. Nobody's doing anything new, except for coining labels.
Great!
<http://en.wikipedia.org/wiki/Software_development_methodology>

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

#11151

On 01/09/2012 07:07 PM, Stefan Ram wrote:
> Jeff Higgins<jeff@invalid.invalid>  writes:
>> On 01/09/2012 06:06 PM, Arved Sandstrom wrote:
>>> On 12-01-09 01:39 PM, Jeff Higgins wrote:
>>>> On 01/09/2012 07:36 AM, Stefan Ram wrote:
>>>>> Arved Sandstrom<asandstrom3minus1@eastlink.ca>    writes:
>>>>>      TDD is not the only methodology,
> (...)
>>> I didn't make the comment you attributed to me, Stefan did. And in fact
>>> Stefan would be mis-quoted if you don't add his "where one writes the
>>> calls before one write the callee".
>> Yep, I did. I apologize for the misattribution.
>
>    I do not see a misattribution. Let me explain:
>
> |>  On 01/09/2012 07:36 AM, Stefan Ram wrote:
> |>>  Arved Sandstrom<asandstrom3minus1@eastlink.ca>    writes:
> |>>      TDD is not the only methodology,
>
>    The number of greater-than signs at the left indicate that
>    »TDD is not the only methodology,« was written by me.
>    It was written by me. So, there is no misattribution.
>
>    But since I feel somewhat annoyed having to explain this,
>    feel all free to apologize for the mismisattribution!
>
>    (Just kinding, there is no need to apologize.)
>
Righto. I'm off to begin a thread on JML. :)

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

#11161

On 12-01-09 08:07 PM, Stefan Ram wrote:
> Jeff Higgins <jeff@invalid.invalid> writes:
>> On 01/09/2012 06:06 PM, Arved Sandstrom wrote:
>>> On 12-01-09 01:39 PM, Jeff Higgins wrote:
>>>> On 01/09/2012 07:36 AM, Stefan Ram wrote:
>>>>> Arved Sandstrom<asandstrom3minus1@eastlink.ca>   writes:
>>>>>     TDD is not the only methodology,
> (...)
>>> I didn't make the comment you attributed to me, Stefan did. And in fact
>>> Stefan would be mis-quoted if you don't add his "where one writes the
>>> calls before one write the callee".
>> Yep, I did. I apologize for the misattribution.
> 
>   I do not see a misattribution. Let me explain:
> 
> |> On 01/09/2012 07:36 AM, Stefan Ram wrote:
> |>> Arved Sandstrom<asandstrom3minus1@eastlink.ca>   writes:
> |>>     TDD is not the only methodology,
> 
>   The number of greater-than signs at the left indicate that
>   »TDD is not the only methodology,« was written by me.
>   It was written by me. So, there is no misattribution.
> 
>   But since I feel somewhat annoyed having to explain this,
>   feel all free to apologize for the mismisattribution!
> 
>   (Just kinding, there is no need to apologize.)
> 
You're correct. Your annoyance is presumably misplaced, if you actually
believe that a majority of readers would pick up on that nuance. I
suspect the majority of people would do as I did, look at the last
quoted author. Regardless of the symbols (> for you, vertical coloured
bars for me), leaving in authors' names when zero content by them is
actually quoted is a mistake.

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

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

#11153

On Mon, 09 Jan 2012 12:36:11 +0000, Stefan Ram wrote:

>   TDD is not the only methodology, where one writes the calls before one
>   write the callee. In the 70s we already had something called »top-down
>   programming« where one writes the upper-level methods first and then
>   implements the operations they call.
>
Indeed. IIRC I first found the idea of Top-down Incremental Development 
(TID) in "Software tools in Pascal" and have used it ever since. I like 
the idea of getting the bugs out of the top level before adding the next 
level down.

I find that my preferred method of writing Java is to do the proper OOD 
thing for the collection of classes that implement code that's specific 
to the algorithm to be implemented but often revert to TID when I'm 
building the framework that will drive the application.  


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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web