Войти
ПрограммированиеФорумОбщее

Парадигмы эффективно снижающие сложность кода... (2 стр)

Страницы: 1 2 3 414 Следующая »
#15
0:28, 25 апр. 2012

kvakvs
> Не пиши акцессор (get(), set()) там где можно обойтись простым мембером (полем) класса.
+1. Вот моё мнение по этому поводу :)


#16
0:39, 25 апр. 2012

newbprofi2
я с тобой полностью согласен, бро.
прошёл через такие же дела.

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

#17
1:07, 25 апр. 2012

newbprofi2
Да, new bro, местами согласен. Таки, правда это обычно корпоративно запрещено и\или не возможно из-за работы в команде, поэтому следую корпоративным правилам.

Pushkoff
> используй const везде где это возможно
Ну, всё... Pushkoff тоже скоро уйдет в функциональщики...
Сам без исключений следую этому правилу, но называть бы его здесь не стал.
Таки сколько ошибок вы заметили в коде за всю свою карьеру благодаря модификатору const?

#18
1:22, 25 апр. 2012

bazhenovc
> > Не пиши акцессор (get(), set()) там где можно обойтись простым мембером (полем) класса.
> +1. Вот моё мнение по этому поводу :)
Из минусов - больше кода и не красиво.
Из плюсов:

  • Легче отладка (например отладочный IO или точку останова кинуть)
  • Контроль допустимости операций в данный момент выполнения программы или\и во время компиляции (например нет гетера или сетера)
  • Домены (контроль допустимости значений)
  • Проверка инвариантов
  • Легче модификация (абстракция от внутренней реализации поля, например его совсем можно выкинуть, заменив схожим в других единицах измерения или с другими характеристиками)
  • Легче введение межпоточной синхронизации при доступе к объекту
  • Таки возможность поддержать обращение к NULL-объекту, если не виртуальные сетеры\гетеры (ни разу мне не было нужно, но ответил на возмущения из ссылки выше).


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

    #19
    1:35, 25 апр. 2012

    laMer007
    >> Легче отладка (например отладочный IO или точку останова кинуть)
    TDD наше всё :)

    >> Контроль допустимости операций в данный момент выполнения программы или\и во время компиляции (например нет гетера или сетера)
    Один гетер или один сетер - норм. Я писал про то, когда лепят гет/сет на всё про всё.

    >> Домены (контроль допустимости значений)
    >> Проверка инвариантов
    Только там, где это нужно.

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

    >> Легче введение межпоточной синхронизации при доступе к объекту
    На вкус и цвет :)

    >> Таки возможность поддержать обращение к NULL-объекту, если не виртуальные сетеры\гетеры (ни разу мне не было нужно, но ответил на возмущения из ссылки выше).
    if (this) {...} ?

    #20
    1:55, 25 апр. 2012

    Не спеши решать задачу, подожди – может быть появится язык, на котором она решается оптимальным образом одним оператором.
    Кроме шуток.

    #21
    1:58, 25 апр. 2012

    Sbtrn. Devil
    Интересная статья, надо полностью прочитать.

    #22
    2:07, 25 апр. 2012

    bazhenovc
    > Не легче, во всех ИДЕ уже есть адекватный рефакторинг.
    Не видел я что-то таких, чтобы по всему коду присвоение на сеттер\геттер изменяли.

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

    > if (this) {...} ?
    Типа так, хотя человеку в здравом уме это врятли придёт. Не нужный паттерн. Но в смалталках и обджекси умудряются это как-то использовать.

    #23
    2:16, 25 апр. 2012

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

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

    Таким образом корпорациям нет смысла от процедурного программирования когда у них уже куча денег и куча людских ресурсов.

    А если один пишеш или всего человек 10 команда, из них всего 3-4 программиста, то ооп здесь не даст закончить проект, а убьет его на корню, мое мнение.

    К тому же я согласен с тем, что после того как проект уже реализован, то неплохо бы сделать рефакторинг и выделить объекты. Но при этом проект уже будет приносить доход, а код от рефакторинга будет уже только во 2й версии программы. Таким образом мы постепенно придем к ооп проекту, но только постепенно и только когда проект уже готов, хотябы первая версия. Тем более не факт что мы захотим делать 2ю версию и что рефакторинг вообще пригодится.

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

    #24
    4:53, 25 апр. 2012

    Dimich
    > А так можно делать?
    Нет. Для этого у мапы есть ::find

    Правка: в смысле по твоему вопросу - можно, но ошибка детектед :)

    #25
    7:45, 25 апр. 2012

    Dimich

    CTexture* CMaterialManager::LoadTexture(const std::string &filename)
    {
      if (textures[filename])
        return textures[filename];
    
      CTexture* texture = new CTexture(filename);
      textures[filename] = texture;
        return texture;
    }
    Изображение
    У индусов скопипастил ?

    Всё это можно сделать за 1 поиск по мапе с помощью
    всего 1-го инсерта, вот такого:

    pair <iterator, bool> insert(
         const value_type& _Val
      );

    #26
    8:04, 25 апр. 2012

    Hybernaculum
    > У индусов скопипастил ?
    Во-первых, код старый, во-вторых, вопрос заключался не в поиске по map'у.

    #27
    8:10, 25 апр. 2012

    > Парадигмы эффективно снижающие сложность кода
    Есть ещё пара хороших книжек по теме

    Изображение

    http://www.ozon.ru/context/detail/id/1308678/
    Изображение

    http://www.ozon.ru/context/detail/id/5011068/

    Dimich
    > Во-первых, код старый, во-вторых, вопрос заключался не в поиске по map'у.
    Предлагаю сначала научиться писать нормальный код, а уже потом
    заморачиваться как его красиво и удобочитабельно отформатировать.

    #28
    11:20, 25 апр. 2012

    bazhenovc
    > Интересная статья, надо полностью прочитать.
    Это не статья, а целая книжка, ещё едва ли не советского времени. У меня есть в бумажном виде. В онлайне, к сожалению, нашлось только такое - не хватает текстов программ. Но, говорят, её можно скачать в windjvu.

    #29
    11:25, 25 апр. 2012

    ryzed
    > Серебряной пули нет.

    вот и не будем об утопиях)))...

    Страницы: 1 2 3 414 Следующая »
    ПрограммированиеФорумОбщее

    Тема в архиве.