• 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

Sequence Diagrams

 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
I have an object which has many private behaviors i.e. private methods. Now when I design a Sequence Diagram to depict the behavior of the said object, do I need to show this behaviors as self calls OR self delegations? OR it can be avoided
yup
- Raj
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Depends on why / whom for you are drawing the diagram. Will it be usefull information for the audience to know about the method calls?
 
Raj Waters
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Lets assume the audience is interested to know the method calls. Now will it be proper to show few self calls in a SD OR is having too many self calls in an object is a bad design OR a case of low cohesion?
yup
- Raj
MCSE, SCJP, SCWCD
 
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, first: many small methods are better than one big one.
But: many methods in a class are also a design smell - a sign that the class is trying to do to much (with other words: low cohesion, yes).
Did that help???
 
Raj Waters
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ya thanx
I guess its a fantastic case of low cohesion if there are too many private methods. But what if methods are just to ensure modularity? Will it still mean low cohesion?
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Following some of the examples in Ron Jeffries Adventures in C# and other refactoring examples, they favor lots of short methods. Back in the old days, we called it Functional Decomposition. Now I guess it helps make methods testable and helps humans comprehend the method.
Actually the rules they follow to get to many short methods don't sound like they'd lead you there. 1) Eliminate duplication. If you see the same code twice - even part of a line some times - factor it out to its own method or class. 2) Use the fewest possible classes and methods. This sound contradictory, but you do it only after eliminating duplication. Oh, and Rule 0 Do The Simplest Thing That Can Possibly Work tells you not to factor something out to its own method until you see it twice!
You don't harm the cohesion of a class unless you broaden its responsibilities. Decomposing it into tiny private methods doesn't change what it does.
Any thoughts? Is the code at the end of Ron's "contiguous owners" example something you'd like to put your name on or run across at work?
 
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

Originally posted by Stan James:
Actually the rules they follow to get to many short methods don't sound like they'd lead you there. 1) Eliminate duplication. If you see the same code twice - even part of a line some times - factor it out to its own method or class. 2) Use the fewest possible classes and methods. This sound contradictory, but you do it only after eliminating duplication. Oh, and Rule 0 Do The Simplest Thing That Can Possibly Work tells you not to factor something out to its own method until you see it twice!


I think there is missing a rule: Let the code communicate every idea you want it to communicate.
That is, if (for example) a method is so big that you feel the need to separate it into blocks (probably even to comment what the different blocks are doing), extract them into separate methods and let the method names speak for them.

You don't harm the cohesion of a class unless you broaden its responsibilities. Decomposing it into tiny private methods doesn't change what it does.


Correct. But a small number of *very big* methods is a sign of lack of cohesion, too...


Any thoughts? Is the code at the end of Ron's "contiguous owners" example something you'd like to put your name on or run across at work?


Yes, it's the way I like my code.
Take a look at http://groups.yahoo.com/group/refactoring/message/3414 for another example of how I like my code... (And notice Ron's answer... )
[ June 19, 2003: Message edited by: Ilja Preuss ]
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic