Es/FlightGear Newsletter September 2010: Difference between revisions

Jump to navigation Jump to search

Es/FlightGear Newsletter September 2010 (view source)

Revision as of 17:41, 11 January 2011

287 bytes removed ,  11 January 2011
→‎Nasal para novatos OOP
Line 233: Line 233:
Esto proporciona una forma de 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 "altitud" puede ser fácilmente modificado internamente a "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.
Esto proporciona una forma de 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 "altitud" puede ser fácilmente modificado internamente a "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.


For example, instead of doing something like cloud.lat=10.22; cloud.lon=43.22; you would have a method accepting lat/lon variables: cloud.setPos(lat, lon);
Por ejemplo, en lugar de hacer algo así cloud.lat = 10,22; cloud.lon = 43,22; tendrías que aceptar un método lat / lon variables: cloud.setPos (lat, lon);


That means that the actual variables containing the values for lat/lon are not exposed or used outside the actual object. This is called encapsulation and provides you with a way to manage state and ensure that internal state is valid at all times, because other code may only use the external interface.
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 encapsulamiento y te proporciona una manera de administrar el estado y asegurar que el estado interno es válido en todo momento, ya que otros códigos sólo pueden utilizar la interfaz externa.


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 te permite, por ejemplo cambiar el nombre simplemente a 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.


 
Otra cosa importante en la programación orientada a objetos es la separación de las preocupaciones, es decir, sino quieres terminar con "superclases" hinchadas que manejan todo tipo de estados diferentes, pero en lugar de utilizar diferentes clases en su caso, para dividir el código en  "módulos" abstractos con responsabilidades bien definidas.
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.


So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).
So, one of the very first steps to convert procedural code to OOP code would be to group your code into a number of logical "classes" (e.g. cloud, cloud field ).
Aepcam
5,810

edits

Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/27488"

Navigation menu