Clever Geek Handbook

Design Pattern for Methods in Another Class

I am looking for a specific desgin template.

For example, I have an article class, clsArticle. This class contains member variables like Id, Title, Author, Article, etc. Imagine I want to show all the articles in a list. So somewhere I have to create a getAllArticles () method. Since clsArticle is not responsible for fetching all articles, I have to put this method in another class, clsArticleFact (Where fact stands for Factory).

Does anyone know what this template is called? Is this the way to work with a design pattern?

+1


source to share


5 answers


Yeap. It is right.

It can be either AbstractFactory or DataAccessObject.

First, if you want the implementation to return different articles

For example, let's say you have a condition where articles behave differently according to the platform.

ArticleFactory.getAll(): Article[]

Would return the correct list on every platform.

Imp can be:

WindowsArticleFactory

or

OSXArticleFactory

The first can be used to abstract away where articles are retrieved from:



Perhaps you have

ArticleDao.getAll(): Article[]

and implementation:

XmlArticleDao // Return a list of articles from an XML

or

DatabaseArticleDao // return the list from the database.

This is where we need to separate creation (getAll ()) from usage (articles)

If the application is simple enough, you can use factoryMethod instead.

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

Hope this helps.

+3


source


You can also use the approach used by the Rails ActiveRecord class classes



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

  // the other regular code here;
}

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


source


Well, create a static class for this purpose:

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


source


What you are describing is not really a pattern, but instead is a programming principle of Separation of Concerns .

From your description, I would strongly argue that you are following a structured design pattern and not a design pattern to create, since the distribution of coding issues is discussed on the co-creation issue.

So, I think the template you are after is perhaps the Facade Template or Gateways . Commonly used Entities (your clsClass) with gateways.

I would not, however, necessarily encourage you to move on to keeping your methods static, but since then they cannot be mocked while testing Business Logic. You would like to mock these types of methods that return data access objects if they form the application data layer, since you don't want to get into the database when the business logic depends on these gateways / facades.

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


source


Don't create static methods!

Your first thought should be the interface .

Maybe you could write something like (example in Java)

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

All other things you need for articles are also included in this interface. Implement a concrete implementation of this class (DbArticleService, XmlArticleService, ...) in every object that needs to deal with articles.

This way, as other posters mentioned, you get decoupled code and nice separation of concerns.

But whatever you do, don't make things static.

0


source






More articles:


All Articles