Reemplazo para el estilo de C struct en la programación orientada a objetos

Question

Soy un estudiante con una principalmente de la electrónica de fondo de entrar en la programación.Cuanto más me meto en ello, más me doy cuenta de lo mal que me siento en él.Estoy tratando de conseguir mejor en diseño OO.Una cosa que he estado leyendo es el uso de los Captadores y Definidores.

http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html?page=1 http://typicalprogrammer.com/?p=23

Ahora puedo ver el punto de que se están haciendo aquí, pero aún no puedo ver lejos en torno a algunos problemas sencillos.Y esto me lleva a mi pregunta (por fin).Estoy configurando un simple juego de defensa de torre en AS3 como un ejercicio de aprendizaje.Quiero enemigos para seguir camino a puntos, por lo que me iba a hacer una matriz de puntos, y hacer que una propiedad de un objeto de mapa.Y un punto de referencia era el de ser un objeto con un x y un y de la propiedad (más como un struct).Ahora puedo ver que esto es exactamente el tipo de malas prácticas que los artículos son desalentadores, pero me parece que no puede pensar en una mejor manera de hacer esto.Cualquier ayuda de algunos de ustedes con un poco más de experiencia sería muy apreciada.

Answer 1

En primer lugar generalizar; mientras que usted está deseando Actualmente enemigos para seguir los waypoints me parece que lo que tienes es una instancia específica del mapa determinar donde algo se mueve.

Los enemigos de Deme una instancia de "GameEntity" (posiblemente MoveableGameEntity).

Lo que usted debe hacer es contar el mapa para gestionar los GameEntities pertinentes, y luego el mapa puede mantener una lista de estos objetos y moverlos según sea necesario.

fragmentos de código.

interface  MoveableGameEntity
{
    void positionNotify(Position new_postition);
};

public class Barbarian implements MoveableGameEntity
{
    void positionNotify(Position new_postition)
    {
         // do something
    }
};

// during initialisation.
map.Add(new Enemy("Barbarian 1"));
map.Add(new Enemy("Barbarian 2"));

//during map processing
Position new_position = new Position();
for (MoveableGameEntityList moveable : moveable_game_entity_items)
{
   new_position = get_new_posistion(moveable);
   item.moveTo(new_position);
   moveable.positionNotify( new_position );
}

El mapa tendrá que tener un método get_new_position (MoveableGameEntity ge) que determinará el nuevo posisiton y los enemigos sólo se dijo a su nuevo posistion a través del método positionNotify.

El MoveableGameEntityList es un objeto que va a unir una entidad de juego y de posición. De esta manera la entidad juego no contiene ninguna información de posición y esto es manejado por otro objeto.

Answer 2

Bueno, pesado supuestos siguientes:Creo que estás pensando demasiado acerca de la eficiencia.OO la codificación no es acerca de la eficiencia.Se trata de un diseño elegante.Se trata de reducir al mínimo los efectos secundarios de los factores externos y la protección interna del estado.Esta es la razón por la compiladores de "optimizar." Usted debe estar pensando en la facilidad de mantenimiento y la dificultad de codificación principalmente.La cantidad de líneas que escribir bien podría ser mayor que la de los no-OO código.Ese no es el punto.

Trate de pensar acerca de sus "objetos" como elementos tangibles que se comunican el uno con el otro.Esta comunicación es un protocolo (incluye las firmas de método).El lenguaje de "hablar" el uno al otro.Es más simple y sin ambigüedades.Nunca asuma que cualquier objeto tiene el poder para manipular a otro más allá de su capacidad para comunicar una sugerencia o petición (encapsulación).

No sólo agregar getters y setters de todo, sin propósito.Vas a perder la totalidad del punto y bien podría ser la codificación en otro estilo.Proteger estado interno.Los captadores & incubadoras en todo simplemente significa que usted tendrá un universalmente ineficiente aplicación.Incubadoras & captadores son los guardianes.Nada más.Eliminarlos, si no hacen sentido.El uso de ellos cuando lo hacen.Nunca permita que otra cosa a tornillo con su estado interno.Se va a crear el caos.

Cuando la escritura de los juegos, estas prácticas se caen, pero no deben ser abandonados.Optimizar su crítica loops & puntos de estrangulamiento.Mantener su código de referencia y como una imagen de espejo modelo de su código optimizado.Tomar los atajos de teclado que usted necesita y nada más.La optimización debe ser el último...incluso en la cara de una, obviamente, ineficiente, pero reflexivo, de diseño.

Muchos ex-programadores Java he trabajado con poner incubadoras & captadores en los atributos innecesariamente (cada atributo).Esto es simplemente lo que estamos acostumbrados.Ningún beneficio en 9 de los 10 casos, pero ellos insistían en este patrón.El impacto fue siempre insignificante (50k usuarios por minuto...por supuesto, el no uso de Java...pero aún así).El impacto total de los captadores & incubadoras es mínima en un diseño de alto nivel.Nivel inferior, como en los CODECs de video o OpenGL, es enorme.

Usted puede elegir para adoptarlas sin pensar, o aplicarlas con aplicabilidad en la mente.Usted se encontrar muchos profesores nos dice que estamos "mal" porque se omite ellos.Mantenga su curso expectativas en mente.:)

Answer 3

Yo prefiero no ver esto como malos hábitos vs buenos hábitos, sino más bien un cambio de paradigma. Por desgracia, no es tan simple como apretar un interruptor. Es algo que ocurre de manera gradual a medida que más y más experiencia con una forma diferente de ver las cosas.

El mejor consejo que puedo dar es que acaba de empezar a programar. Una gran cantidad.

Answer 4

Un poco sin relación, pero si usted desea conseguir en el diseño OO tengo 2 v. Buenos libros para usted, fácil de entender y alcance.

La cabeza primero: OOAD

La cabeza primero: Patrones de diseño