The document outlines 9 steps or rules for improving object-oriented code known as Object Calisthenics. The rules are: 1) Only one level of indentation per method. 2) Do not use else keywords. 3) Wrap primitive types if they have behavior. 4) Only one dot per line. 5) Do not abbreviate. 6) Keep classes small. 7) No more than two instance variables per class. 8) Use first class collections. 9) Do not use setters/getters. Following these rules aims to make code more readable, reusable, testable and maintainable. The document provides examples of applying each rule and discusses the benefits of doing so.

1. Object Calisthenics
9 steps to better OO code

2. Agenda
Learn how to make our code more:
readable
reusable
testable
maintainable

3. Raise you hand if you know
one of the following:
DRY
KISS
SOLID
YAGNI
Zen of Python

4. Calisthenics

5. Cal • is • then • ics - /ˌkaləsˈTHeniks/

6. "Calisthenics are exercises consisting of a
variety of gross motor movements; often
rhythmical and generally without equipment
or apparatus."
Wikipedia

7. Object Calisthenics
Jeff Bay

8. Written for Java

9. Why bother?

10. Code is read more
than it's written
Author unknown

11. You need to write code that
minimizes the time it would
take someone else to
understand it - even if that
someone else is you
Art of Readable Code by Dustin Boswell,
Trevor Foucher

12. Rule #1
Only one level of
indentation per method

13. class Board(object):
def __init__(self, data):
# Level 0
self.buf = ""
for i in range(10):
# Level 1
for j in range(10):
# Level 2
self.buf += data[i][j]

14. class Board(object):
def __init__(self, data):
self.buf = ""
self.collect_rows(data)
def collect_rows(self, data):
for i in range(10):
self.collect_row(data[i])
def collect_row(self, row):
for j in range(10):
self.buf += row[j]

15. products = self.get_products_by_user(...)
if products is None:
products = self.get_products_by_media(...)
if products is None:
products = self.get_products_by_domain(...)
if products is None:
products = self.get_any_products(...):
if products is None:
raise Exception('Access denied')
else:
...
else:
...
else:
...
else:
...

16. Chain of command

17. Benefits
Single responsibility
Better naming
Shorter methods
Reusable methods

18. Rule #2
Do not use else keyword

19. if options.get_categories() is None:
...
elif len(options.get_categories()) == 1:
...
elif SPECIAL_CATEGORY in options.get_categories():
...
elif options.get_categories() and options.get_query():
...
elif options.get_content_type():
...

20. def login (self, request):
if request.user.is_authenticated():
return redirect("homepage")
else:
messages.add_message(request,
messages.INFO,
'Bad credentials')
return redirect("login")

21. def login (self, request):
if request.user.is_authenticated():
return redirect("homepage")
messages.add_message(request,
messages.INFO,
'Bad credentials')
return redirect("login")

22. def function(param):
if param is not None:
value = param
else:
value = "default"
return value

23. def function(param):
value = "default"
if param is not None:
value = param
return value

25. Extract code

26. Default value

27. Polymorphism

28. Strategy pattern

29. State pattern

30. Examples
https://github.com/gennad/Design-Patterns-in-Python

31. https://www.quora.com/Is-it-true-that-a-good-
programmer-uses-fewer-if-conditions-than-an-amateur

32. Benefits
Avoids code duplication
Lower complexity
Readability

33. Rule #3
Wrap primitive types if it
has behaviour

34. Value Object in DDD

35. class Validator(object):
def check_date(self, year, month, day):
pass
# 10th of December or 12th of October?
validator = Validator()
validator.check_date(2016, 10, 12)

36. class Validator(object):
def check_date(self, year: Year, month: Month, day: Day) -> bool:
pass
# Function call leaves no doubt.
validator.check_date(Year(2016), Month(10), Day(12))

37. Benefits
Encapsulation
Type hinting
Attracts similar behaviour

38. Rule #4
Only one dot per line

39. OK: Fluent interface

40. class Poem(object):
def __init__(self, content):
self.content = content
def indent(self, spaces):
self.content = " " * spaces + self.content
return self
def suffix(self, content):
self.content = self.content + " - " + content
return self
Poem("Road Not Travelled").indent(4)
.suffix("Robert Frost")
.content

41. Not OK: getter chain

42. class CartService(object):
def get_token(self):
token = self.get_service('auth')
.auth_user('user', 'password')
.get_result()
.get_token()
return token
# 1. What if None is returned instead of object?
# 2. How about exceptions handling?

43. class Field(object):
def __init__(self):
self.current = Piece()
class Piece(object):
def __init__(self):
self.representation = " "
class Board(object):
def board_representation(self, board):
buf = ''
for field in board:
buf += field.current.representation
return buf

44. class Field(object):
def __init__(self):
self.current = Piece()
def add_to(self, buffer):
return self.current.add_to(buffer)
class Piece(object):
def __init__(self):
self.representation = " "
def add_to(self, buffer):
return buffer + self.representation
class Board(object):
def board_representation(self, board):
buf = ''
for field in board:
buf = field.add_to(buf)
return buf

45. Benefits
Encapsulation
Demeter's law
Open/Closed Principle

46. Rule #5
Do not abbreviate

47. Why abbreviate?

48. Too many responsibilities

49. Name too long?

50. Split & extract

51. Duplicated code?

52. Refactor!

53. class Order(object):
def ship_order(self):
pass
order = Order()
order.ship_order()
// vs
class Order(object):
def ship(self):
pass
order = Order()
order.ship()

54. acc = 0
// accumulator? accuracy?
pos = 100
// position? point of sale? positive?
auth = None
// authentication? authorization? both?

55. Benefits
Clear intentions
Indicate underlying problems

56. Rule #6
Keep your classes small

57. What is small class?
15-20 lines per method
50 lines per class
10 classes per module

58. Benefits
Single Responsibility
Smaller modules

59. Rule #7
No more than 2 instance
variable per class

60. Class should handle single
variable state

61. In some cases it might be
two variables

63. class CartService(object):
def __init__(self):
self.logger = Logger()
self.cart = CartCollection()
self.translationService = TranslationService()
self.auth_service = AuthService()
self.user_service = UserService()

64. Benefits
High cohesion
Encapsulation
Fewer dependencies

65. Rule #8
First class collections

66. collections module

67. Benefits
Single Responsibility

68. Rule #9
Do not use setters/getters

69. Accessors are fine

70. Don't make decisions
outside of class

71. Let class do it's job

72. Tell, don't ask

73. class Game(object):
def __init__(self):
self.score = 0
def set_score(self, score):
self.score = score
def get_score(self):
return self.score
# Usage
ENEMY_DESTROYED_SCORE = 10
game = Game()
game.set_score(game.get_score() + ENEMY_DESTROYED_SCORE)

74. class Game(object):
def __init__(self):
self.score = 0
def add_score(self, score):
self.score += score
# Usage
ENEMY_DESTROYED_SCORE = 10
game = Game()
game.add_score(ENEMY_DESTROYED_SCORE)

75. Benefits
Open/Closed Principle

76. Catch 'em all!

77. Catch 'em all!
1. Only one level of indentation per method,
2. Do not use else keyword,
3. Wrap primitive types if it has behavior,
4. Only one dot per line,
5. Don’t abbreviate,
6. Keep your entities small,
7. No more than two instance variable per class,
8. First Class Collections,
9. Do not use accessors

78. Catch 'em all!
1. Only one level of indentation per method,
2. Do not use else keyword,
3. Wrap primitive types if it has behavior,
4. Only one dot per line,
5. Don’t abbreviate,
6. Keep your entities small,
7. No more than two instance variable per class,
8. First Class Collections,
9. Do not use accessors
10. ???
11. PROFIT!

79. Homework

80. Create new project up to
1000 lines long

81. Apply presented rules as
strictly as possible

82. Draw your own conculsions

83. Customize these rules

84. Final thoughts

85. These are not best practices

86. These are just guidelines

87. Use with caution!

88. Questions?

89. Links
https://en.wikipedia.org/wiki/Calisthenics
https://www.cs.helsinki.fi/u/luontola/tdd-
2009/ext/ObjectCalisthenics.pdf
https://pragprog.com/book/twa/thoughtworks-anthology
https://github.com/gennad/Design-Patterns-in-Python
https://en.wikipedia.org/wiki/Law_of_Demeter
https://www.quora.com/Is-it-true-that-a-good-
programmer-uses-fewer-if-conditions-than-an-amateur

90. Thank you!