Ввести зависимости в методах или в конструкторе?
(2) требуется много правил переписывания и эквивалентности, чтобы вы могли гарантировать это в общем случае. Конечно, если вы просто пытаетесь сделать это для этих двух конкретных регулярных выражений, то вы можете работать ad hoc.
(1), однако, «реальный» способ сделать это. Я удивлен, что вы знаете, как использовать лемму Ардена, но не обратное направление, которое гораздо более распространено (в учебниках и на практике) и проще. Буквально любая книга формальных языков или любая книга компиляторов даст вам по крайней мере один алгоритм для сопоставления регулярного выражения с DFA, а также для минимизации DFA. Если у вас нет доступа к таким книгам, я укажу вам на две статьи, которые я написал несколько лет назад, каждая из которых представляет таксономию (в то время всеобъемлющую) алгоритмов, одну для отображения регулярного выражения в DFA, а другую для минимизации. DFA: http://www.kornai.com/EFS/OnlineSupportMaterial/Watson/Papers/constax.600dpi.ps https://www.researchgate.net/publication/2247379_A_Taxonomy_of_Finite_Automata_im ]
И наконец, более полная работа содержится в моей собственной диссертации под названием «Таксономии и инструментарий алгоритмов регулярного языка», с 1995 года.
Кстати, я должен также упомянуть, что существует множество наборов инструментов, реализующих эти алгоритмы, на разных языках.
С наилучшими пожеланиями, Брюс
5 ответов
Главное преимущество инжекции конструктора - то, что она позволяет Вашим полям быть отмеченными финал. Например:
class Foo {
private final Bar _bar;
Foo(Bar bar) {
_bar=bar;
}
}
следующая страница имеет большой список за и против: Лучшие практики Guice :
инжекция Метода
- + не Является полевой инжекцией
- + Только вещь, которая работает на некоторые странные пограничные случаи
инжекция Конструктора
- +, Поля могут быть окончательными!
- + Инжекция не могла возможно быть пропущена
- + Легкий видеть зависимости сразу
- +, Это - то, что идея конструкции - все приблизительно
- - Никакие дополнительные инжекции
- - Бесполезный, когда библиотека DI не может сделать самого инстанцирования
- - Подклассы должны "знать об" инжекциях, необходимых их суперклассам
- - менее удобный для тестов, которые только "заботятся об" одном из параметров
Не вводя зависимость в каждом методе Вы затем вынуждаете каждую вызывающую сторону знать или получить зависимость.
Также с точки зрения инструментов существует много доступных платформ (по крайней мере, в.NET), которые включают или делают инжекцию конструктора намного легче сделать. Это не должно колебать решение, но делает его намного более привлекательным.
Удача.
Сумасшедший Bob Lee говорит инжекцию конструктора использования, когда это возможно. Только используйте инжекцию метода, когда Вы не будете управлять инстанцированием (как в сервлете).
Если Вы вводите во время методов, чем Вы не дифференцируете поведенческую абстракцию от конкретных зависимостей. Это - большое нет не :). Вы хотите зависеть от абстракций, таким образом, Вы не вместе с зависимостями Ваших зависимостей от классов...
, Так как Ваш конструктор не был бы там ни в каком интерфейсе, который Ваши поддержки реального класса, чем Вы не связывают с той зависимостью. Но вызовы метода имели бы ту проблему.
Вот хорошая статья об этой теме:
http://chrisdonnan.com/blog/2007/05/20/conquest-through-extreme-composition-glue-part-2/
Другой метод является пользователю методом set для зависимости. Иногда это объединено с инжекцией конструктора. Это может быть полезно, если Вы хотите измениться, какую реализацию Вы используете позже, не имея необходимость воссоздавать экземпляр.
public interface IFoo
{
void Do();
}
public class DefaultFoo : IFoo
{
public void Do()
{
}
}
public class UsesFoo
{
private IFoo foo;
public IFoo Foo
{
set { this.foo = value; }
}
public UsesFoo()
{
this.Foo = new DefaultFoo();
}
public UsesFoo( IFoo foo )
{
this.Foo = foo;
}
public void DoFoo()
{
this.Foo.Do();
}
}