Es/FlightGear Newsletter September 2010: Difference between revisions

Jump to navigation Jump to search

Es/FlightGear Newsletter September 2010 (view source)

Revision as of 18:03, 11 January 2011

636 bytes removed ,  11 January 2011
→‎Nasal para novatos OOP
Line 237: Line 237:
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.
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.


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.
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 que sólo utiliza métodos de la clase.


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, lo apropiado es dividir el código en  "módulos" abstractos con responsabilidades bien definidas.


 
Así, uno de los primeros pasos para convertir el código de procedimiento para programación orientada a objetos sería agrupar tu código en una serie de lógica de "clases" (nube por ejemplo, campo de nube).
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.
 
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 ).


Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes. This is then called "composition".
Classes may be composed of other classes, i.e. a "cloud field" class would in turn contain "cloud" classes. This is then called "composition".
 
Las clases pueden estar compuestas de otras clases, es decir, un "campo de nube" de clase, a su vez contienen "nube "de clases. Esto se denomina "composición".
Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".
Another way is inheritance, where a type may inherit properties (fields:variables and methods) from a "parent" class. Imagine it like taking a "template" for the class and then saying "make a new class using this template".






Otra cosa importante en la programación orientada a objetos es la separación de las preocupaciones, es decir, que no quiere terminar con gran hinchada "superclases" que manejan todo tipo de estado diferente, pero en lugar de utilizar diferentes clases en su caso, para dividir el código en abstracto "módulos" con responsabilidades bien definidas.
Así, uno de los primeros pasos para convertir el código de procedimiento para programación orientada a objetos sería el grupo de su código en una serie de lógica "clases" (nube por ejemplo, terreno de nube).


Las clases pueden estar compuestas de otras clases, es decir, un "campo de nube" de clase, a su vez contienen "nube "de clases. Esto se denomina "composición".
Las clases pueden estar compuestas de otras clases, es decir, un "campo de nube" de clase, a su vez contienen "nube "de clases. Esto se denomina "composición".
Aepcam
5,810

edits

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

Navigation menu