Voyez-vous des motifs (anti) dans mon design? Comment reconnaître le motif?

Question

J'ai une application Web codée en ABAP/BSP. Je suis intéressé à fournir du code précis, alors peut-être que vous pouvez m'aider à reconnaître un bon ou un mauvais modèle. En fait, je fais suivre. Déclarez un objet de classe de base et instanciez-le dynamiquement en fonction d'un paramètre avec une sous-classe. La classe de base a quelques méthodes pour récupérer les données() les sous-classes utilisent ces données et peuvent éventuellement les manipuler.

Voici quelques photos de base rapide (désolé ne pense pas que son conforme à une norme ou de la langue, mais devrait vous donner une idée)

alt text http://img35.imageshack.us/img35/4351/designkdp.jpg

Est-ce somthing comme OK? Y at-il un motif connu caché ou devrais-je refactoriser et utiliser un motif? J'aime ici quelques suggestions. J'ai déjà lu l'article de Wikipédia mais je ne vois pas de motif exactement. (Également commandé quelques livres, mais vous les gars êtes sûr plus rapide :))

Answer 1

Il semble factory method

Answer 2

C'est le modèle d'usine du livre « Design Patterns: Elements de logiciel orienté objet réutilisable » par Gamma, Helm , Johnson et Vlissides.

Answer 3

Le BaseClass et me semblent Sous-classes comme avoir quelque chose comme (pseudocode)

interface IDataProvider{ 
    GetData(); 
} 

class SubClass1 implements IDataProvider{ 
    GetData(){ 
    ... 
    } 
} 

Les stratégies d'instanciation que vous utilisez semblent fonctionner comme un Factory. Ce que vous pouvez faire est de mettre en page le rendu dans un HTMLRenderingEngine ou autre (je ne suis pas familier avec ABAP/BSP), juste pour que la présentation soit découplée du reste de la logique.

Answer 4

L'héritage est amusant, mais devrait être utilisé en dernier recours. Je ne dis pas que vous ne pouvez pas le faire comme vous l'avez fait - votre solution est totalement valide, mais juste pour suggérer une alternative ...

Et si vous aviez "DataClass" dans lequel vous pouviez définir un processData objet (ou non). L'objet processData serait en fait une interface avec une seule méthode "processData".

Lorsque vous appelez getData, il pourrait ressembler à ceci:

if(processDataObject == null) 
    return getInformation(); 
else 
    return processDataObject.processData(getInformation()); 

Heck, si vous avez un « passthrough » objet processData défini qui ne fait rien et l'utiliser comme la valeur par défaut « processDataObject », le toute méthode getData devient:

return processDataObject.processData(getInformation()); 

cela permettrait la création dynamique de classes pour faire tout type de traitement que vous voulez - Il va simplifier les choses que vous créez sur le dessus de cette conception.

Ce style de conception m'a pris du temps à accepter, et vous n'aimez peut-être pas l'idée d'éviter l'héritage au début, je vous demande simplement d'y réfléchir. Mon utilisation de l'héritage est assez rare ces temps-ci, et quand je l'utilise, c'est toujours dans des arbres très peu profonds.