Remplacement pour struct style C en POO

Question

Je suis un étudiant avec un fond essentiellement électronique entrer dans la programmation. Plus je en, plus je me rends compte à quel point je suis à elle. Je suis en train de faire mieux à la conception OO. Une chose que je suis en train de lire à propos de l'utilisation des accesseurs.

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

Maintenant, je peux voir le point qu'ils font ici, mais je suis toujours incapable de voir loin autour de quelques problèmes simples. Et cela me amène à ma question (enfin). Je vais mettre en place un simple jeu de tower defense en AS3 comme un exercice d'apprentissage. Je veux des ennemis à suivre les points de passage pour que j'allais faire un tableau de points de passage, et en faire une propriété d'un objet de la carte. Et un point de passage devait être un objet avec un x et une propriété y (plus comme un struct). Maintenant, je peux voir que c'est exactement le genre de mauvaise pratique que les articles sont décourageants, mais je ne peux pas sembler penser à une meilleure façon de le faire. Toute aide de certains d'entre vous avec un peu plus d'expérience serait très appréciée.

Answer 1

Tout d'abord généraliser; alors que vous êtes désireux actuellement ennemis suivre waypoints il me semble que ce que vous avez est une instance spécifique de la carte déterminer où quelque chose bouge.

Appelons ennemis un exemple de "GameEntity" (peut-être MoveableGameEntity).

Ce que vous devez faire est de dire la carte pour gérer les GameEntities pertinentes, puis la carte peut garder une liste de ces objets et les déplacer au besoin.

fragments de code.

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 );
}

La carte devra avoir une get_new_position méthode (MoveableGameEntity ge) qui déterminera la nouvelle posisiton et les ennemis ne seront dit leur nouvelle posistion via la méthode positionNotify.

Le MoveableGameEntityList est un objet qui reliera ensemble une entité de jeu et sa position. De cette façon, l'entité de jeu ne contient pas d'informations de position et cela est géré par un autre objet.

Answer 2

D'accord, les hypothèses lourdes suivent: Je pense que vous pensez beaucoup trop sur l'efficacité. codage OO n'est pas sur l'efficacité. Il est sur le design élégant. Il est de minimiser les effets secondaires des facteurs externes et la protection de l'état interne. Voilà pourquoi les compilateurs « optimize. » Vous devriez penser à la maintenabilité et la difficulté de codage principalement. Le montant des lignes que vous écrivez pourrait bien être supérieur à un code non-OO. Ce n'est pas le point.

Essayez de penser à vos « objets » comme des éléments tangibles qui communiquent entre-autres. Cette communication est un protocole (comprend les signatures de méthode). La langue que vous « parler » les uns aux autres. Faire simple et sans ambiguïté. Ne jamais supposer que tout objet a le pouvoir de manipuler un autre au-delà de sa capacité à communiquer une suggestion ou demande (encapsulation).

Ne pas simplement ajouter des accesseurs à tout sans but. Vous allez manquer le point entier et peut aussi bien être codage dans un autre style. État de protection interne. Getters et setters sur tout signifie simplement que vous aurez une mise en œuvre universellement inefficace. Setters et getters sont les gardiens. Rien de plus. Éliminez-les si elles ne font pas de sens. Utilisez-les là où ils le font. Ne laissez jamais autre chose à vis avec votre état interne. Cela va créer le chaos.

Lors de l'écriture des jeux, ces pratiques tombent vers le bas, mais ils ne sont pas à abandonner. Optimisez vos boucles critiques et points d'étranglement. Gardez votre code original pour référence et un modèle image miroir de votre code optimisé. Prenez les raccourcis dont vous avez besoin et rien de plus. L'optimisation doit toujours venir en dernier ... même en face d'une conception de toute évidence inefficace, mais réfléchie.

De nombreux ex-codeurs Java j'ai travaillé avec les organismes de vente et getters sur les attributs inutilement (tous les attributs). C'est tout simplement ce qu'ils sont habitués. Aucun avantage dans 9 des 10 cas, mais ils ont insisté sur ce modèle. L'impact a toujours été négligeable (50k utilisateurs par minute ... bien sûr, pas en utilisant Java ... mais quand même). L'impact total des getters et setters est minime dans une conception de haut niveau. Au niveau inférieur, comme dans Codecs vidéo ou OpenGL, il est énorme .

Vous pouvez choisir de les adopter sans y penser, ou les mettre en œuvre avec application à l'esprit. Vous vous trouverez de nombreux professeurs vous dire que êtes « mauvais » parce que vous les omettez. Gardez vos attentes coursework à l'esprit. :)

Answer 3

Je préfère ne pas voir ce que les habitudes mauvaises contre de bonnes habitudes, mais plutôt un changement de paradigme. Malheureusement, ce n'est pas aussi simple que basculer un interrupteur. Il est quelque chose qui arrive progressivement à mesure que vous obtenez de plus en plus d'expérience avec une autre façon de voir les choses.

Le meilleur conseil que je peux vous donner est juste de commencer à coder. Beaucoup.

Answer 4

Un peu sans rapport, mais si vous voulez entrer dans la conception OO J'ai 2 c. De bons livres pour vous, facile à comprendre et saisir.

Head First: OOAD

Head First: Design Patterns