Здравствуйте, Ziaw, Вы писали:
Z>Я разве называл что-то ерундой? Ты уверен, что программист не знающий о существовании паттерна бридж будет обречен на умножение числа вариантов?
Не знающий названия паттерна или сути паттерна? Если сути, то будет обречен, если названия, то код это писать никак не мешает.
Z>Главный бенефит в том, что добавив суффикс Bridge к классу он ясно дал понять его назначение без огромных UML диаграмм с кучей комментариев.
Ужас какой. Ни разу не добавлял суффиксы паттернов к классам и не видел, чтобы этого делали другие. Зачем этот мусор нужен в коде? Это какая-то реинкарнация венгерской нотации получается.
Z>Ты серьезно считаешь, что банда четырех что-то изобрела? Они сделали классификацию часто применяемых приемов программирования на некоторых языках.
Где я говорил о банде четырех и классификации? Речь шла о одном из приемов борьбы со сложностью. Главное в приеме суть, а не кто его первый назвал и классифицировал. Это дело десятое.
Здравствуйте, gandjustas, Вы писали:
Q>>Нет. Паттерн Стратегия выглядит точно так же (вплоть до UML-диаграммы), как и паттерн Состояние. И тем не менее, это разные паттерны. G>Вообще-то нет. "Состояние" обычно имеет ссылку на объект, который обладает этим состоянием, а стратегия — нет.
Состояние это частный случай стратегии. Собственно я не случайно перечислил всего лишь четыре паттерна, т.к. остальные паттерны это в лучшем случае производное от них, а в худшем и вовсе антипаттерны, как декоратор к примеру.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Undying, Вы писали:
U>>Вот мы разрабатываем пользовательский интерфейс приложения. Где мы здесь используем математику? S>Вообще-то — много где. Например, у нас есть статистические данные про то, какие сценарии пользователи используют чаще, какие — реже. S>Например, при проектировании интерфейса мы используем математику конечных автоматов для описания поведения UI.
U>>Вот мы думаем какая структура данных хорошо подходит для решения задачи. Где мы здесь используем математику? S>А тут мы вообще ничего, кроме математики, не используем. У Кнута, к примеру, очень подробно расписан матаппарат, который позволяет получить оценки производительности для тех или иных алгоритмов. А применимость алгоритмов напрямую зависит от использованных структур данных. А вы, простите, как-то по-другому что ли это делаете?
U>>Для того, чтобы найти решение нужно думать. Математика может лишь предоставить ряд приемов, которые в некоторых случаях упрощают процесс мышления, но сам процесс мышления и соответственно поиска решения много сложнее, чем математика.
S>У вас, мне кажется, какое-то неверное понимание того, что такое математика. Весь "ряд приёмов", предоставляемый математикой — это формализация. Как только вы что-то формализовали и построили абстрактную модель — вы получили математику.
S>Просто та математика, которую преподают на первых двух курсах, выглядит какой-то отдалённой от практики из-за отсутствия внятных объяснений этого перехода. Ну, к примеру, все понимают, что Быстрое Преобразование Фурье построено на алгебре полей Галуа. А вот на чём построена модель наследования в C++, понимают не все — потому что нет такого курса "математические основы ООП". Это не значит, что нет математических основ ООП.
Просветите, что такое "алгебра полей Галуа", и как она связана с быстрым преобразованием Фурье.
А таже что за таинственные "математические основы ООП".
Здравствуйте, Undying, Вы писали:
U>При разбиении задачи на сущности никакой математикой я не пользуюсь. Это задача решаемая образным мышлением. Например, в задаче есть сущность водитель. Ты надеюсь не будешь утверждать, что это математическая сущность?
В задаче — нет. Но в формализации задачи водитель теряет все лишние свойства. В зависимости от того, что за задача решается, водитель становится математическим объектом, обладающим некоторыми свойствами. А дальше начинается математика в полный рост. Рассуждения типа "водитель — человек, у человека есть фамилия, значит у водителя есть фамилия" — в чистом виде математика. В программе это выражается, например, как class Driver: IPerson.
U>Т.е. опять же речь о математике как инструменте, который позволяет в ряде случаев оценить производительность.
Речь идёт о том, что вы используете ровно этот инструмент, чтобы выбрать между списком, массивом, и деревом.
U>Мышление в общем и программирование в частности происходит в рамках образной модели. А математика лишь инструмент, который при необходимости позволяет образную модель упростить до абстрактной.
В программе не остаётся никакой образной модели. Остаётся только абстрактная модель.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали:
U>Это неверно. Математика это наука о формальных преобразованиях над абстракциями. Преобразованиями реальных сущностей в абстрактные математика не занимается, т.к. формальных методов для этого не существует. Этим занимаются прикладные науки — физика, химия, программирование и т.д. А математика для прикладных наук лишь одно из средств для работы с полученными абстракциями.
Совершенно верно. Вы выполняете преобразование реальных сущностей в абстрактные в рамках прикладного программирования. А в дальнейшем работаете исключительно математикой. Просто вы не всегда это осознаёте.
Осознание математичности программирования помогает писать более хорошие программы. Например, понимание отличий stateless от stateful на математическом, а не образном уровне, помогает делать осознанный выбор между ними и избегать "гибридных" реализаций, обладающих недостатками обоих вариантов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали:
U>Паттерн бридж позволяет заменить умножение числа вариантов на сложение числа вариантов. Ты серьезно считаешь, что это ерунда, нужная лишь для того, чтобы "программисты могли объяснять свои решения"?
Это не ерунда. Это просто слабость языков программирования, требующая объяснять паттерн отдельно от самого языка.
На всякий случай напомню, что, к примеру, наследование и перегрузка виртуальных методов с VMT прекрасно реализуется как паттерн на языке без поддержки наследования (скажем, C). Но в современных ОО-языках такого паттерна не нужно, т.к. он уже встроен на уровне синтаксиса и компилятора.
Это не значит, что паттерн "перегрузка метода" — это ерунда. Как раз наоборот.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали:
U>Формально, да, язык программирования можно считать разновидностью математического языка. Но практически это не имеет смысла, т.к. математический формализм в данном случае не дает никаких дополнительных возможностей и лишь усложняет понимание. Поэтому 99% программистов сильно удивятся, если им сказать, что они программируют на математических языках.
В этом, в частности, и есть проблема. К примеру, многие гражданские инженеры понимают, что они пользуются математикой. Поэтому мосты, скажем, падают редко. А большинство программистов — не понимают, что пользуются математикой. Поэтому их программы падают часто
Это не означает, что в самом программировании мало математики. Это означает, что то, чем занимаются программисты, зачастую похоже на настояшее программирование только издалека.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>На всякий случай напомню, что, к примеру, наследование и перегрузка виртуальных методов с VMT прекрасно реализуется как паттерн на языке без поддержки наследования (скажем, C).
Это не ерунда, это антипаттерн. Наследование от реализации бывает оправданным крайне редко.
S>Но в современных ОО-языках такого паттерна не нужно, т.к. он уже встроен на уровне синтаксиса и компилятора. S>Это не значит, что паттерн "перегрузка метода" — это ерунда. Как раз наоборот.
От встроенности в язык прием никуда не исчезает. Точно также при написании программы нужно решать упростит ли в данном случае использование перегрузки метода решение. А уж сколько строк займет реализация перегрузки это чисто технический вопрос, от которого сам прием никуда не девается.
Здравствуйте, Sinclair, Вы писали:
S>В этом, в частности, и есть проблема. К примеру, многие гражданские инженеры понимают, что они пользуются математикой. Поэтому мосты, скажем, падают редко. А большинство программистов — не понимают, что пользуются математикой. Поэтому их программы падают часто S>Это не означает, что в самом программировании мало математики. Это означает, что то, чем занимаются программисты, зачастую похоже на настояшее программирование только издалека.
Доказательства и примеры будут? Или только аналогии?
Здравствуйте, Sinclair, Вы писали:
S>В задаче — нет. Но в формализации задачи водитель теряет все лишние свойства. В зависимости от того, что за задача решается, водитель становится математическим объектом, обладающим некоторыми свойствами. А дальше начинается математика в полный рост. Рассуждения типа "водитель — человек, у человека есть фамилия, значит у водителя есть фамилия" — в чистом виде математика. В программе это выражается, например, как class Driver: IPerson.
Что нам дает то, что запись class Driver : IPerson мы начали воспринимать как математическую сущность? Пару примитивных и интуитивно понятных без всякой математики преобразований? Или что-то по существенней? Если второе, то, пожалуйста, примеры.
U>>Т.е. опять же речь о математике как инструменте, который позволяет в ряде случаев оценить производительность. S>Речь идёт о том, что вы используете ровно этот инструмент, чтобы выбрать между списком, массивом, и деревом.
Например, если есть фиксированная последовательность, то я использую массив, список и дерево я даже не рассматриваю. Где я здесь использовал математику для выбора?
И вообще можно к более сложным примерам перейти? Т.к. если и удастся доказать, что на простых примерах математика формально применима, то толку с этого? Простые случай и без всякой математики прекрасно решаются.
S>В программе не остаётся никакой образной модели. Остаётся только абстрактная модель.
И что нам дает? Все равно для того, чтобы понять что делает программа и правильно ли это делает нужно выполнить обратное преобразование из абстрактной модели в образную.
Здравствуйте, Undying, Вы писали:
Z>>Я разве называл что-то ерундой? Ты уверен, что программист не знающий о существовании паттерна бридж будет обречен на умножение числа вариантов?
U>Не знающий названия паттерна или сути паттерна? Если сути, то будет обречен, если названия, то код это писать никак не мешает.
Названия.
Z>>Главный бенефит в том, что добавив суффикс Bridge к классу он ясно дал понять его назначение без огромных UML диаграмм с кучей комментариев.
U>Ужас какой. Ни разу не добавлял суффиксы паттернов к классам и не видел, чтобы этого делали другие. Зачем этот мусор нужен в коде? Это какая-то реинкарнация венгерской нотации получается.
Зависит от паттерна, с бриджем я дал маху конечно, но суффиксы Proxy, Visitor, Factory, Adapter общеупотребимы и не являются венгерской нотацией, это самое четкое описание их функционала.
U>Где я говорил о банде четырех и классификации? Речь шла о одном из приемов борьбы со сложностью. Главное в приеме суть, а не кто его первый назвал и классифицировал. Это дело десятое.
Ну так это частные приемы в частных языках. К программированию вообще они имеют мало отношения. На универсальную нотацию не тянут.
Здравствуйте, Undying, Вы писали:
U>Это не ерунда, это антипаттерн. Наследование от реализации бывает оправданным крайне редко.
Да без проблем. Не хотите от реализации — можно от интерфейса. Один хрен, в язык C это не встроено. Что не мешает реализовать это в виде паттерна. См. например C-реализации COM.
U>От встроенности в язык прием никуда не исчезает. Точно также при написании программы нужно решать упростит ли в данном случае использование перегрузки метода решение. А уж сколько строк займет реализация перегрузки это чисто технический вопрос, от которого сам прием никуда не девается.
Мы говорим не о деваемости приёма, а о его математической формализации. В компиляторе наследование интерфейса имеет вполне строгую формализацию, благодаря чему компилятор может делать забавные математические трюки — вроде инлайнинга вызовов там, где он может доказать единственность реализации.
Без математики подобные трансформации делать нельзя. Из-за этого возникает понятие abstraction penalty и прочие предрассудки относительно дизайнерских решений, выраженных в "образных" понятиях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали:
U>Что нам дает то, что запись class Driver : IPerson мы начали воспринимать как математическую сущность? Пару примитивных и интуитивно понятных без всякой математики преобразований?
Важное заблуждение выделено. Точно также можно сказать, что 246*50 можно посчитать и безо всякой математики, путём интуитивно понятных действий.
U>Например, если есть фиксированная последовательность, то я использую массив, список и дерево я даже не рассматриваю. Где я здесь использовал математику для выбора?
Вы — не использовали. А зря. Одной фиксированности последовательности недостаточно для того, чтобы выбрать массив. Нужно ещё учитывать то, какие операции будут выполняться. К примеру, если часто выполняется поиск в этой коллекции, то дерево всё ещё может оказаться эффективнее массива.
Поэтому математика рулит, а интуиция — нет.
U>И вообще можно к более сложным примерам перейти? Т.к. если и удастся доказать, что на простых примерах математика формально применима, то толку с этого? Простые случай и без всякой математики прекрасно решаются.
Можно — по индукции. Но вы хотите "интуитивного" доказательства, а это будет "математическое".
U>И что нам дает? Все равно для того, чтобы понять что делает программа и правильно ли это делает нужно выполнить обратное преобразование из абстрактной модели в образную.
Это нам даёт возможность выполнять рассуждения, не вдаваясь в то, что именно делает программа. Например, можно доказать некоторые вещи — типа type safety, проверяемой верификатором в дотнете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Undying, Вы писали:
U>Здравствуйте, Sinclair, Вы писали:
S>>На всякий случай напомню, что, к примеру, наследование и перегрузка виртуальных методов с VMT прекрасно реализуется как паттерн на языке без поддержки наследования (скажем, C).
U>Это не ерунда, это антипаттерн. Наследование от реализации бывает оправданным крайне редко.
Уточню, что в С нет вообще никакого наследования, и в частности, интерфейсов там тоже нет. Соответственно создание полиморфного поведения объекта без ветвлений (if/switch) требует ручной эмуляции VMT.
S>>Но в современных ОО-языках такого паттерна не нужно, т.к. он уже встроен на уровне синтаксиса и компилятора. S>>Это не значит, что паттерн "перегрузка метода" — это ерунда. Как раз наоборот.
U>От встроенности в язык прием никуда не исчезает. Точно также при написании программы нужно решать упростит ли в данном случае использование перегрузки метода решение. А уж сколько строк займет реализация перегрузки это чисто технический вопрос, от которого сам прием никуда не девается.
Прием не девается, девается частота его использования. Программируя на C#, ты решаешь что нужен интерфейс и его реализация. Он в языке есть, считай что бесплатен (дешевле реализация разве что в F# — Object expressions). А в C — придется создавать тип для хранения указателей на функции, typedef-ы для функций (с явной передачей this), писать код по заполнению VMT для каждой "реализации", беспокоиться о том что бы передавать нужную VMT вместе с соответствующими данными, если структура данных не предполагает хранения ссылки на VMT. Подумаешь, повзвешиваешь, и окажется что средства зачастую убивают цель.
Здравствуйте, Undying, Вы писали:
U>Доказательства и примеры будут? Или только аналогии?
Что именно вы хотите чтобы я доказал? Неформально определённый тезис? Сие невозможно по определению.
Какой пример вас убедит?
Вот, скажем, протокол HTTP. Многие программисты знают о математике внутри этого протокола — скажем, что GET считается безопасным методом, а DELETE — идемпотентным.
А те, которые не знают, нарушают безопасность GET, и получают неожиданные результаты при запуске приложения в эксплуатацию. Или, наоборот, используют POST для навигации, и получают корректные, но неэффективные реализации на ровном месте. Почему? Да потому, что впереди интуиции должна идти математика. Только после того, как некоторый приём или его семейство разобрано по запчастям, и освоены ограничения применимости, можно положить этот приём в моторную память и пользоваться им "безо всякой математики".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Chrome, Вы писали: C>Вопрос в том, стоит ли близость к математической нотации рассматривать как преимущество синтаксиса языка программирования.
Разумеется. Об этом свидетельствует успех Фортрана.
Здравствуйте, Sinclair, Вы писали:
S>Мы говорим не о деваемости приёма, а о его математической формализации. В компиляторе наследование интерфейса имеет вполне строгую формализацию, благодаря чему компилятор может делать забавные математические трюки — вроде инлайнинга вызовов там, где он может доказать единственность реализации. S>Без математики подобные трансформации делать нельзя. Из-за этого возникает понятие abstraction penalty и прочие предрассудки относительно дизайнерских решений, выраженных в "образных" понятиях.
Напоминаю, топик-стартер говорил о синтаксисе языка программирования. Т.е. речь идет о преобразовании условия задачи в программный код и применимости математики к этому преобразованию. Зачем ты перескочил на преобразовании программного кода в машинный код? Мы это не обсуждаем.
Здравствуйте, Sinclair, Вы писали:
S>Вот, скажем, протокол HTTP. Многие программисты знают о математике внутри этого протокола — скажем, что GET считается безопасным методом, а DELETE — идемпотентным.
Что-то ты сам путаешься в терминах:
Согласно стандарту HTTP, запросы типа GET считаются идемпотентными — многократное повторение одного и того же запроса GET должно приводить к одинаковым результатам (при условии, что сам ресурс не изменился за время между запросами). Это позволяет кэшировать ответы на запросы GET.
И причем здесь математика? Обычный хак, т.е. решение корректное использование которого неочевидно и возможно только после прочтения документации. Прочтение документации уже стало математическим актом?
Здравствуйте, Sinclair, Вы писали:
S>Вот, скажем, протокол HTTP. Многие программисты знают о математике внутри этого протокола — скажем, что GET считается безопасным методом, а DELETE — идемпотентным.
S>А те, которые не знают, нарушают безопасность GET, и получают неожиданные результаты при запуске приложения в эксплуатацию. Или, наоборот, используют POST для навигации, и получают корректные, но неэффективные реализации на ровном месте. Почему? Да потому, что впереди интуиции должна идти математика. Только после того, как некоторый приём или его семейство разобрано по запчастям, и освоены ограничения применимости, можно положить этот приём в моторную память и пользоваться им "безо всякой математики".
Кстати, за что не люблю математику это за ее способность делать простое сложным. Для объяснения механизма тут достаточно одной фразы: при DELETE и POST происходит сброс кэшей, при GET — нет. Никакой математики и заумных терминов тут даром не надо.
