Modèle de conception pour les méthodes d'une autre classe

Question

Je cherche un modèle de dessin spécifique.

Par exemple, j'ai une classe d'article, clsArticle. Cette classe contient des variables membres telles que Id, title, author, article, etc. Imaginez que je veux montrer tous les articles dans une liste. Donc quelque part je dois créer une méthode getAllArticles(). Puisque clsArticle n'est pas responsable de l'obtention de tous les articles, je dois mettre cette méthode dans une autre classe, clsArticleFact (où Fact signifie Factory).

Est-ce que quelqu'un sait comment ce modèle est appelé? Est-ce que cette façon de travailler est un motif de conception?

Answer 1

Yeap. C'est correct.

Il peut s'agir d'une AbstractFactory ou d'un DataAccessObject.

Le premier est quand vous voulez laisser la mise en œuvre retourner différents types d'articles

Par exemple, disons que vous avez une condition où les articles se comportent différents selon la plate-forme.

ArticleFactory.getAll(): Article[] 

Renvoie la liste correcte dans chaque plateforme.

Le impl peut être:

WindowsArticleFactory 

ou

OSXArticleFactory 

L'ancien peut être utilisé pour abstraire l'endroit où les articles sont récupérés à partir de:

Vous pouvez avoir

ArticleDao.getAll(): Article[] 

et les mises en œuvre:

XmlArticleDao // Return a list of articles from an XML 

ou

DatabaseArticleDao // return the list from the database. 

Le point ici est de découpler la création (getAll()) de l'utilisation (article)

Si votre application est assez simple, vous peut utiliser un factoryMethod à la place.

class Article { 
    static Article[] getAll() { 
     // do whatever is neede here... 
    } 
} 

J'espère que cela aide.

Answer 2

Eh bien, créez une classe statique à cette fin:

public static class clsArticles 
{ 
    public static clsArticles[] GetAllArticles() { /* actual code */ } 
} 

Answer 3

Vous pouvez également utiliser l'approche adoptée par Rails classes de modèle ActiveRecord

public class clsArticle 
{ 
    public static clsArticle[] findAll() { /*... */ } 

    // the other regular code here; 
} 

// client code 
foreach(clsArticle obArticle in clsArticle.findAll()) 
{ 
    list.add(clsArticle) 
} 

Answer 4

Ce que vous décrivez est pas vraiment un modèle, mais à la place, un principe de programmation appelé «Séparation des préoccupations».De votre description, je dirais fortement que vous après un modèle de conception structurelle, pas un modèle de conception de création puisque l'attribution des préoccupations de codage est discutée sur la complicité créationnelle.

Alors, ma meilleure estimation est que le modèle que vous êtes après est peut-être le motif de façade ou passerelles. Il est courant d'utiliser Entities (votre clsClass) avec Gateways. Je n'encouragerais cependant pas forcément à rendre vos méthodes statiques, mais elles ne peuvent pas être moquées pendant les tests de Business Logic. Vous voudriez vous moquer de ces types de méthodes qui renvoient des objets d'accès aux données s'ils forment la couche de données de l'application puisque vous ne voulez pas toucher la base de données lorsque la logique métier dépend de ces passerelles/façades.

public class clsClass 
{ 
    public int ID; 
    public string title; 
    public string author; 
    public string article; 
} 


public class BookGateway 
{ 
    public List<clsClass> GetAllArticles() 
    { 
     var result = new List<clsClass>(); 

     // Add items here. 
     // Can call database and populate each new clsClass 
     // and add to result object. 

     return result; 
    } 
} 

Answer 5

Ne créez pas de méthodes statiques!

Votre première pensée devrait être interface.

Peut-être que vous pourriez écrire quelque chose comme (par exemple en Java)

public interface ArticleService { 
    Article[] getAllArticles() throws ServiceException(); 
} 

Toutes les autres choses que vous devez faire avec les articles vont également dans cette interface. Injectez une implémentation concrète de cette classe (DbArticleService, XmlArticleService, ...) dans chaque objet devant traiter les articles. De cette façon, comme d'autres affiches mentionnées, vous obtenez un code découplé et une bonne séparation des préoccupations.

Mais quoi que vous fassiez, ne pas rendre les choses statiques.