Skip to main content
added 223 characters in body
Source Link
supercat
  • 8.7k
  • 25
  • 30

In a number of languages, classes can expose fields, but interfaces cannot. In some cases, it may be useful to a class expose information via both its class type (in which case consumers could uses fields) and via an interface (in which case consumers must use methods). For

For example, a Location3d interface might define methods getX(), getY(), and getZ(), and a. A Point3d class might define fields X, Y, Z and also implement that interface. Other objects which have locations, but don't store the X, Y, and Z directly, might implement the interface to compute coordinates which are not stored inallow other entities to inquire about their position.

Continuing the example, a Point3dMonster (e.g.class in a game, a monster might expose an EnemyLocation whosewhich holds a reference back to the monster, and implements getX() etc. methods so they will continuously report the location of the monster's current enemy). If the EnemyLocation stored coordinates indirectly, or even if it held a reference to the current enemy's Point3d, the coordinates wouldn't get updated when a monster finds a new enemy to target. If, but ifhowever, its getX() etc. methods examine the monster to which it's attached monster, and read the present location of itsthat monster's present enemy, they can always report up-to-date data.

In a number of languages, classes can expose fields, but interfaces cannot. In some cases, it may be useful to a class expose information via both its class type (in which case consumers could uses fields) and via an interface (in which case consumers must use methods). For example, a Location3d interface might define methods getX(), getY(), and getZ(), and a Point3d might define fields X, Y, Z and also implement that interface. Other objects might implement the interface to compute coordinates which are not stored in a Point3d (e.g. in a game, a monster might expose an EnemyLocation whose getX() etc. methods will continuously report the location of the monster's current enemy). If EnemyLocation stored coordinates in a Point3d, the coordinates wouldn't get updated when a monster finds a new enemy to target, but if its getX() etc. methods examine the monster to which it's attached, and read the present location of its present enemy, they can always report up-to-date data.

In a number of languages, classes can expose fields, but interfaces cannot. In some cases, it may be useful to a class expose information via both its class type (in which case consumers could uses fields) and via an interface (in which case consumers must use methods).

For example, a Location3d interface might define methods getX(), getY(), and getZ(). A Point3d class might define fields X, Y, Z and also implement that interface. Other objects which have locations, but don't store the X, Y, and Z directly, might implement the interface to allow other entities to inquire about their position.

Continuing the example, a Monster class in a game might expose an EnemyLocation which holds a reference back to the monster, and implements getX() etc. methods so they will continuously report the location of the monster's current enemy. If the EnemyLocation stored coordinates directly, or even if it held a reference to the current enemy's Point3d, the coordinates wouldn't get updated when a monster finds a new enemy to target. If, however, its getX() etc. methods examine the attached monster, and read the present location of that monster's present enemy, they can always report up-to-date data.

Source Link
supercat
  • 8.7k
  • 25
  • 30

In a number of languages, classes can expose fields, but interfaces cannot. In some cases, it may be useful to a class expose information via both its class type (in which case consumers could uses fields) and via an interface (in which case consumers must use methods). For example, a Location3d interface might define methods getX(), getY(), and getZ(), and a Point3d might define fields X, Y, Z and also implement that interface. Other objects might implement the interface to compute coordinates which are not stored in a Point3d (e.g. in a game, a monster might expose an EnemyLocation whose getX() etc. methods will continuously report the location of the monster's current enemy). If EnemyLocation stored coordinates in a Point3d, the coordinates wouldn't get updated when a monster finds a new enemy to target, but if its getX() etc. methods examine the monster to which it's attached, and read the present location of its present enemy, they can always report up-to-date data.