Информация об изменениях

Сообщение Re[4]: Конструктор с параметрами vs метод Init -- стоит ли и от 31.03.2016 14:59

Изменено 31.03.2016 15:01 Shmj

Здравствуйте, _NN_, Вы писали:

S>>При использовании контрактов двухуровневой не избежать.

_NN>Можно пример ?

Упрощенный пример:

  Скрытый текст
using System;

namespace ConsoleApplication30
{
    class Program
    {
        class Settings
        {
            public string LocalFolder { get; set; }
        }

        interface IFileService
        {
            // Нужно иметь гарантию что установлены настройки
            void Init(Settings settings);

            void DownloadFile(string fileName);
        }

        class TestFileService : IFileService
        {
            private Settings _settings;

            public void Init(Settings settings)
            {
                _settings = settings;
            }

            public void DownloadFile(string fileName)
            {
                Console.WriteLine("Скачиваем файл " + fileName + " и сохраняем в папку " + _settings.LocalFolder);
            }
        }

        static void Main(string[] args)
        {
            // Получаем необходимую запись через unityContainer
            //IFileService fileService = unityContainer.Resolve<IFileService>()
            // Для упрощения заменим:
            IFileService fileService = new TestFileService();

            // Вместо Init можно было бы задействовать InjectionConstructor, но это никак бы не отразилось на контракте.
            // По этому в контракте нужно либо сделать свойство Settings, либо метод Init. Поскольку при инициализации не просто устанавливаем значение, а и производим действия -- то метод.
            fileService.Init(new Settings {LocalFolder = "C:\\temp"});

            fileService.DownloadFile("fileName.txt");
        }
    }
}


_NN>Как вариант можете просто написать свой анализатор кода и всё контролировать извне.

_NN>Есть ещё вариант в виде библиотеки: https://github.com/default0/Introspect

Я бы предпочел максимально простой вариант, без доп. библиотек, когда можно без них.
Re[4]: Конструктор с параметрами vs метод Init -- стоит ли и
Здравствуйте, _NN_, Вы писали:

S>>При использовании контрактов двухуровневой не избежать.

_NN>Можно пример ?

Упрощенный пример:

  Скрытый текст
using System;

namespace ConsoleApplication30
{
    class Program
    {
        class Settings
        {
            public string LocalFolder { get; set; }
        }

        interface IFileService
        {
            // Нужно иметь гарантию что установлены настройки
            void Init(Settings settings);

            void DownloadFile(string fileName);
        }

        class TestFileService : IFileService
        {
            private Settings _settings;

            public void Init(Settings settings)
            {
                _settings = settings;
            }

            public void DownloadFile(string fileName)
            {
                Console.WriteLine("Скачиваем файл " + fileName + " и сохраняем в папку " + _settings.LocalFolder);
            }
        }

        static void Main(string[] args)
        {
            // Получаем необходимую реализацию через unityContainer
            //IFileService fileService = unityContainer.Resolve<IFileService>()
            // Для упрощения заменим:
            IFileService fileService = new TestFileService();

            // Вместо Init можно было бы задействовать InjectionConstructor, но это никак бы не отразилось на контракте.
            // По этому в контракте нужно либо сделать свойство Settings, либо метод Init. Поскольку при инициализации не просто устанавливаем значение, а и производим действия -- то метод.
            fileService.Init(new Settings {LocalFolder = "C:\\temp"});

            fileService.DownloadFile("fileName.txt");
        }
    }
}


_NN>Как вариант можете просто написать свой анализатор кода и всё контролировать извне.

_NN>Есть ещё вариант в виде библиотеки: https://github.com/default0/Introspect

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