• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

style guide - views

 
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I found this page while reading Paul's profile. A nice attempt to simplifies coding standards.
However, some of the things which I think are dated or not “right” are:
1. Matching braces always line up vertically in the same column as their construct.
2. All method names should be immediately followed by a left parenthesis.

Also, no mention on access specifier (or modifier) for methods of a class. My view is, all methods should be public to make them easy to "unit test".

What's say.

Thanks.
 
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
"Not right" is subjective: some people prefer their braces that way. This is a religious discussion not worth getting in to.

Making all methods public isn't necessarily the best way to make things testable, either; a test class can just extend the class under test, or you can use reflection.

Depending on the type of code you're writing making a method public may be a recipe for disaster (think API).

 
Rancher
Posts: 600
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

My view is, all methods should be public to make them easy to "unit test".



I totally disagree. You should only expose those methods that you intend to, and that are meaningful to the functioning of the API. Exposing methods that are only used internally needlessly increases the coupling between the class you're creating, and the classes that use that class. If, in the future you need to refactor, you'll find that it's hard to change a public API.

John.
 
David Newton
Author
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@John: I think it's important to make a distinction between different types of code, though.

As an example, a web site's action classes probably don't need many, if any, private methods--the classes won't normally be extended. An API, however, has significantly different usage and design patterns that wouldn't make sense for a one-off web application.
 
John de Michele
Rancher
Posts: 600
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@David:

Yes, I agree. I was trying to make the distinction between just making all methods public willy-nilly as Ankur proposed, and thoughtfully deciding which methods should be exposed. You're absolutely right that there are many cases where having all or most of a classes' methods public is fine and even necessary. I think that there are also cases where exposing the wrong method(s) exposes the internal workings of a class.

John.
 
ankur rathi
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree that if you are going to expose your application as an API to public (or internally too), exposing all methods might confuse users. I mostly never worked on such applications so expressed that as a statement.

@David: How extending a class will make its private methods testable?

I have few comments for reflection too but I'll take some time though...
 
Marshal
Posts: 79151
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Not a "beginning Java" question. Moving.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
http://c2.com/cgi/wiki$?MethodsShouldBePublic
 
Java Cowboy
Posts: 16084
88
Android Scala IntelliJ IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ilja Preuss wrote:http://c2.com/cgi/wiki$?MethodsShouldBePublic


I disagree, in my opinion the public API of any class should be as small as possible, and methods should be private and only be <default>, protected or public when there is a specific reason to do so.

If it's about testability, then give your methods default (package) access instead of public, and put your test classes in the same package (but in a different source tree) as the program classes themselves.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, that was a link to a discussion, not an opinion (and a quite interesting one, I'd say), so I'm not sure that it's even possible to disagree with it.

 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my not so humble opinion:

- wanting to test a method directly that is not naturally part of the public API of a class is a smell. Most likely, that method belongs to a different class, where it would naturally be public.

- there is a big difference between a public and a published method: http://martinfowler.com/ieeeSoftware/published.pdf
 
ankur rathi
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ilja Preuss wrote:
- there is a big difference between a public and a published method: http://martinfowler.com/ieeeSoftware/published.pdf



More of a word game, IMO.
If it's public & it's public API then it's published. You can't do anything about it...





 
ankur rathi
Ranch Hand
Posts: 3852
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ilja Preuss wrote:In my not so humble opinion:

- wanting to test a method directly that is not naturally part of the public API of a class is a smell. Most likely, that method belongs to a different class, where it would naturally be public.



Do you say that a class will never have private methods which need tests?
 
John de Michele
Rancher
Posts: 600
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ankur:

Private methods don't exist in a vacuum. They are called by public methods to do behind-the-scenes work, and will therefore be tested when the public method that calls them is tested.

John.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

ankur rathi wrote:

Ilja Preuss wrote:In my not so humble opinion:

- wanting to test a method directly that is not naturally part of the public API of a class is a smell. Most likely, that method belongs to a different class, where it would naturally be public.



Do you say that a class will never have private methods which need tests?



A private method that needs its own tests is likely to be a non-trivial method. That the method is private means that it isn't the main responsibility of the class - the main responsibility of a class is in its public methods. Having a non-trivial private method in a class violates the Single Responsibility Principle. Moving that method to a class where it is naturally public improves the design.
 
Ranch Hand
Posts: 177
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
(By the way... Obviously, you can't create a jUnit test for a private method. The closest you can come is to make the method package level, and put the jUnit test in the same package. I guess the normal practice is to create a "test" source directory, and put jUnit tests there, with each test class in the same package as the class it's testing. From a theoretical point of view, you don't really need to test private methods since you only really care about "outside" behavior. For example, I can write a complete test for ArrayList even though I have no idea how the author implemented it.)
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Max Rahder wrote:(By the way... Obviously, you can't create a jUnit test for a private method.)



Actually, you can. You can directly access private methods using reflection. It's a bad hack, though. The only reason I can think of to ever use it is to write a test for a third party component.
reply
    Bookmark Topic Watch Topic
  • New Topic