Шаблон проектирования для методов в другом классе

Я ищу определенный шаблон дизайна.

Например, у меня есть класс статьи, clsArticle. Этот класс содержит переменные-члены, такие как Id, title, author, article и т. Д. Представьте, что я хочу показать все статьи в списке. Поэтому где-то мне нужно создать метод getAllArticles (). Так как clsArticle не отвечает за получение всех статей, я должен поместить этот метод в другой класс, clsArticleFact (где Fact обозначает Factory).

Кто-нибудь знает, как называется этот шаблон? Это способ работы шаблона дизайна?

11.12.2008 09:38:50
5 ОТВЕТОВ
РЕШЕНИЕ

Yeap. Это правильно.

Это может быть либо AbstractFactory, либо DataAccessObject.

Первый - когда вы хотите, чтобы реализация возвращала разные виды статей.

Например, предположим, у вас есть условие, когда статьи ведут себя по-разному в зависимости от платформы.

ArticleFactory.getAll(): Article[]

Вернул бы правильный список в каждой платформе.

Импл может быть:

WindowsArticleFactory

или

OSXArticleFactory

Первый может быть использован для абстрагирования места, из которого статьи извлекаются:

Ты можешь иметь

ArticleDao.getAll(): Article[]

и реализации:

XmlArticleDao // Return a list of articles from an XML

или

DatabaseArticleDao // return the list from the database.

Смысл здесь в том, чтобы отделить создание (getAll ()) от использования (Статья)

Если ваше приложение достаточно простое, вы можете использовать factoryMethod.

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

Надеюсь, это поможет.

3
11.12.2008 16:42:11
Спасибо за ответ. Я действительно не понимаю. Я программирую на C #. И у меня есть один тип статьи.
Martijn 11.12.2008 09:55:34
@Martijn: OT: Если вы программируете на C #, вам действительно не следует использовать префиксы для чего-либо (например, clsArticle), и вы не должны сокращать что-либо (например, * Fact). Ознакомьтесь с правилами именования в .NET Framework, это также поможет всем, кто ответит на ваши будущие вопросы по C #.
OregonGhost 11.12.2008 10:03:29
Это относится также и к любому ОО-лангу. На самом деле, вам не нужно много гибкости. Последний вариант (с использованием метода класса) будет достаточно для вас. Однако, если вы хотите, чтобы все эти операции были помещены в отдельный класс, вы все равно можете называть ArticleFactory. Концепция остается самой
OscarRyz 11.12.2008 16:38:06

Хорошо, создайте статический класс для этой цели:

public static class clsArticles
{
    public static clsArticles[] GetAllArticles() { /* actual code */ }
}
0
11.12.2008 10:03:14
Потому что в настоящее время единственной целью класса является предоставление доступа к статическому методу.
Claymore 11.12.2008 10:07:34
Thnx. И я должен также использовать статические члены, например, для сохранения статьи? Или получить статью по идентификатору?
Martijn 11.12.2008 10:12:46

Вы также можете использовать подход, принятый модельными классами Rails ActiveRecord.

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

  // the other regular code here;
}

// client code
foreach(clsArticle obArticle in clsArticle.findAll())
{
  list.add(clsArticle)
}
1
11.12.2008 10:26:02
Да, это третий вариант, который я упомянул. Здесь действительно нет необходимости в дополнительной гибкости.
OscarRyz 11.12.2008 16:39:03
Я не очень согласен с приведенными выше замечаниями, потому что вопрос помечен «шаблонами проектирования» и «оригинальным дизайном», и нас не интересует (только) «самый быстрый способ, который будет работать».
eljenso 26.12.2008 20:03:47

То, что вы описываете, на самом деле не шаблон, а принцип программирования, называемый « Разделение проблем ».

Из вашего описания я бы настоятельно утверждал, что вы после структурного шаблона проектирования, а не шаблона творческого проектирования, так как распределение проблем кодирования обсуждается из-за творческого соучастия.

Итак, мое лучшее предположение заключается в том, что шаблон, за которым вы следуете, это, возможно, шаблон фасада или шлюзы . Обычно объекты (ваш clsClass) используются со шлюзами.

Однако я не обязательно рекомендую делать ваши методы статичными, поскольку с тех пор их нельзя проверять во время тестирования Business Logic. Вы хотели бы смоделировать эти типы методов, которые возвращают объекты доступа к данным, если они образуют слой данных приложения, поскольку вы не хотите обращаться к базе данных, когда бизнес-логика зависит от этих шлюзов / фасадов.

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
11.12.2008 17:15:44
Спасибо за ответ. Я не понимаю последнюю часть. Класс BookGateWay - это моя бизнес-логика. В моем случае этот класс содержит объект класса базы данных. Так это правильно, верно?
Martijn 11.12.2008 10:57:16
Последняя часть ответа предназначена для продвинутых разработчиков. Причина, по которой следует избегать использования статических методов на ранних этапах. Как правило, делать статические только там, где это необходимо. BookGateway действительно является бизнес-логикой и будет выполнять вызов базы данных и заполнять каждый класс clsClass значениями БД.
Llyle 11.12.2008 17:09:58
Ответ Оскара не то, что вы после. Используйте шлюз и просто добавьте все новые методы (... как SaveArticle (объект Article), GetArticleByID (int ArticleID), DeleteArticleById (int ArticleID) ...) к шлюзу, как вам требуется.
Llyle 11.12.2008 17:13:49

Не создавайте статические методы!

Ваша первая мысль должна быть интерфейсом .

Может быть, вы могли бы написать что-то вроде (пример на Java)

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

Все остальные вещи, которые вам нужно сделать со статьями, также входят в этот интерфейс. Вставьте конкретную реализацию этого класса (DbArticleService, XmlArticleService, ...) в каждый объект, который должен иметь дело со статьями.

Таким образом, как упоминалось в других постерах, вы получаете отсоединенный код и хорошее разделение интересов.

Но что бы вы ни делали, не делайте вещи статичными.

0
11.12.2008 16:40:56
Используя этот способ, куда я помещаю такие методы, как SaveArticle (объект Article), GetArticleByID (int ArticleID), DeleteArticleById (int ArticleID) и так далее?
Martijn 11.12.2008 11:04:29
На интерфейсе ArticleService.
eljenso 11.12.2008 13:08:35