Задать вопрос

stringer

Информация
Пользователь пока ничего не рассказал о себе

Наибольший вклад в теги

Все теги (12)

Лучшие ответы пользователя

Все ответы (7)

  • Программы для облегчения проектирования программ?

    @stringer
    Выполнил несколько проектов в Enterprise Architect. Плюсы:
    1. внятный учёт требований к ПО, позволяющий реально понять какой реквест чем реализуется;
    2. связка с контролем версий, можно хотя бы понять что когда и как менялось;
    3. реально выполним round-trip (генерация/реверс/генерация), не без проблем конечно, но другими средствами я вообще не смог добиться на своём шарпе;
    Минусы:
    1. плохо работает с женериками, генерация возможна, реверс - нет, он их не видит;
    2. некоторая тормознутость;
    3. сложно с масштабными диаграммами, но может просто у меня монитор маленький
    Ответ написан
    Комментировать
    Комментировать

  • Как, используя паттерн Wapper (Decorator/Wrapper), наследовать запечатанный класс?

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

    Как-то так:
    public class PathFigureCollectionWrapper
{
  private PathFigureCollection _pfc;

  public PathFigureCollectionWrapper(PathFigureCollection pfc)
  {
    _pfc = pfc;
  }

  public int Method()
  {
    return _pfc.Method();
  }
}

    нужные методы обёртки просто содержат вызовы обёрнутого экземпляра класса.
    Решарпер, кстати, генерит обёртки в один клик.
    Ответ написан
    1 комментарий
    1 комментарий

  • C#: построение тяжелых графиков в реальном времени

    @stringer
    Хороший обзор средств построения графиков был тут. Согласен с Sumor относительно того, что не надо перерисовывать на каждый чих.
    Ответ написан
    3 комментария
    3 комментария

  • Пара глупых вопросов по полиморфизму и наследованию?

    @stringer
    1. не надо так писать
    Ваш вопрос не про полиморфизм... Полиморфное поведение может демонстрировать к примеру функция:
    void Foo(IList list) { var bar = list[1]; }
    если ожидается, что на вход может приходить не совсем new List(), или даже совсем не List, а некое хранилище, которое обеспечивает доступ к элементам по индексу, и ради этого это хранилище реализует IList.

    2 ничем не отличается
    Разница возникла бы в коде,
    Base A;
switch(...)
{
  case 0:
    A = Derived_1();
    break;
  case 1:
    A = Derived_2();
   break;
}
A.Foo();

    в точке, где происходит вызов Foo(), тут полиморфизм обеспечивает исполнение разных версий метода для _1() и _2() наследников. В таком коде если бы Вы написали объявление А как в вопросе, case 1: компилятор у Вас забраковал бы, не говоря уже о том, что _2() не исполнялось бы никогда.
    Ответ написан
    Комментировать
    Комментировать

  • Нужно ли складывать enum, class в отдельные файлы всегда?

    @stringer
    Проблема есть, но корни её тянутся не от отсюда. Попробую объяснить на примере, представим: есть файл с двумя классами в проекте на 5к строк, проект имеет историю и сменный состав программистов. С течением времени файл разросся и некто Пупкин решает разделить его. Дело нехитрое - в проект добавляется новый файл, один из классов переносится в него, commit. На этом месте история правок перенесённого класса потеряна.
    Если бы каждый Пупкин мог корректно клонировать файл в репе, а потом делить с сохранением истории изменений, для облегчения понимания действительно было бы правильно связанные сущности в одно место, но в реале нам такого счастья не дано. На проект в любой момент может прийти новый персонаж, уровень компетенции наперёд непредсказуем, поэтому тактически более умным ходом считаю разделять всё по файлам. Исключение делаю только для enum и delegate объявленных совместно с интерфейсом, где они используются.
    Ответ написан
    Комментировать
    Комментировать