It's great that you are driven. You'll get there eventually.
I have some comments on the design of the
Point class. It's not about what you CAN do, it's about what
you SHOULD do.
Your
Point class contains setters for the
x and
y fields. While setters are unavoidable in some cases, for many types they are actually harmful.
When you think about the points
(2, 3) and
(4, -1) in 2D coordinate space, you think of them as two fixed objects, right? "Setting" the
x coordinate of
(2, 3) to
1 doesn't really make sense. Instead, you just think about a
new point with coordinates
(1, 3).
The reason it's harmful is because you might pass an instance of type
Point to another object that assumes that the point will never change. Then when you do change the coordinates of the point, the object that depends on the
Point will have been corrupted.
Secondly, use names that are as descriptive as possible. A
distance() method without parameters didn't make sense to me until I looked at the implementation. Methods should be clear in their purpose without having to look at their implementation.
Override the
toString() method if you can to give your objects a good textual representation for debugging. Override the
hashCode() and
equals() methods if your class represents a value type: Objects of a value type represent a fixed value that can be compared to another object of the same type, such as the number
7.3, the character
'K' or the point
(4, 2). Your
Point class is an ideal candidate if you drop the setters.
Make your classes and members as private as possible. Lose the habit of writing
public everywhere. Only raise the visibility of a class or method if you really need it outside of the package or class you declared it in.
Make your classes
final. This prevents them from being subclassed. Subclassing is a powerful tool, but it comes with a lot of unforeseen challenges that are hard to deal with if you haven't carefully designed your class. The easiest thing is to just prevent it.
Here's an updated version of your class.