Design pattern for methods in another class

Question

I am looking for a specific desgin pattern.

For example i have an article class, clsArticle. This class contains member variables like Id, title, author, article, and so on. Imagine i want to show all the articles in a list. So somewhere i have to create a method getAllArticles(). Since clsArticle is not responsible for getting all the articles, i have to put this method in another class, clsArticleFact (Where Fact stands for Factory).

Does someone know how this pattern is called? Is this way of working a design pattern?

Answer 1

Yeap. That's correct.

It may be either an AbstractFactory or a DataAccessObject.

The first is when you want to let the implementation return different kinds of articles

For instance let's say you have a condition where the articles behave different according with the platform.

ArticleFactory.getAll(): Article[]

Would return the correct list in each platform.

The impl may be:

WindowsArticleFactory

or

OSXArticleFactory

The former may be used to abstract the place where the articles are retrieved from:

You may have

ArticleDao.getAll(): Article[]

and the implementations:

XmlArticleDao // Return a list of articles from an XML

or

DatabaseArticleDao // return the list from the database.

The point here is to decouple the creation ( getAll() ) from the usage ( Article )

If you application is simple enough you can use a factoryMethod instead.

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

I hope this helps.

Answer 2

Well, create a static class for that purpose:

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

Answer 3

You can also use the approach taken by Rails ActiveRecord model classes

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

What you describe is not really a pattern, but instead a programming principle called 'Separation of Concerns'.

From your description I would strongly argue that you after a structural design pattern, not a creational design pattern since allocation of coding concerns is discussed over creational complicity.

So, my best guess is that the pattern you are after is perhaps the Facade Pattern or Gateways. It is common to use Entities (your clsClass) with Gateways.

I would however not necessarily encourage jumping into making your methods static however since then these cannot be mocked during testing of Business Logic. You would want to mock these types of methods that return data access objects if they form the application's data layer since you don't want to hit the data base when 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;
    }
}

Answer 5

Don't create static methods!

Your first thought should be interface.

Maybe you could write something like (example in Java)

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

All other things you need to do with articles also go into this interface. Inject a concrete implementation of this class (DbArticleService, XmlArticleService, ...) into every object that needs to deal with Articles.

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

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