• 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
Sheriffs:
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Carey Brown

Sequence of Methods in a class

 
Ranch Hand
Posts: 121
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Besides personal preference, is there a (for lack of better phrase) standard design way of sequencing methods in a given class?

By that I mean: given a simple example,



My personal preference has always been to define methods bA() and cA() in the class before calling them in method aA().  However I've seen that some others define aA() first, and the methods being called (i.e. bA() and cA()) are defined after the aA() method.

Thanks

p.s. I've left out Static and Instance considerations, because my question goes to design based on functionality grouping, rather than java execution sequence.
 
Bartender
Posts: 7202
65
Eclipse IDE Firefox Browser MySQL Database VI Editor Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Personal preference: if A calls B then C, I will define then in that order, that way when you go to read 'B' you have some context. But I don't adhere to this religiously. I also tend to migrate static utility methods lower down in the class followed by inner classes.
 
Jake Monhan
Ranch Hand
Posts: 121
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So looks like is a choice of does one want the UML diagram to show what each method does, and then how they all interact - VS - showing what functional call each method needs to make to another method and then defining that method.

That being said, I would hazard a comment that it all comes down to a combination of personal choice and case by case design need.

Thanks for the input.
 
Marshal
Posts: 3149
466
Android Eclipse IDE TypeScript Redhat MicroProfile Quarkus Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jake Monhan wrote:So looks like is a choice of does one want the UML diagram to show what each method does, and then how they all interact - VS - showing what functional call each method needs to make to another method and then defining that method.


Which type of UML diagram are you thinking of? A structural diagram like a Class diagram would show relationships between the classes, but not which particular methods/functions might be called.
 
Bartender
Posts: 1268
39
IBM DB2 Netbeans IDE Spring Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My personal taste: constructors, factory static methods, public methods, then protected / private ones. It helps me to verify at a glance if I'm not breaking encapsulation (for example exposing too many methods as public)
 
Marshal
Posts: 69847
278
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think even the old Sun style guide has a ruling; I think it simply said to keep related methods together.

[edit]A spelling correction and change part of the text to a link.
 
Saloon Keeper
Posts: 2624
128
Google Web Toolkit Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As a personal preference, I do write the methods containing @Override at the top. This allows me to quickly glance a class code to see what's special about it. I do rely on the IDE a lot to look at the methods. Eclipse, for example, has an "Outline" view that allows you to see methods either as the order in which they are written or in alphabetical order. It also allows you to filter out static, non-public methods etc. Alphabetic sorting shows getters and setters together.
While following a pattern of writing methods is good and would help you structure your own code well, you cant expect everyone in your team to do the same
 
Sheriff
Posts: 15801
264
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're working on a team, the team's coding standards might be what determines the order. I would never expect the order of methods in a UML class diagram to reflect the source order nor is it meant to dictate it. in UML diagrams, I'd expect the scope to determine the grouping, i.e., private methods together first, and public methods together listed last, everything else in between. This is what I've come to expect to see at least.
 
Jake Monhan
Ranch Hand
Posts: 121
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Considering the number of different responses, it looks like it does come down to personal choice, unless effected by outside forces.

As for the UML part: besides one showing the class relationship, also creating one that shows the relationship of the methods within each class.  As to that end, sometimes it has helped, sometimes it is nothing more than too much information!

Thanks every one.
 
They gave me pumpkin ice cream. It was not pumpkin pie ice cream. Wiping my tongue on this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic