Как перестать программировать на С++ в Паскаль стиле?

← →
Медвежонок Пятачок © (2009-05-18 12:58) [120]

Вот и получаем на выходе код, который не плохо было бы отрефакторить.

Кто-то получает такой.
А кто-то получает совсем другой код.

← →
Alkid © (2009-05-18 13:02) [121]

> Медвежонок Пятачок © (18.05.09 12:56) [118]
> Расслабся лучше.

Нет-нет, не уходите от ответа, нам очень интересно послушать :)

Если серьёзно - я сам раньше считал точно так же. Мол, проектируем универсально расширяемую систему и мы в шоколаде. Однако реальность всегда била меня по лицу тем, что изменения возникали из неожиданных мест. По-этому очень интересно узнать на основании какого опыта делаются подобные обобщения.

← →
Медвежонок Пятачок © (2009-05-18 13:04) [122]

Да не систему проектируем, очертания которой могут быть не известны до конца.
А код структурируем так, что его рефакторинг в первый день назначенного релиза не потребуется.

Ты же не систему рефакторишь, а код.

← →
Игорь Шевченко © (2009-05-18 13:25) [123]

Любая универсальность, сделанная в расчете на возможные будущие изменения, есть зло по определению :)

← →
Mystic © (2009-05-18 14:15) [124]

> не нажимать шифт в начале идентификатора -)

Стилей написания в самом C++ до черта.

← →
MsGuns © (2009-05-19 11:33) [125]

>Игорь Шевченко © (18.05.09 13:25) [123]
>Любая универсальность, сделанная в расчете на возможные будущие изменения, есть зло по >определению :)

Подписываюсь всеми четырьмя руками и ногами :)

← →
oxffff © (2009-05-19 11:57) [126]

> Игорь Шевченко © (18.05.09 13:25) [123]
> Любая универсальность, сделанная в расчете на возможные
> будущие изменения, есть зло по определению :)

:)
Вы очень часто рекомендуете книги к прочтению.
Вы их сами внимательно читаете?

← →
Игорь Шевченко © (2009-05-19 12:05) [127]

oxffff © (19.05.09 11:57) [126]

> Вы их сами внимательно читаете?

В связи с каким именно моим словом возник подобный вопрос ?

← →
oxffff © (2009-05-19 13:02) [128]

> Игорь Шевченко © (19.05.09 12:05) [127]

> есть зло по >определению :)

В книгах которые предлагаете("навязываете") так и пишут?
Если это ваша точка зрения. Где аргументы?
И вам очень нравится глубочайший рефакторинг?

← →
oxffff © (2009-05-19 13:18) [129]

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

← →
clickmaker © (2009-05-19 13:32) [130]

> Универсальный обобщенный код является показателем мастерства
> программиста

Возможно. Но программирование - прикладная наука, а не мастерство ради мастерства.

← →
Anatoly Podgoretsky © (2009-05-19 13:42) [131]

> clickmaker (19.05.2009 13:32:10) [130]

Иногда шаманство.

← →
Alkid © (2009-05-19 14:02) [132]

> oxffff © (19.05.09 13:18) [129]
> По моему глубокому убеждению. Универсальный обобщенный код
> является показателем мастерства программиста.

Или его желания самовыразиться ;)

← →
oxffff © (2009-05-19 14:10) [133]

> clickmaker © (19.05.09 13:32) [130]
> > Универсальный обобщенный код является показателем мастерства
>
> > программиста
>
> Возможно. Но программирование - прикладная наука, а не мастерство
> ради мастерства.

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

← →
Игорь Шевченко © (2009-05-19 14:11) [134]

Alkid © (19.05.09 14:02) [132]

> Или его желания самовыразиться ;)

Я бы даже сказал - самовыпендриться.

oxffff © (19.05.09 13:18) [129]

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

Это пройдет.

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

2. Правило ясности - ясность лучше, чем мастерство.

5. Правило простоты - необходимо проектировать простые программы и "добавлять сложность" только там, где это необходимо.

(с) Эрик Реймонд, "Искусство программирования для Unix"

← →
Mystic © (2009-05-19 14:16) [135]

> Универсальный обобщенный код является показателем мастерства
> программиста.

Универсальность во всем сродни проституции.

Любая программа на Delphi менее универсальна, чем само Delphi. Зато некоторый набор действий на ней выполнять проще и быстрее. Сам смысл разработки в том, чтобы теряя универсальность упрощать выполнение некоторых частных случаев.

← →
oxffff © (2009-05-19 14:33) [136]

> Mystic © (19.05.09 14:16) [135]

> Игорь Шевченко © (19.05.09 14:11) [134]

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

← →
oxffff © (2009-05-19 14:39) [137]

> Игорь Шевченко © (19.05.09 14:11) [134]
> Alkid © (19.05.09 14:02) [132]
>
>
> > Или его желания самовыразиться ;)
>
>
> Я бы даже сказал - самовыпендриться.

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

← →
oxffff © (2009-05-19 14:45) [138]

>Mystic © (19.05.09 14:16) [135]
> Любая программа на Delphi менее универсальна, чем само Delphi.
>

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

Так что к чему ваши слова я малось не понял. :)

← →
Игорь Шевченко © (2009-05-19 14:48) [139]

oxffff © (19.05.09 14:39) [137]

Скорее говорит печальный опыт попытки повторного или хоть какого-то использования результатов деятельности программирующих "универсальные" решения

← →
oxffff © (2009-05-19 14:53) [140]

> Игорь Шевченко © (19.05.09 14:48) [139]

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

GOF паттерны, итераторы, MulticastDelegate(в противовес procedure of object) являются универсальными решениями.
Особенно MulticastDelegate какая мелочь этот связный список,
но какой качественный отрыв.

← →
Mystic © (2009-05-19 14:57) [141]

> oxffff © (19.05.09 14:33) [136]

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

← →
Alkid © (2009-05-19 15:05) [142]

> oxffff © (19.05.09 14:33) [136]
> Мое стремление к универсальности вызвано не заботой о заказчике,
> а скорее заботой о себе. Зачем мне разрабатывать сходные
> решения для решения сходной задачи над другим набором данных.
> Ведь большинство программ, которые разрабатываются используют
> одни и те же решения в разном сочетании и вложенности. Так
> почему мы не облегчить себе работу и продумать структуру
> таких решений таким образом, чтобы все эти решения не только
> сочателись между собой, но и работали над произвольным набором
> типов. Ведь стремление к reusability не является чем то
> плохим.

Я ничего против более обобщённых решений не имею, поскольку в обобщении основная сила программирования. Но, как показывает моя практика, недостаточно продуманное обобщённое решение доставляет несоизмеримо больше геморроя, чем конкретное решение. А продуманное обобщённое решение, помимо решения конкретной предметной задачи, требует так же тщательного анализа всего класса подобных задач, что может вылиться в гораздо бОльшие сроки разработки с естественно возникающим вопросом - окупятся ли эти вложения в будущем.

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

← →
Alkid © (2009-05-19 15:05) [143]

P.S. У Ашманова хорошо написано про универсальные решения.

← →
test © (2009-05-19 15:06) [144]

Mystic © (19.05.09 14:16) [135]
А как же Дельфи написан на Дельфи? Предел того что можно сделать?

Игорь Шевченко © (19.05.09 14:48) [139]
А как же ОС и языки программирования? Или их подарил человечеству БОГ, так чисто поржать?

← →
Игорь Шевченко © (2009-05-19 15:07) [145]

oxffff © (19.05.09 14:53) [140]

> GOF паттерны, итераторы, MulticastDelegate(в противовес
> procedure of object) являются универсальными решениями.
> Особенно MulticastDelegate какая мелочь этот связный список,
>
> но какой качественный отрыв.

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

Все универсальные решения надо документировать, без документации они практической ценности не несут, описывать условия применимости, описывать условия неприменимости, то есть, выполнять массу работы заранее, снижать понятность кода решения конкретной задачи, возможно, снижать производительность - а зачем ?

Я прошел через попытки универсализировать все и вся лет 15 назад. Надеюсь, благополучно.

← →
oxffff © (2009-05-19 15:08) [146]

> Mystic © (19.05.09 14:57) [141]
> > oxffff © (19.05.09 14:33) [136]

Есть большая разница между if и виртуальным методом.
В том что для If вам нужно изменять код универсального метода, а при использовании виртуального метода(контракта) вам этого делать не нужно.
Это проблема называется поверхностная универсализация.
Заключается в том, что сам универсальный алгоритм строится на вызове обобщенных методов которые работают для некоторого подмножества всего множества типов. Однако ничего не мешает обошить все множество типов в контракт и универсального алгоритму работать с контрактом. А типам реализовывать такой контракт и такой набор контрактов. И т.к далее ьолее верхние уровни. Да я не говорю что это просто. Сложно приходится затратить время на такое обобщение. Но это работает.

← →
Alkid © (2009-05-19 15:12) [147]

> oxffff © (19.05.09 14:53) [140]
> GOF паттерны,

Оффтопик (от оффтопика), но я придерживаюсь мнения, что паттерны есть проявление несовершенства языка.

← →
Eraser © (2009-05-19 15:15) [148]

> [146] oxffff © (19.05.09 15:08)

> Заключается в том, что сам универсальный алгоритм строится
> на вызове обобщенных методов которые работают для некоторого
> подмножества всего множества типов. Однако ничего не мешает
> обошить все множество типов в контракт и универсального
> алгоритму работать с контрактом. А типам реализовывать такой
> контракт и такой набор контрактов. И т.к далее ьолее верхние
> уровни. Да я не говорю что это просто. Сложно приходится
> затратить время на такое обобщение. Но это работает.

пусть ИИ этим занимается, когда будет изобретен )

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

> Игорь Шевченко © (19.05.09 15:07) [145]
> oxffff © (19.05.09 14:53) [140]
>
>
> > GOF паттерны, итераторы, MulticastDelegate(в противовес
>
> > procedure of object) являются универсальными решениями.
>
> > Особенно MulticastDelegate какая мелочь этот связный список,
>
> >
> > но какой качественный отрыв.
>
>
> Все хорошо в меру. Я стараюсь писать проще, даже если усложненное
> возможно когда-нибудь при каких-нибудь условиях может быть
> использовано. Тому есть несколько причин, первая - зачем
> писать больше сейчас, неизвестно, потребуется ли это в будущем,
> а вторая - зачем засорять мозги тому, кто будет работать
> с кодом после меня.

Зачем?

Давайте рассмотрим язык программирования Delphi. Мы же пишем вставлять одни конструкции в другие, передавать конструкциям разные типы вообщем сочетать их по разному. Такого рода решения для меня представляют ценность. Пусть и с потерей производительности.
А LINQ - это тоже же стремление к универсальности над контейнерами.
Разве это не примеры удачное решений?

> Alkid © (19.05.09 15:12) [147]
>
> > oxffff © (19.05.09 14:53) [140]
> > GOF паттерны,
>
> Оффтопик (от оффтопика), но я придерживаюсь мнения, что
> паттерны есть проявление несовершенства языка.

А как же например паттерн Посетитель?
Приведи пример языковой конструкции, которой нет в языках

> Тут вы пытаетесь опровергать возможность написания языка
> на самом себе. По вашему любой другой язык будет хуже предыдущего.

Нет, не хуже. Я не про языки программирования говорю.

Например, вы взялись за разработку системы бухгалтерского учета. Через некоторое время вы приносите заказчику компилятор и говорите, что с помощью этого языка программирования можно написать любую систему бухгалтерского учета. И еще много чего кроме этого. Так что это более универсально.

> oxffff © (19.05.09 15:20) [150]
> А как же например паттерн Посетитель?
> Приведи пример языковой конструкции, которой нет в языках

Multipe-dispatch.
Реализован в CLOS.

← →
Noctis (2009-05-19 15:25) [153]

Alkid © (19.05.09 15:12) [147]

>Оффтопик (от оффтопика), но я придерживаюсь мнения, что паттерны есть проявление несовершенства языка.

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

> А как же Дельфи написан на Дельфи? Предел того что можно
> сделать?

По универсальности предел. Если R[X] это множество задач, которые можно решить при помощи некоторой программы X, то если при помощи программы X написать программу Y, то R[Y] будет подмножеством R[X].

> Игорь Шевченко © (19.05.09 15:07) [145]
> oxffff © (19.05.09 14:53) [140]
> Все хорошо в меру

Так и я тоже придерживаюсь такоей точки зрения.

> Alkid © (19.05.09 15:24) [152]
>
> > oxffff © (19.05.09 15:20) [150]
> > А как же например паттерн Посетитель?
> > Приведи пример языковой конструкции, которой нет в языках
>
> Multipe-dispatch.
> Реализован в CLOS.

Да ты прав.

>
> Alkid © (19.05.09 15:24) [152]
>
> > oxffff © (19.05.09 15:20) [150]
> > А как же например паттерн Посетитель?
> > Приведи пример языковой конструкции, которой нет в языках
>
> Multipe-dispatch.
> Реализован в CLOS.

А шаблон Мост? :)

P.S. А oxffff то не знает.

> А как быть если продукт может являться надможеством другого
> продукта?

Это как-то опровергает то, что я написал?

Как перестать программировать на С++ в Паскаль стиле? Найти похожие ветки