Best Way to Pass Info Between Objects?

[Jeff Higgins]

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.

 

[Jeff Higgins]

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>

 

[Arved Sandstrom]

<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

 

[Jeff Higgins]

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>

 

[Stefan Ram]

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:
|>> 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.)

 

[Jeff Higgins]

I do not see a misattribution. Let me explain:

|> On 01/09/2012 07:36 AM, Stefan Ram wrote:
|>> 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.

 

[Martin Gregorie]

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

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.

 

[Gene Wirchenko]

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

 

[Arved Sandstrom]

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.

 

[Arved Sandstrom]

I do not see a misattribution. Let me explain:

|> On 01/09/2012 07:36 AM, Stefan Ram wrote:
|>> 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

 

[Lew]

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]

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.

 

[Martin Gregorie]

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

 

[Arved Sandstrom]

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