Главно рефакторинг мой код, этого добра хватает?


namespace SharpDream.Api
{
    public enum SourceType
    {
        Test,
        Xml
    }

    public class UserFinder
    {
        private IUserInformationSource _sourceType;
        private IParser _parserType;
        private string _source;

        public UserFinder(SourceType sourceType)
        {
            switch (sourceType)
            {
                case SourceType.Test:
                    var testSource = new TestSource();
                    _sourceType = testSource;
                    break;
                case SourceType.Xml:
                    var xmlSource = new XmlSource();
                    var xmlParser = new XmlParser();
                    _sourceType = xmlSource;
                    _parserType = xmlParser;
                    break;
                default:
                    break;
            }
        }

        /// <summary>
        /// Returns a User object loaded with information.
        /// </summary>
        /// <param name="forumUserId">The DIC forum users ID number.</param>
        /// <returns>A User object.</returns>
        public User GetUserById(int forumUserId)
        {
            _source = _sourceType.GetResponseSource(forumUserId);
            return _parserType.ParseUserFromSource(_source);
        }
    }
}

Чего я и добиваюсь:

  • Разделение проблем. Который работает верите вы или нет! Это настолько освежающе, чтобы чувствовать себя уверенно, что ваш код не сломается, если вы что-то изменить где-то еще. Я закончил этот бит, и теперь я могу работать на разборе области без того, чтобы положить что-нибудь еще в ментальный буфер.

  • Гибкость во время использования.

Вот пример, как моя библиотека будет использоваться:

UserFinder userFinder = new UserFinder(SourceType.Xml);
var foundUser = userFinder.GetUserById(1);

Сравните это с старой версии библиотеки:

//Let's create an XmlMemberFinder, since we'll use the XML api as our data source.
XmlMemberFinder xmlMemberFinder = new XmlMemberFinder();

//MemberList is the class you'll use in your application to get anything you need 
//relating to members.
MemberLister memberList = new MemberLister(xmlMemberFinder);

//This is an example of fetching and listing a user.
var member = memberList.FindMember(1);

Я думаю, что я сделал улучшения, но всегда найдется кто-то хитрее там. :)

Спасибо за ваше время!



323
2
задан 1 марта 2011 в 02:03 Источник Поделиться
Комментарии
3 ответа

Лично я UserFinder класс Источник-независимые.
Это может быть либо видя XML и испытание источников в качестве картографа и UserFinder в качестве модели (какой-то DataMapper):

public interface UserMapperInterface {}
public class XmlSource : UserMapperInterface { // ... }
public class TestSource : UserMapperInterface { // ... }

public class UserFinder {
public UserFinder(UserMapperInterface $source) { // ... }
public UserFinder() { // use default source }
}

Таким образом, вы сделать GetUserById способ источник-независимые. Основное использование будет:

UserFinder t = new UserFinder(new TestSource());
// UserFinder t = new UserFinder(); // using the default source
t.GetUserById(43);

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

8
ответ дан 1 марта 2011 в 04:03 Источник Поделиться

Ответ ФГР (наряду с комментарием Mongus понга) действительно отмечает главный вопрос с вашим дизайном. В общем, вы хотите избежать:


  1. С помощью перечислений на место полиморфизм.

  2. Утечка детали того, как вы проверить тип в тип. Вы это делаете явные ссылки на TestSource в UserFinder. Делать это усложняет основной тип с тестовым кодом и/или видов испытаний, которые не принадлежат. Обратите внимание, что есть времена, когда вам придется нарушить это "правило"; например, когда нет другого способа проверить объект, но, как правило, вы можете избежать его.

ФГР ответ предлагает замечательное решение для обеих этих проблем (хотя UserMapperInterface интерфейс должен быть действительно назван IUserMapper, но это просто придирки).

Как только вы получите этот шаблон МОК и инъекции зависимостей вниз вы находитесь на пороге чего-то, что действительно может изменить то, как вы писать и тестировать код: насмешливый. Большое введение о том, как и почему поиздевавшись можно найти здесь.

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

1
ответ дан 2 марта 2011 в 05:03 Источник Поделиться

Это выглядит довольно хорошо для меня. Главное, что выделяется, что я хотел изменить, что UserFinder() метод довольно большие, и это не сразу понятно для меня, что каждый кусок делает.

Я попытаюсь разбить на несколько более мелких, выразительно названном методов:

общественные UserFinder(тип источника тип источника) 
{
если (requestIsTest())
{
createTestSource();
}
еще
{
createXmlSource();
}
}

Ваш оригинал-это более компактная, но менее читаемым в моей книге. В шесть месяцев, когда вы вернетесь к нему, вы сможете вспомнить то, что он делает, или вы будете иметь, чтобы потратить 10 минут разбора его и выяснить, что он делает?

0
ответ дан 1 марта 2011 в 03:03 Источник Поделиться