The Cartesian coordinate system is not the only way of describing a grid. Another way is the polar coordinate system:
The polar coordinate system is a two-dimensional coordinate system in which we determine each point on the plane by two numbers — the polar angle and the polar radius. The polar coordinate system helps in cases where the relations between points are easier to represent in the form of radii and angles. We can establish such relations only by applying trigonometric equations in more common Cartesian, rectangular, or coordinate systems. (c) Wikipedia
Imagine this situation. We developed a graphic editor like Photoshop and used a library for working with graphic primitives based on the Cartesian coordinate system. At some point, you realize that switching to the polar system will help make everything easier and faster. What price will you have to pay for this change? We have to rewrite almost all the code:
point = {"x": 2, "y": 3}
symmetrical_point = {
"x": -point["x"],
"y": point["y"],
}
It is because your library does not hide the internal structure. Any code that uses points or segments knows how they work inside. It applies to pieces of code that create new primitives and extract the parts from them. It is simple to change the situation and hide the implementation using functions:
point = make_point(3, 4)
symmetrical_point = make_point(-get_x(point), get_y(point))
In the example, we can see three functions:
- The
make_point()
constructor that creates a new primitive - The
get_x()
selector - The
get_y()
selector
Even a small change like this will lead to far-reaching consequences. The main thing is that the application code that uses the library does not work with structure directly:
## We do it differently
point = [1, 4] # We know this is the list
print(point[1]) # It is a direct access to list
# In the following way
point = make_point(3, 4) # We don't know how a point works
print(get_y(point)) # We only access parts via selectors
Looking at the code, you cannot even tell what the point is from the inside or what language constructs it is represented by — you can use debugging printing for this. So, we built a data abstraction. The essence of this abstraction is that we hide the internal implementation. Creating an abstraction using data leads to hiding this data from external code.
And there is one way to implement an abstraction when working with a point:
def make_point(x, y):
return {"x": x, "y": y}
def get_x(point):
return point["x"]
def get_y(point):
return point["y"]
We can change the implementation without having to rewrite the entire code. However, rewriting individual parts may still be necessary. We use the make_point()
function, which creates a point based on the Cartesian coordinate system and takes the coordinates x
and y
as input.
Also, we can represent it in a polar coordinate system inside. In other words, during construction, we go from one format to another:
import math
def make_point(x, y):
# Here we see conversion
return {
"angle": math.atan2(y, x),
"radius": math.sqrt(x ** 2 + y ** 2)
}
Once you start working through data abstraction, there is no going back. Always stick to the functions you have created or those provided to you by the library used.
Are there any more questions? Ask them in the Discussion section.
The Hexlet support team or other students will answer you.
For full access to the course you need a professional subscription.
A professional subscription will give you full access to all Hexlet courses, projects and lifetime access to the theory of lessons learned. You can cancel your subscription at any time.