Four harmful Java idioms, and how to fix them

justforregister · 发表于 2009-2-25 23:59

Conclusion                   I have argued in thisarticle that four common Java idioms should be modified. The ultimatejustification for such changes is that they will make code demonstrablyeasier to read, understand, and use -- and, in the process, they willexhibit more compassion for the mental experience of the reader. In thecase of immutability and packaging style, they will also nudge you inthe direction of improved design.
                  In summary, I suggest that the following idioms should be favored as the preferred style:

Use a naming convention to distinguish three kinds of data, not two: local variables, fields, and method arguments.
Prefer the package-by-feature style over package-by-layer.
Prefer immutable objects over JavaBeans.
Order items in a class in terms of decreasing scope, with private items appearing last.

Ifthe arguments presented in this article are correct, then they lead toa question: Why do harmful idioms still persist in Java programmingculture, after so many years? In answer to that question, I would offerthe following speculation. Style guides and other tools published inthe early years of Java didn't have the benefit of long experience.They got most things right, but a few things wrong. This is completelynatural, and doesn't reflect poorly on their creators. Some of theseitems, which were published by Sun Microsystems, were very widelyimitated. They had a very strong influence, and were often treated asauthoritative. Perhaps they were treated with a little too muchdeference.

justforregister · 发表于 2009-2-26 00:00

The few harmful idioms that were created in the early days of Java have persisted because they become popular, ingrained habits -- and perhaps because of a little bit of consensus trance or groupthink, wherein the fact that something is popular or treated as authoritative often overrides any opposing viewpoint.
WillJava programming culture gradually change these bad habits, or willthey persist, in spite of their defects? My guess is that,unfortunately, they will remain a part of Java programming culture. ButI would love to be proved wrong!