5,810
edits
Es/FlightGear Newsletter September 2010: Difference between revisions
Jump to navigation
Jump to search
Es/FlightGear Newsletter September 2010 (view source)
Revision as of 02:28, 3 January 2011
, 3 January 2011→Nasal for newbies: OOP
| Line 248: | Line 248: | ||
This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods. | This allows you for example to simply rename a class variable, without having to change any of the code that uses the object, because other code only uses class methods. | ||
Esto proporciona una forma para administrar el acceso a una variable miembro (campo), como una interfaz abstracta también es útil para mantener la lógica privada, y la interna. Por ejemplo, el nombre de una variable "altura" puede ser fácilmente modificado internamente para "altitude_ft", sin tener que cambiar el nombre de todos los usuarios de la clase - simplemente porque todos los otros códigos se refieren a los métodos de acceso al campo. | |||
Por ejemplo, en lugar de hacer algo así cloud.lat = 10,22; cloud.lon = 43,22; tendría que aceptar un método lat / lon variables: cloud.setPos (lat, lon); | |||
Eso significa que las variables reales que contiene los valores de latitud y longitud no están expuestos o utilizados fuera del objeto real. Esto se conoce como encapsulación y le proporciona una manera de administrar el estado y asegurar que el estado interno es válida en todo momento, ya que otros códigos sólo pueden utilizar la interfaz externa. | |||
Esto le permite, por ejemplo para cambiar el nombre simplemente una variable de clase, sin tener que cambiar nada del código que utiliza el objeto, por otro código sólo utiliza métodos de la clase. | |||
Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities. | Another important thing in OOP is separation of concerns, i.e. you don't want to end up with huge bloated "super classes" that manage all sorts of different state, but instead use different classes where appropriate to split code into abstract "modules" with well defined responsibilities. | ||