This notation reflects particular traits of your object-oriented code as little drawn dudes. As a result, codebase can be represented visually, and badness of bad decisions becomes visual and obvious.
- Dudes - objects
- Arms (or any other limbs) - methods
- Tube-fingers - parameters
- Shake/touch object's hand - call corresponding method
- "@"-symbols in the brain - instance variables
- "Internal" hands - private methods
- Swallen hands - too much conditional logic
- Legs - same as hands (can be used to reflect "getter" methods)
- Spawning platforms - classes
class Book
attr_reader :title, :author
def initialize(title, author)
@title = title
@author = author
end
end
- exploring other developers' code
- exlaining tricky concepts
- use it as a compact way to reflect code complexity
- visualize "bigger picture" in real projects
- see how things change in dynamics
Presentation "Solving Architectural Problems with OOP in Pictures"
You don't have to visualize every single aspect of your class. For example, if for your task instance variables or private methods are not important, you simply don't draw them.
The same goes for classes/objects you want to reflect. For example, when you work on a feature or refactor a part of your code, you might be interested to visualize only a subset of classes.
-
You can use colors to identify classes from different layers of abstractions, or classes of specific namespace.
-
Code coverage, code performance (Big-O notation), churn rate, vulnerabilities, any code complexity metrics can be easily reflected on bodies of the dudes.
It was developed for Ruby language, but it can be modified to reflect rules of other Languages. For example, for statically typed languages "tube-fingers" would have different shapes, and only accept arguments of the same shape.