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.
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.
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.
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.
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.
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)
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
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.
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.
No holds barred. And no bars holed. Except this tiny ad: