Skip to main content
deleted 7 characters in body
Source Link
candied_orange
  • 119.7k
  • 27
  • 233
  • 369

One simple answer to the question "why does this expose implementation?" is that if you have two getters/setters that each return a double and are called X and Y, you are exposing that you've implemented the Point class using Carthesian Coordinates rather than, say, Polar Coordinates.

Also, giving people access to these X and Y values might lead them to manipulate them in calculations. For example; rather than using

Point->distanceTo(otherPoint); 

They might do something like:

distance = sqrt(  pow( PointA->getX() - PointB->getX(), 2 )    + pow( PointA->getY() - PointB->getY(), 2 ) ); 

In addition to the code duplication that will inevitably happen, this makes a second assumption. This formula only works on a flat, rectangular plane. If you're actually representing a hexagon grid for example, then this function is simply wrong.

By not exposing how you're implementing a point on a field, you can later change between ways of storing these coordinates and you prevent people from trying to be clever with details they shouldn't concern themselves with in the first place.

One simple answer to the question "why does this expose implementation?" is that if you have two getters/setters that each return a double and are called X and Y, you are exposing that you've implemented the Point class using Carthesian Coordinates rather than, say, Polar Coordinates.

Also, giving people access to these X and Y values might lead them to manipulate them in calculations. For example; rather than using

Point->distanceTo(otherPoint); 

They might do something like:

distance = sqrt( pow( PointA->getX() - PointB->getX(), 2 )    + pow( PointA->getY() - PointB->getY(), 2 ) ); 

In addition to the code duplication that will inevitably happen, this makes a second assumption. This formula only works on a flat, rectangular plane. If you're actually representing a hexagon grid for example, then this function is simply wrong.

By not exposing how you're implementing a point on a field, you can later change between ways of storing these coordinates and you prevent people from trying to be clever with details they shouldn't concern themselves with in the first place.

One simple answer to the question "why does this expose implementation?" is that if you have two getters/setters that each return a double and are called X and Y, you are exposing that you've implemented the Point class using Carthesian Coordinates rather than, say, Polar Coordinates.

Also, giving people access to these X and Y values might lead them to manipulate them in calculations. For example; rather than using

Point->distanceTo(otherPoint); 

They might do something like:

distance = sqrt(  pow( PointA->getX() - PointB->getX(), 2 ) + pow( PointA->getY() - PointB->getY(), 2 ) ); 

In addition to the code duplication that will inevitably happen, this makes a second assumption. This formula only works on a flat, rectangular plane. If you're actually representing a hexagon grid for example, then this function is simply wrong.

By not exposing how you're implementing a point on a field, you can later change between ways of storing these coordinates and you prevent people from trying to be clever with details they shouldn't concern themselves with in the first place.

We hates horizontal scroll. We hates it. Nasty evil scroll. Hisss.
Source Link
candied_orange
  • 119.7k
  • 27
  • 233
  • 369

One simple answer to the question "why does this expose implementation?" is that if you have two getters/setters that each return a double and are called X and Y, you are exposing that you've implemented the Point class using Carthesian Coordinates rather than, say, Polar Coordinates.

Also, giving people access to these X and Y values might lead them to manipulate them in calculations. For example; rather than using

Point->distanceTo(otherPoint); 

They might do something like:

distance = sqrt(  pow( PointA->getX() - PointB->getX(), 2 )  + pow( PointA->getY() - PointB->getY(), 2 ) ); 

In addition to the code duplication that will inevitably happen, this makes a second assumption. This formula only works on a flat, rectangular plane. If you're actually representing a hexagon grid for example, then this function is simply wrong.

By not exposing how you're implementing a point on a field, you can later change between ways of storing these coordinates and you prevent people from trying to be clever with details they shouldn't concern themselves with in the first place.

One simple answer to the question "why does this expose implementation?" is that if you have two getters/setters that each return a double and are called X and Y, you are exposing that you've implemented the Point class using Carthesian Coordinates rather than, say, Polar Coordinates.

Also, giving people access to these X and Y values might lead them to manipulate them in calculations. For example; rather than using

Point->distanceTo(otherPoint); 

They might do something like:

distance = sqrt( pow(PointA->getX() - PointB->getX(), 2) + pow(PointA->getY() - PointB->getY(), 2)); 

In addition to the code duplication that will inevitably happen, this makes a second assumption. This formula only works on a flat, rectangular plane. If you're actually representing a hexagon grid for example, then this function is simply wrong.

By not exposing how you're implementing a point on a field, you can later change between ways of storing these coordinates and you prevent people from trying to be clever with details they shouldn't concern themselves with in the first place.

One simple answer to the question "why does this expose implementation?" is that if you have two getters/setters that each return a double and are called X and Y, you are exposing that you've implemented the Point class using Carthesian Coordinates rather than, say, Polar Coordinates.

Also, giving people access to these X and Y values might lead them to manipulate them in calculations. For example; rather than using

Point->distanceTo(otherPoint); 

They might do something like:

distance = sqrt(  pow( PointA->getX() - PointB->getX(), 2 )  + pow( PointA->getY() - PointB->getY(), 2 ) ); 

In addition to the code duplication that will inevitably happen, this makes a second assumption. This formula only works on a flat, rectangular plane. If you're actually representing a hexagon grid for example, then this function is simply wrong.

By not exposing how you're implementing a point on a field, you can later change between ways of storing these coordinates and you prevent people from trying to be clever with details they shouldn't concern themselves with in the first place.

Source Link
Erik
  • 260
  • 2
  • 5

One simple answer to the question "why does this expose implementation?" is that if you have two getters/setters that each return a double and are called X and Y, you are exposing that you've implemented the Point class using Carthesian Coordinates rather than, say, Polar Coordinates.

Also, giving people access to these X and Y values might lead them to manipulate them in calculations. For example; rather than using

Point->distanceTo(otherPoint); 

They might do something like:

distance = sqrt( pow(PointA->getX() - PointB->getX(), 2) + pow(PointA->getY() - PointB->getY(), 2)); 

In addition to the code duplication that will inevitably happen, this makes a second assumption. This formula only works on a flat, rectangular plane. If you're actually representing a hexagon grid for example, then this function is simply wrong.

By not exposing how you're implementing a point on a field, you can later change between ways of storing these coordinates and you prevent people from trying to be clever with details they shouldn't concern themselves with in the first place.