7. Dragon ADR Position Set¶
ADR - Architecture Design Records
7.1. Problem¶
Set new position to x=10, y=20
7.2. Option 1¶
>>> dragon.fly(10, 20)
>>> dragon.teleport(10, 20)
>>> dragon.set_position(10, 20)
>>> dragon.set_position_xy(10, 20)
Good: easy to use
Good: encapsulation
Good: easy to add validation if needed
Good: easy to extend to 3D - add parameter with default value
0
Bad: name
set_position_xy()
ties you to 2D pointBad: arguments are implicit, require knowledge of an API
Bad:
teleport()
andfly()
are bad names, does not indicate context what are the values provided as arguments
7.3. Option 2¶
>>> dragon.fly(x=10, y=20)
>>> dragon.teleport(x=10, y=20)
>>> dragon.set_position(x=10, y=20)
Good: easy to use
Good: arguments are explicit
Good: encapsulation
Good: easy to add validation if needed
Good: easy to extend to 3D - add parameter with default value
0
Bad:
teleport()
andfly()
are bad names, to use-case specific
7.4. Option 3¶
>>> dragon.set(position_x=10, position_y=20)
Good: easy to use
Good: arguments are explicit
Good: encapsulation
Good: easy to add validation if needed
Bad:
set()
is to genericBad: gateway to abuse
7.5. Option 4¶
>>> dragon.x = 10
>>> dragon.y = 20
>>> dragon.x, dragon.y = 10, 20
Good: easy to use
Good: arguments are explicit
Good: can use
@property
for validation if neededBad: encapsulation
Bad: names
x
andy
are weakly related todragon
Example:
>>> knn = KNearestNeighbors(k=3)
>>> knn.w = [1, 2, 3]
7.6. Option 5¶
>>> dragon.position_x = 10
>>> dragon.position_y = 20
>>> dragon.position_x, dragon.position_y = 10, 20
Good: easy to use
Good: arguments are explicit
Good: can use
@property
for validation if neededBad: encapsulation
Example:
>>> knn = KNearestNeighbors(k=3)
>>> knn.weights = [1, 2, 3]
7.7. Option 6¶
>>> dragon.position = (10, 20)
>>> dragon.position @ (10, 20)
Good: easy to use
Good: can use
@property
for validation if neededGood: using
@
(matmul) it is easy to validationBad:
@
(at) makes sense only in EnglishBad: arguments are implicit
Bad: require knowledge of an API
Bad: always 2D
Bad: not extensible, hard to refactor to 3D
7.8. Option 7¶
>>> dragon.position = Point(x=10, y=20)
>>> dragon.position @ Point(x=10, y=20)
Good: easy to use
Good: can use
@property
for validation if neededGood: arguments are explicit
Good: readability
Bad:
@
(at) makes sense only in EnglishBad: require knowledge of an API
Bad: extensible, easy to refactor to 3D
7.9. Option 8¶
>>> dragon.position.x = 10
>>> dragon.position.y = 20
>>> dragon.position.x, dragon.position.y = 10, 20
Good: more or less easy to use
Good: arguments are explicit
Good: can use
@property
for validation if neededGood: namespace
Good: more or less readable
Good: extensible, easy to refactor to 3D
Bad: encapsulation
Bad: nested
Bad: require knowledge of an API
7.10. Decision¶
>>> dragon.set_position(x=10, y=20)
Good: easy to use
Good: arguments are explicit
Good: encapsulation
Good: easy to add validation if needed
Good: extensible, easy to refactor to 3D