Реализация синглтона с многократным освобождением ресурсов

#c_sharp #шаблоны_проектирования

                    
Как правильно реализовать многопоточный синглтон с возможностью в любой момент и
из любой нити освободить все занятые ресурсы и так чтобы при следующем запросе они
снова лениво разворачивались. 
    

Ответы

Ответ 1

А в чём проблема? Ну окружите весь доступ мьютексом. Поскольку вам нужна логика реинициализации,
простое решение с Lazy-свойствами не проходит.

public sealed class Singleton
{
    // классическая реализация из статьи Jon Skeet'а
    // http://csharpindepth.com/articles/general/singleton.aspx
    private static readonly Lazy lazy =
        new Lazy(() => new Singleton());

    public static Singleton Instance { get { return lazy.Value; } }

    private Singleton() { }

    /////////////////// ленивые свойства ///////////////////
    object accessMutex = new object();

    string lazyProperty;
    public string LazyProperty
    {
        get
        {
            lock (accessMutex)
                return lazyProperty ?? (lazyProperty = CreateLazyProperty());
        }
    }

    public void Reset()
    {
        lock (accessMutex)
        {
            lazyProperty = null;
            // обнулите остальные свойства, освободите IDisposable-ресурсы
        }
    }

    string CreateLazyProperty() { ... }
}

Подмена базового класса в сложившейся архитектуре классов

#c_sharp #шаблоны_проектирования

                    
Имеется базовый класс (предположим, Window), у которого огромное число классов-потомков
(BlackWindow, TransperentWindow, ...).

Предположим, что я хочу добавить в архитектуру класс BorderedWindow, который перегружает
пару виртуальных функций родительского класса Window. И далее я хочу, чтобы все имеющиеся
классы-потомки могли создаваться как от Window, так и от BorderedWindow.

Проблему можно проиллюстрировать следующим кодом:

class Window
{
    public virtual Rectangle ClientArea()
    {
        return new Rectangle(0, 0, 100, 50);
    }
}

class BlackWindow : Window
{
    public BlackWindow(Window window) { ... }
}

class BorderedWindow : Window
{
    public overide Rectangle ClientArea()
    {
        return new Rectangle(5, 5, 110, 60);
    }
}

Window window = new Window();
BorderedWindow borderedWindow = new BorderedWindow();
new BlackWindow(window).ClientArea();                // Rectangle(0, 0, 100, 50), ОК
new BlackWindow(borderedWindow).ClientArea();        // Rectangle(0, 0, 100, 50), FAIL!


В целом, здесь можно применить паттерн Декоратор. Но этого делать не хочется, так
как последуют существенные изменения классов-потомков. Придётся для каждой функции
класса Window писать функцию-"обёртку" в каждом классе-наследнике. Для десятка функций
и десятка классов объём кода вырастает драматически.

Как можно исправить ситуацию?
    

Ответы

Ответ 1

Почему бы тогда не «Стратегия»? Вместо довольно неудобного наследования переходите
на прогрессивную композицию. Пусть любой из классов получает ClientStrategy как часть
конструктора.

interface IClientAreaStrategy { Rectangle ClientArea { get; } }

class DefaultClientAreaStrategy : IClientAreaStrategy
{
    Rectangle clientArea = new Rectangle(0, 0, 100, 50);
    public Rectangle ClientArea { get { return clientArea; } }
}

class BorderedClientAreaStrategy : IClientAreaStrategy
{
    Rectangle clientArea = new Rectangle(5, 5, 110, 60);
    public Rectangle ClientArea { get { return clientArea; } }
}

class Window
{
    protected readonly IClientAreaStrategy clientAreaStrategy;
    public Rectangle ClientArea
    {
        get { return clientAreaStrategy.ClientArea; }
    }

    public Window(IClientAreaStrategy clientAreaStrategy)
    {
        this.clientAreaStrategy = clientAreaStrategy;
    }
}

class BlackWindow : Window
{
    public BlackWindow(Window window) : base(window.ClientStrategy)
    {
        // ...
    }
}


(Кстати, у нужно ли наследование для BlackWindow? Возможно, вам снова нужна композиция?)



Для конкретно этого случая вам не нужен целый интерфейс IClientAreaStrategy, а просто
Func или даже просто Rectangle. Но в более сложном случае понадобится интерфейс.

В чем преимущества выделения контроллера в mvc?

#java #mvc #шаблоны_проектирования

У меня сразу несколько вопросов по mvc. Спрашивать буду на примере игрушечной программки,
которую специально для этого написал:

public class View implements Observer {

private Model model;
private IController controller;

private JLabel firstNumber = new JLabel();
private JLabel secondNumber = new JLabel();
private JLabel resultLabel = new JLabel();

public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable() {
        @Override
        public void run() {
            Model model = new Model();
            IController controller = new Controller();
            View view = new View();
            view.setModel(model);
            view.setController(controller);
            view.createAndShowGUI();
        }
    });
}

public void setModel(Model model) {
    this.model = model;
    model.addObserver(this);
}

public void setController(IController controller) {
    this.controller = controller;
}

public void createAndShowGUI() {
    JFrame frame = new JFrame("mvc train");
    frame.setSize(400, 400);
    frame.getContentPane().add(createMainPanel());
    frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
    frame.setVisible(true);
}

private Component createMainPanel() {
    JPanel mainPanel = new JPanel();
    mainPanel.add(firstNumber);
    mainPanel.add(secondNumber);
    mainPanel.add(resultLabel);
    JButton inc1 = new JButton("increment first");
    inc1.addActionListener(new ActionListener() {

        @Override
        public void actionPerformed(ActionEvent e) {
            controller.execute("inc1", model);
        }
    });
    JButton dec1 = new JButton("decrement first");
    dec1.addActionListener(new ActionListener() {

        @Override
        public void actionPerformed(ActionEvent e) {
            controller.execute("dec1", model);
        }
    });
    mainPanel.add(inc1);
    mainPanel.add(dec1);
    JButton inc2 = new JButton("increment second");
    inc2.addActionListener(new ActionListener() {

        @Override
        public void actionPerformed(ActionEvent e) {
            controller.execute("inc2", model);
        }
    });
    JButton dec2 = new JButton("decrement second");
    dec2.addActionListener(new ActionListener() {

        @Override
        public void actionPerformed(ActionEvent e) {
            controller.execute("dec2", model);
        }
    });
    mainPanel.add(inc2);
    mainPanel.add(dec2);
    return mainPanel;
}

@Override
public void update(Observable arg0, Object arg1) {
    firstNumber.setText("" + model.getA());
    secondNumber.setText("" + model.getB());
    resultLabel.setText("" + (model.getA() + model.getB()));
}

}


Это класс представления. Получается такая картинка:


Кнопка increment first увеличивает на единицу первое число, increment second - второе,
decrement first уменьшает первое число на единицу, decrement secomd - второе. В общем,
после двух нажатий на increment first и одного нажатия на increment second получаем
такую картинку:



Два числа хранятся в модели. Вот она:

public class Model extends Observable {

private int a;
private int b;

public void incrementA() {
    a++;
    setChanged();
    notifyObservers();
}

public void incrementB() {
    b++;
    setChanged();
    notifyObservers();
}

public void decrementA() {
    a--;
    setChanged();
    notifyObservers();
}

public void decrementB() {
    b--;
    setChanged();
    notifyObservers();
}

public int getA() {
    return a;
}

public int getB() {
    return b;
}

@Override
public void addObserver(Observer observer) {
    super.addObserver(observer);
    setChanged();
    notifyObservers();
}

}


Мой контроллер:

public class Controller implements IController {

@Override
public void execute(String action, Model model) {
    switch (action) {
    case "inc1":
        model.incrementA();
        break;
    case "inc2":
        model.incrementB();
        break;
    case "dec1":
        model.decrementA();
        break;
    case "dec2":
        model.decrementB();
    }
}

}


Теперь вопросы.
Самый главный вопрос собственно в названии.


Чем нам помог контроллер? Код из веток case оператора switch в
контроллере мог бы с таким же успехом находится в слушателях. На
каждую ветку по слушателю. В итоге слушателей все равно приходится
создавать, что бы вызвать метод контроллера. А потом в этом методе в
операторе switch прописывать тот же самой код, что мог бы быть в
слушателях. Может быть я вообще неправильно реализовал mvc?
Подозреваю что именно так. Причем именно в части контроллера. Потому
что по нему в сети мало информации. Если это так то прошу подсказать
как правильно. Слышал что можно создавать контроллеры для каждого
элемента (в данном случае для каждой кнопки). Но ситуация не сильно
поменяется.
В моем примере все методы, которые вызывается в ветках case не имеют параметров.
В реальных программах это скорее всего будет не так. Некоторые кнопки могли бы требовать
вызовов методов с параметрами, причем с разным количеством параметров. Что делать в
такой ситуации?
Где лучше вычислять самое правое число? В моем примере я делаю это в функции update().
Не лучше ли это делать в модели?

    

Ответы

Ответ 1

Контроллер помогает структурировать код. Весь код, реагирующий на пользовательский
ввод, принадлежит контроллеру.

Можно было бы всё слить в один класс, и делать всю логику в OnClick, и код получился
бы наверное даже короче. Но вашей целью должен быть не самый короткий, а самый понятный
и легко поддерживаемый код.
Мне кажется, ваша диспетчеризация команд по строкам — неправильна. Команды должны
быть не строками, а объектами. (У нас же ООП, в конце-концов, да?) И вместо длинного
свитча у вас должен быть всего лишь вызов Invoke. [Но это практика из MVVM, общепринятого
паттерна в WPF, а традиции в MVC могут быть и другими.]
Вычисления принадлежат модели и только ей. Представление должно не выполнять работу
модели (а сложение в реальной программе превратится в серьёзное, длинное вычисление),
а лишь только отображать её.

Экспорт модели в .xlsx соблюдая SOLID

#c_sharp #ооп #шаблоны_проектирования #solid

В БД есть таблица результатов тестирования по русскому языку и математике (SubjectCode=2):

dbo.Result


Во второй таблице находятся просто сведения о школах:

dbo.School



Таких результатов бывает 40.000-70.000. Нужно на выходе получить для каждого тестируемого
вот такой отчет в pdf-файле:



Мое решение:


Создал Excel-шаблон;
Беру данные из базы и заношу их в этот xlsx-шаблон;
Сохраняю этот шаблон в pdf-файл;
И так для каждого ученика.




LearnerReport.cs

namespace so16092016.Models
{
    public class LearnerReport
    {
        public string SNS { get; set; } //Surname Name SecondName
        public string SchoolName { get; set; }
        public string ClassName { get; set; }
        public int TestResult5 { get; set; }
    }
}


Program.cs

using Excel = Microsoft.Office.Interop.Excel;

namespace so16092016
{
    class Program
    {
        static void Main(string[] args)
        {
            resultsEntities context = new resultsEntities();
            ResultsRepository resultsRepository = new ResultsRepository(context);
            var ma_results = resultsRepository.GetTList().Where(x => x.SubjectCode
== 2); //получить результаты по математике

            Excel.Application app = new Excel.Application();
            app.DisplayAlerts = false;
            Excel.Workbook book_template = app.Workbooks.Open(@"шаблон_отчета.xlsx");
            Excel._Worksheet sheet_template = book_template.Sheets["отчет"];

            foreach(var ob in ma_results)
            {
                //1. Создаем объкт LearnerReport из БД
                LearnerReport report = new LearnerReport
                {
                    SNS = $"{ob.surname} {ob.name} {ob.SecondName}",
                    SchoolName = ob.SchoolName,
                    ClassName = ob.ClassName,
                    TestResult5 = ob.TestResult5                     
                };

                //2. Экспорт объкта LearnerReport в шаблон xlsx
                sheet_template.Range["C4"].Value2 = report.SNS;
                sheet_template.Range["C5"].Value2 = report.SchoolName;
                sheet_template.Range["C6"].Value2 = report.ClassName;
                sheet_template.Range["C9"].Value2 = report.TestResult5;

                //3. Сохраняем полученный файл в .pdf на рабочем столе
                string file_name = $@"{Environment.GetFolderPath(Environment.SpecialFolder.Desktop)}\{report.SNS}.pdf";
                sheet_template.ExportAsFixedFormat(Excel.XlFixedFormatType.xlTypePDF,
file_name);
            }

            book_template.Close(0);
            book_template = null;
            app.Quit();
            app = null;
        }
    }
}


Необходимо: Приложение работает и дает необходимый результат. Но вы наверное видите,
что оно далеко от ООП (SOLID) и как результат очень трудно его "допиливать" и масштабировать.
Помогите правильно спроектировать данный механизм формирования подобных отчетов: 


логика экспорта модели в .xlsx должна быть у самой модели или
необходимо создать отдельный класс-менеджер для этого?
какие должны быть модели?
как правильно создавать модель-отчета на основе объектов БД? 
какой порождающий паттерн здесь больше подходит?

    

Ответы

Ответ 1

Конкретно в вашем случай нет необходимость, применять какие либо паттерны, т.к. у
вас довольно простая программа и паттерны добавят лишь ненужную сложность (применять
паттерны ради паттернов плохая практика).
Паттерны сгодятся если вы пишите большие Enterprise приложения, где необходима гибкость
и масштабируемость.

Если я правильно понял, то вы хотите отрефакторить программу.

1) Из кода я не понял что вы используете для получения данных из БД, но посоветовал
бы использовать какую нибудь ORM, например Entity Framework 6.

Создать DbContext и использовать его в репозиториях ResultsRepository и SchoolRepository
Все выборки засунуть в соответствующий репозиторий например

class ResultsRepository
{
    // возвращает все результаты
    public IEnumerable GetResults()

    // возвращает все результаты по заданому предмету.
    public IEnumerable GetResults(Subject subject)

    // возвращает все результаты для заданой школы.
    public IEnumerable GetResults(int idSchool)

    // возвращает все результаты для заданой школы по заданому предмету.
    public IEnumerable GetResults(int idSchool, Subject subject)    
}

class SchoolRepository
{
    // возвращает список всех школ.
    public IEnumerable GetSchools()
}


2) Модель данных приблизительно выглядит так

class Result 
{
    [Key]
    public Guid Id { get; set; }

    public string Surname { get; set; }
    public string Name { get; set; }
    public string SecondName { get; set; }

    [NotMapped]
    public string SNS => $"{Surname} {Name} {SecondName}";

    public School School { get; set; }

    public string ClassName { get; set; }

    public Subject Subject { get; set; }

    public int TestResult5 { get; set; }
}

class School
{
    [Key]
    public int Id { get; set; }
    public string Name { get; set; }
}

enum Subject
{
    RussianLanguage = 1,
    Mathematics = 2
}


3) Можно создать отдельный класс для работы отчётами

class LearnerReportManager
{
    public Excel._Worksheet CreateReport(Result result)

    public SaveReport(Excel._Worksheet reportWorksheet, string fileName)
}


4) Для формирования Excel отчёта луче используйте EPPlus или более крутой File Formats
от Syncfusion (у них есть бесплатная версия).
вы так не будите зависеть от установленного MS Office.

5) Если кол. формируемых отчетов за раз от 40 до 70 тыс., то 
было бы не плохо добавить многопоточное создание отчетов, это существенно уменьшит
время создания отчётов.

Приложения баз данных. Паттерны проектирования.

#c_sharp #шаблоны_проектирования #sql_server

Здравствуйте! Есть небольшая база данных, допустим, библиотеки. Какие паттерны проектирования
стоило бы использовать? Какие правила стоит учитывать при проектировании базы данных
и самого приложения? Стоит ли использовать паттерн MVP и какая выгода будет от этого?
Заранее спасибо.    

Ответы

Ответ 1

Как сказали в уточнениях, паттерн MVP действительно не имеет отношение к БД. Он скорее
имеет отношение к интерфейсной части (client-side).
Я бы сказал, что самое главное правило, которого стоит придерживаться при разработке
приложений, которые обращаются к БД, это трехслойная архитектура: UI - Business Logic
- DB. В самом тупом случае, слой DB у вас может представлять собой набор хелперов для
работы с БД.
В частности, отмечу некоторые важные моменты:


все прямые обращения к БД должны быть только в слое DB, никаких прямых вызовов к
БД, разбросанных по всему коду


все обращения к слою DB должны исходить только из слоя BL, в UI не должно быть прямых
вызовов кода из слоя DB


В остальном, реально не имеет значения (особенно в небольшом проекте), как у вас
будет организовано получение и сохранение данных: тупые датасеты, ORM или что-то еще.
Существует несколько распространенных паттернов для работы с данными, однако их применение
также не очень критично (и уж точно не стоит применять их ради самого факта применения,
о чем говорили выше). Главное — обособить код для работы с базой, это уже избавит вас
от множества проблем.
Ниже список некоторых паттернов для работы с БД:
http://design-pattern.ru/patterns/repository.html
http://ru.wikipedia.org/wiki/Data_Access_Object
http://design-pattern.ru/patterns/table-data-gateway.html
http://design-pattern.ru/patterns/row-data-gateway.html
http://design-pattern.ru/patterns/active-record.html -- тут я готов спорить, предпочитаю
иметь тупые объекты (DTO, только данные) плюс классы, которые отвечают за загрузку/сохранение
http://design-pattern.ru/patterns/data-mapper.html

Ревью Архитектуры приложения

#c_sharp #архитектура #шаблоны_проектирования #инспекция_кода

Есть решение разбитое на следующие слои: DAO, DAL, Services Gui где,


DAO - здесь хранятся классы описывающие доменнные модели;
DAL - Generic Repository и его реализация; 
Services - здесь у меня методы по типу следующего: IEnumerable GetEntities();
Gui - клиентская часть


предвижу сразу вопрос чем Services отличается от Repository, в репозитории у меня
базовые методы CRUD:

void Create(Entity entity);
void Update(Entity entity);
void Delete(Entity entity);
IQueryable Table {get;}


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

var _orders = получаем данные;
var _histories = получаем данные;
var orders = _orders.Join(_histories, o=>o.Id, h=>h.OrderId,(o,h)=>new OrderView
                    {
                        //Формируем необходимое представление
                    })
                    .ToList();


ну и т.п.

зависимости между проектами следующие:


DAO подключен в качестве reference в DAL, Services, Gui
DAL подключен в качестве reference в Services, Gui
Services подключен в качестве reference в Gui


Хочу проект сделать так что бы дальнейшая поддержка причиняла как можно меньше проблем.

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

Буду премного благодарен за ссылки на литературу которую стоит почитать что бы прояснить
для себя как правильно строить каркас приложения
    

Ответы

Ответ 1

Есть самые разные способы проектирования приложения. Как я вижу вы пытаетесь использовать
DDD. Этот паттрен достаточно универсален, но не является сильвербуллетом, а так же
имеет очень много вариаций реализации, например CQRS+ES или DDD+Onion которые имеют
свои назначения, а вместе с ним свои плюсы и минусы.

По мимо DDD и его вариаций, существуют такие архитектурные паттерны как EDA, SOA,
NLayer и другие.

Что бы поддержка не причиняла больших проблем, нужно сначала выбрать правильную архитектуру,
а это вопрос не только правильного выбора паттерна, но языка, стека технологий и многого
другого. Сам же выбор зависит от решаемой задачи и различных условий.


Ответ 2

Был у меня опыт разработки именно при такой архитектуре, только за место Entity Framework
использовался NHibernate. Ну и был еще один дополнительный слой абстракции для веб
сервисов. То бишь было параллельно несколько веб сервисов, которые пользовались фунциями
из слоя Services. 

В целом код получался весьма читабельным и понятным. Но вместе с этим при реализации
функции в GUI приходилось протягивать эту функцию через все слои это со временем начинало
бесить. Получалось как-то слишком много лишнего кода который приходилось писать лишь
из-за всех этих слоёв. Дебаг так же происходил чуть медленнее. Были некоторые трудности
с определением того куда стоит засунуть функцию, в DAL или Services. В целом считаю
данную архитектуру весьма адекватной для решения многих задач. Она предлагает высокую
степень гибкости и читабельности, но может стать очень громоздкой. Что бы избавиться
от громоздкозти этого монолита мне кажется, можно было бы начать отщипывать от монолита
микросервисы.

Паттерны Poor Man's DI и Bastard Injection

#шаблоны_проектирования

Наткнулся в сети на комментарий, в котором упоминались паттерны Poor Man's DI и Bastard
Injection -- что это такое и в чём между ними разница?

(Любой язык программирования, не обязательно c#)
    

Ответы

Ответ 1

Poor Man's DI, также называемое Pure DI - это DI без специальной библиотеки-контейнера.
В случае использования такого подхода все зависимости классов выносятся в параметры
их конструкторов либо в свойства, причем все классы, конструкторы и свойства обязаны
быть открытыми. Пример на C#:

public class Baz
{
    private readonly IBar bar;
    public Baz(IBar bar)
    {
        this.bar = bar;
    }
}


В Composition Root же пишется код, который собирает все эти классы вместе - то есть
весь граф объектов собирается вручную. Код получается вроде вот такого:

var foo = new Foo();
var bar = new Bar(foo);

SomeFrameworkClass.SetControllerFactory(() => { // точка входа
    var baz = new Baz(bar);
    return new Controller(foo, baz);
});


В чистом виде Pure DI используется редко, однако если ваши классы написаны с использованием
Pure DI-подхода, то к проекту можно прикрутить любую библиотеку-контейнер, или же сменить
ее в любой момент.



Bastard Injection же - это полная противоположность прошлому подходу. В случае использования
Bastard Injection каждый класс самостоятельно затягивает свои зависимости из контейнера
используя его как Service Locator:

public class Baz
{
    private readonly IBar bar = App.container.Resolve();
}


Главный недостаток такого подхода - зависимости оказываются раскиданы по коду. К
примеру, без доступа к исходникам единственный способ определить какие зависимости
нужны классу Baz - это вызвать его конструктор и посмотреть на отсутствие чего он ругнется.
А уж опциональные зависимости без документации найти можно только декомпиляцией.

Какой паттерн проектирования выбрать?

#проектирование #шаблоны_проектирования

Занимаюсь разработкой небольшого клиент-серверного приложения. Использую многослойную
архитектуру. В настоящий момент закончил реализацию слоя доступа к данным, при разработке
этого слоя использовал паттерн Репозиторий. Теперь у меня есть своеобразный шлюз (интерфейсный
класс), при помощи которого слой бизнес-логики может получать все необходимые данные
из базы данных.

Посоветуйте, какие паттерны следует использовать в слое бизнес-логики, чтобы затем
реализовать, скажем, сервисный слой. Какие есть варианты?

Поправьте меня, если я чего-то недопонимаю, или вопрос задан некорректно. Спасибо.
    

Ответы

Ответ 1

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

Забудьте на время о паттернах. Они не самоцель. Сперва делайте так, как вам кажется
правильным. И в какой-то момент некоторые задачи покажутся знакомыми и уже их при желании
можно решить, применив тот или иной паттерн.

Еще лучше, забудьте о паттернах на годик. И вернитесь к ним после того, как получите
чуть больше опыта. Тогда, я уверяю вас, вы совершенно по-другому на них взглянете,
и более того, даже поймете, что использовали некоторые из них, не осознавая этого.
Проанализировав свой опыт, поймете, где могли бы применить тот или иной шаблон. Еще
раз повторюсь, вы неправильно понимаете для чего нужны паттерны, если отталкиваетесь
от них. Шаблоны -- не самоцель, а лишь средство. Это как спрашивать "я хочу построить
дом, какой кирпич мне взять?". Вы не с того начинаете, строитель!


Ответ 2

Если в бизнес-логике находится неизменяемая часть программы, а реализация сервисов
может меняться, то в такой ситуации сервисы надо определить как интерфейсы, и реализовать
их в классах. При этом в бизнес-логику передается только интерфейс сервиса, а сами
классы (т.е. реализация интерфейса) должна быть недоступной из бизнес-логики. 

Это позволяет менять реализацию сервисов, не меняя бизнес-логику. Например, использовали
сервис логирования, который выводил данные в файл, а позже решили выводить данные в
облачный сервис. Для этого надо заменить только реализацию сервиса, а бизнес-логика
остается без изменений.

Такой паттерн называется "Cтратегия" -- это изолирование изменяемой части посредством
интерфейса.

Для передачи интерфейсов сервисов в бизнес-логику используется инъекция зависимостей
(Dependency Injection, DI). 
Для внедрения зависимостей используются разные способы и целые фреймворки, например, MEF.

Как перевести понятия MVP/MVC в термины WinForms?

#c_sharp #winforms #шаблоны_проектирования

В описании паттерна MVP (Model-View-Presenter) сказано следующее:


Model (Модель) — предоставляет данные для пользовательского интерфейса.   
View (Представление) — реализует отображение данных (Модели) и маршрутизацию пользовательских
команд или событий Presenter-у.   
Presenter — управляет Моделью и Представлением. Например извлекает данные из Модели
и форматирует их для отображения в Представлении.   


Что в WinForms приложениях соответствует View и Presenter?
    

Ответы

Ответ 1

Стандартная лапша - в code-behind форм в обработчиках событий производится запросы
к модели, какая-то работа и визуализация результата.

В mvp модель остается моделью, то есть это набор бизнес-логики, а код в форме делится
на View и Presenter

View - это формы, code-behind этих форм, где производится работа по визуальной составляющей,
а также туда же сводятся подписки на события контролов

Presenter - туда вынесен рабочий код, который не являются частью визуализации. View
содержит ссылку на presenter и вызывает его методы. А presenter содержит ссылку на
View через интерфейс

То есть View в обработчиках событий контролов делегирует presenter-у "сделай это",
а presenter содержит управляющий код, который опросит модель, получит результат и потом
дернет View и скажет ему "отрисуй такое то" 

Таким образом визуализирующий и управляющий код разделяются.

По просьбе @Stack привожу пример. Псевдошарпокод.

Имеем простую модель (она же бизнес логика). Просто читает файл планет

class PlanetReader{  
    public IList ReadPlanetsFromFile(){
        return File.ReadLines(...)
   }
}


Далее интерфейс представления 

public interface IMainView{
    void ShowPlanets(IList planets);  
}


ну и презентер

public class Presenter{

    private IMainView _view;

    public Presenter(IMainView view){
      _view=view;
    }            

    public void LoadPlanets(){
        var planets=new PlanetReader().ReadPlanetsFromFile();                        
        _view.ShowPlanets(planets);                                     
    }
}


и представление winforms

public partial class MainForm : Form, IMainView{

    private Presenter _presenter;

    public MainForm(){                
      InitializeComponent();          
      button.Click+=OnButtonClick;          
     _presenter=new Presenter(this);
    }         

    public void OnButtonClick(...){
         _presenter.LoadPlanets();
    }


    public void ShowPlanets(IList planets){
       TextBox.Text=string.Join("\n", planets);
    }

}


для WPF код в общем то идентичен Winforms кроме класса родителя и сигнатур обработчиков
событий (хотя лучше все таки MVVM)

public partial class MainWindow : Window, IMainView


для консоли

class ConsoleApp : IMainView {

  private Presenter _presenter;

  public ConsoleApp(){
     _presenter=new Presenter(this);
  }                                               

  public void Run(){
     Console.WriteLine("press any key to load planets');
     Console.ReadKey();
     _presenter.LoadPlanets();
  }

  public void ShowPlanets(IList planets){
      Console.WritrLine(string.Join("\n", planets));
  }

}


за IMainView может быть скрыто что-угодно - от простой формы winforms до самописной
системы отрисовки  на удаленной машине.

Плюшки:


"Логика интерфейса" по факту делится на "презентационную логику" и собственно "логику
визуализации".
В "презентационную логику" входит решение, что делать по нажатию на кнопку и что
делать с результатом - по сигналу от UI работает с моделью и просит потом "логику визуализации"
отобразить результат.
В "логику визуализации" входит отображение того, что просят - контролы, события,
установки полей у контролов, кобминирование контролов и так далее.
Презентер не имеет прямой ссылки на представление, поэтому детали отображения на
UI инкапсулированы (опять же чистота кода, вся сложность спрятана) и возможность заменять
представление на другое.
Презентер не имеет прямой ссылки на представление, а значит вместо представлениям
можно подсунуть заглушку и протестировать презентер. Тестировать же логику интерфейса
без такого разделения крайне сложно (нужно тыкать мышью руками или автоматикой и считывать
как то результаты с экрана)


Ответ 2

Решил добавить еще один ответ, потому что размер комментариев ограничен, а у @Stack
все перемешалось в голове и мой пост отвечает не на вопрос "как", а на "где и почему?"

Цель MVP не сделать возможность подмены UI (для этого просто нужно менять UI), а
разделить ответственности и обеспечить тестируемость.

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

у нас разные UI на разных платформах.

варианты:


Делаем проект-ядро, где будет логика приложения и создаем по проекту
UI на каждую платформу и при компиляции оно разберется
Делаем UI на кроссплатформенных контролах
прячем за фасадом (паттерн такой) любые реализации UI приводя их к обобщенному виду
фасада. Банально делается класс/интерфейс за которым прячется реальный UI. но это 
не MVP, а просто сокрытие сложности и зависимостей
Для подобной же цели служит паттерн "мост". Отличие от варианта с "фасадом", что,
вместо сокрытия реализации за фасадом, более ярко выражена связующая шина между приложением
и графическим приложением и независимость реализации обоих частей


А где же MVP?

Когда задача подмены UI решена, то нужно реализовать эти самые UI.

Допустим одна из наших UI на WinForms.
В силу особенностей Visual Studio мы получаем на выходе в Code-Behind основной формы
кучу методов (евент-хендлеры и кучу приватных методов реализующих логику интерфейса).
Мало того, что это лапша кода, так еще все это невозможно тестировать - для тестирования
нужно тыкать на кнопки и отслеживать изменение GUI, что сложно.

Возникает желание навести порядок. Это можно сделать 101 способом (MVC/MVP/MVVM/MVVMC/свой
вариант), просто некоторые в конкретном случае будут менее удобны чем другие, а ведь
еще хочется не терять визуальный дизайнер студии. И паттерн MVP хорошо подходит для
UI, где нет нормальных биндингов, потому что прост и прячет кучу визуализационного
кода за интерфейсом. Это и Winforms, и я вот под андроид тоже использую MVP.

вообще то это очевидное решение - разделить godobject на классы и удалить зависимости
от реализаций, спрятав за интерфейсами. Типичные варианты решений и обозвали паттернами

Разделив визуализацию и логику мы получаем возможность тестировать ту логику, что
вошла в презентер (а туда входит вся управляющая логика взаимодействия с моделью и
управления визуализацией). Тестировать просто, ведь презентер просто класс с зависимостями.
Если же еще хочется тестировать кнопочки, то winium в руки, но тестировать UI всегда сложно

"как в вашем примере тестировать Presenter. из-за new в методе LoadPlanets() { var
planets=new PlanetReader()...} его невозможно тестировать отдельно от конкретной модели"
@Stack

Для этого используется то, что называется "принцип инверсии зависимостей". Еще одно
очевидное решение, имеющее свое название

Делаем интерфейс IPlanetReader и выносим его в конструктор. Или же используем ServiceLocator.
Или же IoC-контейнеры. Или любой другой вариант. MVP всего лишь вариант разделения
на ответственности "где за что отвечает", а реализация ответственностей уже не входит
в него и там полная свобода действий



тестирование UI это проверка того как смотрятся шрифты -это вообще тестируется только
глазами. мы же говорим про автоматическое тестирование. 

Тестирование через эмуляцию нажатий кнопок и считыванием информации с контролов.
недостатки: сложность считывания даннных (мало ли какие контролы), сложность изоляции
(для проверки, что пользователь существует нам нужно подсунуь базу где пользователь
есть), скорость работы (из-за того, что полностью работают все слои приложения). Не
выявляет функциональные ошибки, когда делает не то, но показывает правильный результат.

При тестировании презентера можно изолировать и подсунуть любые данные, проверить
что идет правильный порядок вызовов модели. Пишется намного проще, есть изоляция и
высокая скорость работы. В идеале должно быть больше различных тестов, но выбор необходимых
тестов определяется возможностями (тесты бизнесу не нужны. они нужны программисту и
за них платить не любят). 

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


Ответ 3

Давайте представим, что надо создать справочник планет Солнечной системы в виде Console
Application. Список планет выводится в консоль. Для выбора планеты надо набрать ее
порядковый номер и нажать Enter.
В соответствии с описанием паттерна в своей программе надо определить три отдельных
класса. При этом Presenter не должен знать как работает View, который по команде Presenter'a,
выводит список планет в консоль, а введенный порядковый номер планеты возвращает Presenter'у.
Считается, что такое разделение и сокрытие деталей реализации позволяет сделать части
системы заменяемыми. Но это не так.
Представьте, что прошло время, и надо в справочник планет добавить миллионы астероидов,
сделать 3D визуализацию движения объектов и реализовать сенсорное управление.
Понятно, что если Model можно дополнить, то Presenter и View придется создавать с
нуля, т.к. UI-логика совершенно отличается от той, что была в консольном приложении.
При этом логика в Model (бизнес-логика) никак не меняется и не зависит от UI-логики.



Паттерн MVP является производным от MVC (Model-View-Controller), который был представлен
в 1979 г. и назывался Thing-Model-View-Editor. На сайте автора, профессора Реенскауг
Трюгве, видно на графике, что Controller и несколько View объединяются в Tool.



Графический интерфейс в Windows построен на основе оконной подсистемы - Windows Manager,
GDI и DWM. Есть десятки системных функций WinAPI, которые позволяют управлять окнами,
перехватывать события движения мыши и т.д.

В WinForms базовым классом для создания графического интерфейса является Control.  

Если посмотреть на определение MVP, то получается, что раз Control позволяет отображать
данные и получать события мыши и т.д., то Control - это и есть View. Но это не так.  

Дело в том, что Control является оберткой для оконной подсистемы Windows, взаимодействие
с которой происходит через вызовы функций Win API (их можно увидеть в исходниках Control).

Движение мыши, нажатия клавиш и другие системные события попадают в Message Queue
(это очередь системных событий, которые транслируются в вызовы соответствующих методов
Control; системные события можно перехватывать, если переопределить метод WndProc или
PreProcessMessage).

Получается, что View - это оконная подсистема Windows, а Presenter - это Control.

 MVP       :  WinForms приложение 
----------------------------------------------
 Мodel     :  Объекты для работы с данными
----------------------------------------------
 View      :  Оконная подсистема Windows
----------------------------------------------
 Presenter :  Производные от Control


Пример на C# с цитатами из определения паттерна MVP.

interface IModel {
   int Data { get; set; }
}

class Presenter : TextBox {
   IModel Model;

   public Presenter(IModel m) {
      this.Model = m;   
      var d = m.Data;  // извлекаем данные из модели
      var s = d.ToString(); // форматируем данные для отображения
      this.Text = s;  // передаем в Представление (оконная подсистема Windows).   
   }

   // маршрутизация пользовательских команд
   protected override void OnKeyDown(KeyEventArgs e) {
      base.OnKeyDown(e);
      if (this.Text.Contains("1")) {   // логика
         var d = int.Parse(this.Text); // форматируем данные          
         this.Model.Data = d; // управляем моделью
      }
   }
}

Паттерн “Посетитель”. Java

#java #шаблоны_проектирования

В первый раз реализую, и что-то не заработало.

public interface FieldVisitor {
    Object visit(Field field);
}


А это методы из реализации:

private FieldVisitor factory = new FieldVisitor() {
    public Object visit(PresetField presetField) {
        ....
    }

    public Object visit(StringField stringField) {
        ....
    }

    @Override
    public Object visit(Field field) {
        System.out.println(field.getClass());
        ....
    }
};


Вызываю так:

public Node getFieldFor(Field field) {
    return (Node) factory.visit(field);
}


Видно что приходят объекты разных классов:

class com.dma.params.model.field.PresetField
class com.dma.params.model.field.PresetField
class com.dma.params.model.field.NumberField
class com.dma.params.model.field.NumberField
class com.dma.params.model.field.StringField
class com.dma.params.model.field.BooleanField


Однако попадаю как видно только в метод для суперкласса. В общем, как я понял, какой
тип указателя, такая функция вызывается. Я могу как то изменить это поведение? Чтобы
вызывалась функция для фактического типа или я где-то тупанул с паттерном?
    

Ответы

Ответ 1

Потому что всё совершенно не так.

Во-первых интерфейс визитёра должен объявлять методы для всех классов иерархии

public interface FieldVisitor {
    Object visit(PresetField field);
    Object visit(StringField field);
    ...
}


Во-вторых родоначальник иерархии объявляет абстрактный метод accept, в котором принимается
визитёр

class Field {
    ...
    public abstract void accept(FieldVisitor visitor);
    ...
}


В-третьих конкретные такие потомки реализуют/переопределяют метод-акцептор таким
образом, чтобы вызывался метод визитёра для нужного (своего) класса  

class StringField {
    ...
    @Override
    public abstract void accept(FieldVisitor visitor) {
        visitor.visit(this); // вызов visit(StringField field)
    }
    ...
}


Наконец визитёр может посетить иерархию, предварительно реализовав интерфейс визитёра
вызовом акцептора  

...
field.accept(new FieldVisitor() {
    @Override
    Object visit(PresetField field) {
        ...
    }

    @Override
    Object visit(StringField field) {
        ...
    }

});
...


Благодаря полиморфизму вызывается accept конкретного класса, который в свою очередь
вызывает "свой" перегруженный метод визитёра.

Паттерн ООП, ограничивающий количество экземпляров класса по аттрибуту

#ооп #многопоточность #шаблоны_проектирования

Как организовать невозможность в программе существования нескольких экземпляров одного
класса с одинаковым значением определенного атрибута? 
Как называется такой паттерн ООП (если он есть)?
Пишу приложение на JAVA, многопоточное, но примеры интересны на различных языках
программирования (естественно с ООП парадигмой).    

Ответы

Ответ 1

В общем случае наиболее подходит под вашу задачу паттерн Factory. В частном случае,
когда разрешен всего 1 объект это классический Singleton. Единственное, я бы не стал
возлагать на паттерн задачу безопасности ибо что Singleton, что Factory ломаются на
раз-два.
Update
Применительно к Java такой способ ведь действительно существует и часто используется
в реальной жизни - например кэширование пула коннектов (например JDBC). Как известно,
коннект ресурс достаточно дорогой и ценный и если по ходу пьесы коннект берется во
многих местах имеет смысл организовать кэширование коннектов с ограничением количества
оных. 
Вполне аналогично также и ставится ограничение на количество окон в системе. Да в
том же Android'е надысь писал такую штуку. Ставится корневой класс - прародителей всех
Activity и вперед создавать списочек, контроль все как надо.
Так что надо попроще и без кошачьих завихрений, а то совсем ужо замутили головы boost
commiter, перегрузка операторов... 
P.S. Ну вы млин даёте :)


Ответ 2

Эта задачу (если решать ее в общем виде) очень сложно решить хорошо в языках с Garbage
Collector'ами в силу недетерминированности работы последних. 




Под хорошим решением подразумевается что-то типа специальной фабрики ObjectFactoryWithAttributeChecking,
в которой хранятся слабые ссылки на объекты выбранных типов, и при попытке создания
нового объекта она проверяет, жив ли прошлый / прошлые или нет.


Понятно, что, в силу недетерминированности GC очень легко получить ситуацию, когда
на объект уже никто не ссылается, но он еще не заколлекчен (и в этот момент фабрика
ObjectFactoryWithAttributeChecking будет вести себя некорректно).




Плохой подход - вводить такую же фабрику с явными методами Create и Dispose - решает
задачу, но сводит на нет преимущества автоматической сборки мусора и крайне неустойчив.


Если calling site в случае такого подхода забудет вызвать Dispose, то ваша фабрика
моментально оказывается в неконсистентном состоянии.


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


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


В случае языков без сборки мусора (типа C++) вроде как можно реализовать решение
на уровне собственного аллокатора, но сделать это правильно для всех кейсов крайне
нетривиально. Такая задача должна быть по зубам разработчиками уровня boost commiter,
да и то, наверняка, не всем.


Небольшой Update:

Сейчас еще раз перечитал вопрос и, в принципе (если вас устроит такой подход), вы
можете просто сделать фабрику ленивых синглтонов - т.е фабрику с методом getObjectWithSomeConcreteAttribute,
которая будет создавать объект с таким атрибутом только один раз по его первому запросу.


Создание объектов в обход фабрики в таком случае, разумеется, надо запретить.


Другое дело, что это не слишком интересно, если сравнивать с задачей, решения для
которой я предлагаю выше :)


Ответ 3

Есть такой вариант решения "проблемы", недостатки такого подхода очевидны, хотя вариант
имеет право на жизнь (видел в нескольких enterprise продуктах): 
public enum TestEnum {

    INTEGER {
        @Override
        public void doAction(Object arg) {
            if (arg instanceof Integer) {
                System.out.println("int - " + arg);
            }
        }
    },
    STRING {
        @Override
        public void doAction(Object arg) {
            if (arg instanceof String) {
                System.out.println("str - " + arg);
            }
        }
    },

    BOOLEAN {
        @Override
        public void doAction(Object arg) {
            if (arg instanceof Boolean) {
                System.out.println("bool - " + arg);
            }
        }
    };

    public abstract void doAction(Object arg);

    public static void applyAction(Object arg) {
        System.out.println("Handling: '" + arg + "'");
        for (TestEnum e : values()) {
            e.doAction(arg);
        }
    }

    public static void main(String args[]) {
        List