Осуществление зависимостей в МОК через конструктора?
Это не полная ошибка вывода этой команды, это:
$ unzip "gradle-2.10-bin.zip"
Archive: gradle-2.10-bin.zip
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
unzip: cannot find zipfile directory in one of gradle-2.10-bin.zip or
gradle-2.10-bin.zip.zip, and cannot find gradle-2.10-bin.zip.ZIP, period.
И если мы проверим, что файл пуст. Если мы сделаем curl -I для этого URL, мы получим 301, поэтому вам нужно добавить -L к этой команде curl, чтобы следовать перенаправлению:
curl -L https://services.gradle.org/distributions/gradle-2.10-bin.zip
3 ответа
Я всегда думаю, что это легче объяснить на (вымышленном) примере ...
Представьте, что у вас есть интерфейс ICustomerRepository, интерфейс IShoppingCartRepository и интерфейс ICheckout. У вас есть конкретные реализации этих интерфейсов - CustomerRepository, ShoppingCartRepository и CheckoutService.
Ваш конкретный класс CheckoutService имеет конструктор, который принимает ICustomerRepository и IShoppingCartRepository - например,
public CheckoutService(ICustomerRepository customerRepository, IShoppingCartRepository shoppingCartRepository)
{
// Set fields for use in some methods later...
_customerRepository = customerRepository;
_shoppingCartRepository = shoppingCartRepository;
}
Затем, когда вы хотите, чтобы реализация ICheckoutService выполняла некоторую работу с вы указываете контейнеру IoC, какой конкретный класс он должен использовать для каждого типа интерфейса, и просите его создать для вас ICheckoutService. Ваш контейнер IoC пойдет и построит ваши классы для вас, вставляя правильные конкретные классы в конструктор вашего CheckoutService.
Ваш контейнер IoC должен создавать объект из конкретного типа, даже если то, что вы передаете, является интерфейсом. Ваш конструктор не является поведением или государственным контрактом, поэтому он не принадлежит интерфейсу или общедоступному члену вашего абстрактного класса.
Конструктор - это деталь реализации, поэтому вам не нужно отделять его определение от конкретного класс.
Вы не можете определять сигнатуры конструктора в интерфейсах. В любом случае это не имеет смысла, так как интерфейс не должен обеспечивать реализацию реализаций.
Хотя абстрактные классы действительно могут иметь конструкторы. Они должны быть защищены, так как публичные конструкторы также не имеют смысла. Они должны вызываться только конкретными подклассами.
Принцип IoC гласит, что вместо того, чтобы класс A знал о классе B и создавал его экземпляр, вам следует вместо этого передать ссылку на IB в конструктор A. Тогда A не нужно будет знать о классе B, и, таким образом, вы можете легко заменить класс B какой-либо другой реализацией IB.
Поскольку вы передаете уже созданный объект класса B, интерфейсу IB не требуется иметь сигнатуру конструктора.
Принцип IoC гласит, что вместо того, чтобы класс A знал и создавал экземпляр класса B, вы должны вместо этого передать ссылку на IB в конструктор A. Тогда A не нужно будет знать о классе B, и, таким образом, вы можете легко замените класс B какой-либо другой реализацией IB.
Поскольку вы передаете уже созданный экземпляр класса B, интерфейсу IB не требуется иметь сигнатуру конструктора.
Принцип IoC гласит, что вместо того, чтобы класс A знал и создавал экземпляр класса B, вы должны вместо этого передать ссылку на IB в конструктор A. Тогда A не нужно будет знать о классе B, и, таким образом, вы можете легко замените класс B какой-либо другой реализацией IB.
Поскольку вы передаете уже созданный экземпляр класса B, интерфейсу IB не требуется иметь сигнатуру конструктора.