Tool for inlining useless getter/setter call

[Daniele Futtorovic]

Excellent! That's exactly what I was saying as well.


I'm not sure I follow this. If you're saying that access and
mutation of internal data members, when absolutely necessary, should
be via methods rather than exposing those data members publicly, that
makes perfect sense.


I mentioned DAOs and similar data structures wrapped as objects
elsethread. While this technique is necessary in some areas of a
typical system, that level of exposure is inappropriate in
behavior-focused objects.


I agree, although no doubt someone will now come up with a
compelling exception to that rule.

It seems we all pretty much agree then.

Now where's the splitter who'll make this another "SWT" thread? ;-)

 

[Patricia Shanahan]

Patricia Shanahan a écrit :


That's exactly what he thinks too. To him, flexible means : test
everything, no invariant, no pre/post conditions, ...

How do you test *anything* if you have no invariants and no pre/post
conditions? Without pre-conditions, how do you know what the unit test
should set up? Without post-conditions, how do you know what assertions
to make about the effects of the call?

Patricia

 

[Jack]

Patricia Shanahan a écrit :

How do you test *anything* if you have no invariants and no pre/post
conditions? Without pre-conditions, how do you know what the unit test
should set up? Without post-conditions, how do you know what assertions
to make about the effects of the call?

Well we don't have unit tests

What i mean is that in every methods, we test that the fields used by the method are not null, the array have the good size, etc. And if the fields are not "like they should", the method do nothing... but we never throw any exceptions. Well we are not supposed to...

 

[Lew]

Well we don't have unit tests

What i [sic] mean is that in every methods, we test that the fields used by
the method are not null, the array have the good size, etc. And if the
fields are not "like they should", the method do nothing... but we never
throw any exceptions. Well we are not supposed to...

The biggest challenge for you professionally, Jack, is to avoid picking up
execrable programming habits from that stupid, stupid boss of yours. You will
have to keep up your learning from correct sources, like Joshua Bloch's
/Effective Java/ or articles by Brian Goetz, for example, if you don't want
that idiot's crazy ideas to ruin you.

 

[Jack]

Lew a écrit :

Well we don't have unit tests

What i [sic] mean is that in every methods, we test that the fields
used by the method are not null, the array have the good size, etc.
And if the fields are not "like they should", the method do nothing...
but we never throw any exceptions. Well we are not supposed to...

The biggest challenge for you professionally, Jack, is to avoid picking
up execrable programming habits from that stupid, stupid boss of yours.
You will have to keep up your learning from correct sources, like Joshua
Bloch's /Effective Java/ or articles by Brian Goetz, for example, if you
don't want that idiot's crazy ideas to ruin you.

Lol, you seem even more angry than me. Thanks for the input on Brian Goetz. His articles seems interesting. I'll try to find the Effective Java book too.

Thanks man !

 

[Mark Space]

Lol, you seem even more angry than me. Thanks for the input on Brian
Goetz. His articles seems interesting. I'll try to find the Effective
Java book too.

Lew's right about one thing. Assuming you are relatively new to the
profession (I didn't read the whole thread), this is terrible for your
professional development. Leave this place as soon as possible. Find
someplace where they write unit tests, at least.

 

[Lew]

Lew's right about one thing. Assuming you are relatively new to the
profession (I didn't read the whole thread), this is terrible for your
professional development. Leave this place as soon as possible. Find
someplace where they write unit tests, at least.

<http://java.sun.com/docs/books/effective/>

 

[Arne Vajhøj]

No, it's a bad practice. Wherever possible, objects should be
immutable. Where not possible, follow the rule of "tell, don't ask."
If you have classes that poke around in the internals of other classes
in order to accomplish their goals, you need to repartition your
behaviors.

Widespread use of accessors and mutators is the sign of a poorly
designed system.

I completely disagree. Let the readers choose for themselves.

Your philosophy just threw out all JavaBeans, all bean property editors,
all IDEs, all of JPA, JSTL, JSF, in fact, just about every framework
written for Java. Quite frankly, I think calling accessors and mutators
"sign of a poorly designed system" is completely whacked. It is
ingrained in Java culture to use them.

I still aver that they are a best practice. They allow, for example,
for the actual attribute members to be private, for all kinds of
checking and invariant enforcement, control of exceptions, integration
with and proliferation of useful frameworks, and are manifestly
responsible for the great growth of all kinds of useful APIs. They add
safety, enforce the fundamental values of encapsulation and
non-dependency, and author after author touts them as best practices. I
offer those facts in evidence.

Obviously it does not make any sense to make all types of objects
immutable.

The benefits of immutable are for "small" objects. There are a bunch
of them in java.lang and java.math.

Arne