Здравствуйте, gandjustas, Вы писали:
R3>>То, что ими пользуются. G>Всеми сразу в одной программе? Снова не верю.
В разных конечно.
G>>>Физически это невозможно. R3>>Если есть автоматика, то возможно. G>Какая автоматика? Что может избавить от описания объектов?
Пример: есть класс Person { int id; string Name; } и есть класс Auto { string Name; int idPerson }.
Языки программирования предоставляют возможность работать со sting-ами. Ты не занимаешься "обучением" sting-ов для каждого класса отдельно. Но ты будешь заниматься "обучением" класса Auto, чтобы он начал понимать, как работать с idPerson. Вот тут бы автоматика помогла бы.
R3>>На примере это выглядит так: R3>>Есть какой-нибудь мессенджер, который предоставляет пользователям обмен текстовыми сообщениями. Возникает необходимость в функциональности голосовой связи. Сейчас либо пишут новый мессенджер (повторно реализуя функционал обмена текстовыми сообщениями), либо присобачивают новую функциональность к существующему так, что лучше они бы этого не делали. Потому что голосовая связь — это тоже сообщения, только другого типа, но она также как и текстовые сообщения должна передавать некоторую информацию в "основную базу" мессенджера, например, время отправки сообщения и т.п. G>Есть скайп, Lync и другие сервисы. Писать не надо.
Ну, и разве это не дублирование функционала?
G> Кроме того ты опять путаешь объекты и функции. Я говорю про описание объектов, ты говоришь зачем-то о функциях передачи сообщений и голоса. Если пытаться декомпозировать задачу передачи сообщений, то мы совсем уйдем от "реального мира" и бизнес-задач.
Сори, возможно, я в чём-то не последователен: у меня некоторые идеи ещё не обдуманы, а в обдуманных идеях я забегаю вперёд.
Я не путаю объекты и функции. Я их — объединяю.
Если подитожить то, что я хочу сказать:
Если есть объект "принтер", то у него есть функция "печать". Соответственно, если есть объект "файл", то для того, чтобы научить его функции "печать", не надо создавать объект "принтер" — он уже есть. Но вот как именно научить объект "файл" функции "печать" — это вопрос. И мне не нравится, как это делается сейчас.
Здравствуйте, Real 3L0, Вы писали:
R3>Пример: есть класс Person { int id; string Name; } и есть класс Auto { string Name; int idPerson }. R3>Языки программирования предоставляют возможность работать со sting-ами. Ты не занимаешься "обучением" sting-ов для каждого класса отдельно. Но ты будешь заниматься "обучением" класса Auto, чтобы он начал понимать, как работать с idPerson. Вот тут бы автоматика помогла бы.
А не надо делать idPerson, должна быть ссылка. А пусть система сама разбирается как эту ссылку мапить на хранилище. Ты сам пытаешься работать со слишком низким уровнем и тебе "автоматики" не хватает.
R3>>>На примере это выглядит так: R3>>>Есть какой-нибудь мессенджер, который предоставляет пользователям обмен текстовыми сообщениями. Возникает необходимость в функциональности голосовой связи. Сейчас либо пишут новый мессенджер (повторно реализуя функционал обмена текстовыми сообщениями), либо присобачивают новую функциональность к существующему так, что лучше они бы этого не делали. Потому что голосовая связь — это тоже сообщения, только другого типа, но она также как и текстовые сообщения должна передавать некоторую информацию в "основную базу" мессенджера, например, время отправки сообщения и т.п. G>>Есть скайп, Lync и другие сервисы. Писать не надо. R3>Ну, и разве это не дублирование функционала?
Это тут совершенно не при чем. При чем то, что не надо такой функционал писать.
G>> Кроме того ты опять путаешь объекты и функции. Я говорю про описание объектов, ты говоришь зачем-то о функциях передачи сообщений и голоса. Если пытаться декомпозировать задачу передачи сообщений, то мы совсем уйдем от "реального мира" и бизнес-задач.
R3>Сори, возможно, я в чём-то не последователен: у меня некоторые идеи ещё не обдуманы, а в обдуманных идеях я забегаю вперёд. R3>Я не путаю объекты и функции. Я их — объединяю.
Выделенное — очень зря. Функции объективны, а какие объекты — зависит от задачи и от взгляда человека на эту задачу (предельно субъективны).
R3>Если подитожить то, что я хочу сказать: R3>Если есть объект "принтер", то у него есть функция "печать". Соответственно, если есть объект "файл", то для того, чтобы научить его функции "печать", не надо создавать объект "принтер" — он уже есть. Но вот как именно научить объект "файл" функции "печать" — это вопрос. И мне не нравится, как это делается сейчас.
Нету такого объекта, потому что ты банально не сможешь непротиворечиво его описать. Когда начнешь описывать этот объект выродится у тебя в одну функцию печати. И эта функция принимает на вход некоторый объект, который можно печатать. Вот и вся связь. После этого тебе надо согласовать интерфейс для "объекта, который можно печатать" и научить "файл" поддерживать этот интерфейс.
Здравствуйте, gandjustas, Вы писали:
R3>>Языки программирования предоставляют возможность работать со sting-ами. Ты не занимаешься "обучением" sting-ов для каждого класса отдельно. Но ты будешь заниматься "обучением" класса Auto, чтобы он начал понимать, как работать с idPerson. Вот тут бы автоматика помогла бы. G>А не надо делать idPerson, должна быть ссылка. А пусть система сама разбирается как эту ссылку мапить на хранилище. Ты сам пытаешься работать со слишком низким уровнем и тебе "автоматики" не хватает.
Ну пусть ссылка. Да, пусть система сама разбирается. Но таких систем, к сожалению, нет.
G>>>Есть скайп, Lync и другие сервисы. Писать не надо. R3>>Ну, и разве это не дублирование функционала? G>Это тут совершенно не при чем. При чем то, что не надо такой функционал писать.
Основная проблема не в существующем функционале, а том, что этот функционал никто не может просто использовать отдельно от продукта, в котором он реализован.
R3>>Сори, возможно, я в чём-то не последователен: у меня некоторые идеи ещё не обдуманы, а в обдуманных идеях я забегаю вперёд. R3>>Я не путаю объекты и функции. Я их — объединяю. G>Выделенное — очень зря. Функции объективны, а какие объекты — зависит от задачи и от взгляда человека на эту задачу (предельно субъективны).
Не зная объект, ты не сможешь сказать, применима ли к нему определённая функция.
R3>>Если подитожить то, что я хочу сказать: R3>>Если есть объект "принтер", то у него есть функция "печать". Соответственно, если есть объект "файл", то для того, чтобы научить его функции "печать", не надо создавать объект "принтер" — он уже есть. Но вот как именно научить объект "файл" функции "печать" — это вопрос. И мне не нравится, как это делается сейчас.
G>Нету такого объекта, потому что ты банально не сможешь непротиворечиво его описать. Когда начнешь описывать этот объект выродится у тебя в одну функцию печати.
Эээ, я что-то не понял. В первом предложении ты написал о невозможности, а во втором — привёл пример как можно.
Объект может состоять не только из одной функции — от может содержать вызовы других функций. Например, если это "принтер", то он может содержать вызов функции "местоположение" (по GPS), например для того, чтобы разрешать пользоваться функцией "печать" только тем, кто находится недалеко от этого принтера.
G> И эта функция принимает на вход некоторый объект, который можно печатать. Вот и вся связь. После этого тебе надо согласовать интерфейс для "объекта, который можно печатать" и научить "файл" поддерживать этот интерфейс.
Да-да, как-то так. Но этого мало. Надо чтобы было так, чтобы объекты сами могли выдавать другим объектам, что с ними можно сделать. Без обучения.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
R3>>>Языки программирования предоставляют возможность работать со sting-ами. Ты не занимаешься "обучением" sting-ов для каждого класса отдельно. Но ты будешь заниматься "обучением" класса Auto, чтобы он начал понимать, как работать с idPerson. Вот тут бы автоматика помогла бы. G>>А не надо делать idPerson, должна быть ссылка. А пусть система сама разбирается как эту ссылку мапить на хранилище. Ты сам пытаешься работать со слишком низким уровнем и тебе "автоматики" не хватает.
R3>Ну пусть ссылка. Да, пусть система сама разбирается. Но таких систем, к сожалению, нет.
Как это нет? Я вот пользую Entity Framework, он вполне умеет понимать ссылки и генерить из них схему БД.
Есть Orchard CMS, который тоже понимает ссылки.
Более высокоуровневые системы: 1C, SharePoint, Dynamics, в них также ты описываешь ссылки между сущностями, а он сам занимается раскладываением их в хранилище. Вот только если ты будешь путать ссылки и функции, то ниче хорошего у тебя не выйдет изначально.
G>>>>Есть скайп, Lync и другие сервисы. Писать не надо. R3>>>Ну, и разве это не дублирование функционала? G>>Это тут совершенно не при чем. При чем то, что не надо такой функционал писать.
R3>Основная проблема не в существующем функционале, а том, что этот функционал никто не может просто использовать отдельно от продукта, в котором он реализован.
не понял мысли. Ты используешь некоторую платформу, будь это просто dll, подключаемая к проекту или готовое приложение.
R3>>>Сори, возможно, я в чём-то не последователен: у меня некоторые идеи ещё не обдуманы, а в обдуманных идеях я забегаю вперёд. R3>>>Я не путаю объекты и функции. Я их — объединяю. G>>Выделенное — очень зря. Функции объективны, а какие объекты — зависит от задачи и от взгляда человека на эту задачу (предельно субъективны). R3>Не зная объект, ты не сможешь сказать, применима ли к нему определённая функция.
И что? Тебе ведь не нужны объекты сами по себе, тебе (и пользователю) нужны функции. А объекты обеспечивают возможность выполнения функций.
R3>>>Если подитожить то, что я хочу сказать: R3>>>Если есть объект "принтер", то у него есть функция "печать". Соответственно, если есть объект "файл", то для того, чтобы научить его функции "печать", не надо создавать объект "принтер" — он уже есть. Но вот как именно научить объект "файл" функции "печать" — это вопрос. И мне не нравится, как это делается сейчас.
G>>Нету такого объекта, потому что ты банально не сможешь непротиворечиво его описать. Когда начнешь описывать этот объект выродится у тебя в одну функцию печати.
R3>Эээ, я что-то не понял. В первом предложении ты написал о невозможности, а во втором — привёл пример как можно.
Еще раз. Я сказал что ты не сможешь описать объект, и я описал функцию. Ты их смешиваешь — в этом проблема.
R3>Объект может состоять не только из одной функции — от может содержать вызовы других функций.
Объект не может состоять из функций. Пока этого не поймешь дальше не продвинешься.
G>Функции объективны, а какие объекты — зависит от задачи и от взгляда человека на эту задачу (предельно субъективны).
функции настолько же субъективны, насколько и объекты
можно
печатать на принтере,
выводить на принтер,
передавать на принтер,
отправить на принтер,
взаимодействовать с принтером,
вывести в печатном виде,
получить твердую копию,
преобразовать в бумажный вид
и еще 137 видов функций(действий)
зы
это есть опасное заблуждение, культивируемое на рсдн-е и в рядах фя-шников, что функция более объективна, чем объект.
в реальности это не так, и не важно на чем строить модели: на сущностях(объектах) или на действиях(функциях), и то и другое субъективные понятия, которые легко могут меняться от того или иного взгляда на решаемую проблему
G>Объект не может состоять из функций. Пока этого не поймешь дальше не продвинешься.
не путай человека.
функция уж точно не может состоять из функций (не уж тем более из объектов), а их может только вызывать(или оперировать/использовать, если про объекты)
зы
а вообще все эти утверждения: может/не может бессмысленны, пока не зафиксирована задача(цель) и термины
Здравствуйте, DarkGray, Вы писали:
G>>Функции объективны, а какие объекты — зависит от задачи и от взгляда человека на эту задачу (предельно субъективны).
DG>функции настолько же субъективны, насколько и объекты
DG>можно DG>печатать на принтере, DG>выводить на принтер, DG>передавать на принтер, DG>отправить на принтер, DG>взаимодействовать с принтером, DG>вывести в печатном виде, DG>получить твердую копию, DG>преобразовать в бумажный вид DG>и еще 137 видов функций(действий)
По сути это все одно и тоже (синонимы). Важно не название, а суть.
DG>зы DG>это есть опасное заблуждение, культивируемое на рсдн-е и в рядах фя-шников, что функция более объективна, чем объект.
ФЯ тут не при чем. Посмотрите люблю бизнес-постановку задачи. Людям нужны функции, приходится долго анализировать постановку что понять какие там объекты нужны.
А вот программистам проще наоборот, они сначала выдумывают объекты (классы), а потом прилепляют к ним функции.
DG>в реальности это не так, и не важно на чем строить модели: на сущностях(объектах) или на действиях(функциях), и то и другое субъективные понятия, которые легко могут меняться от того или иного взгляда на решаемую проблему
Про реальность я написал выше.
Здравствуйте, lseder, Вы писали:
L>>Марти Фаулер. Архитектура корпоративных программных приложений. L>спасибо, посмотрю. но моя задача по размерам пока не тянет на корпоративные размеры, L>хотя общие принципы разработки знать необходимо.
L> Уже несколько месяцев бьюсь над структурой конструирования мета-конструкций.
Там таки и описаны мета-конструкции с самых верхних уровней. Т.е. абстрагироваться не от текста,
а от визуального представления. Хотя вашу задачу я так и не понял.
Динамически конструирумое дерево. Я так понимаю, это дерево разбора синаксического анализатора+
динамически дополняемое лексемами. Знакомо?
L>>По моему наиболее близко на сегодняшний день, к сабжу. L>>Есть еще книги, "Порождающее программирование". "Фабрики разработки программ". И много много всего по паттернам, UML. L>"Порождающее программирование" наиболее близко к теме, но книгу чарнецки в Украине купить невозможно.
Просто она устарела, я брал лет 5 назад, в Украине в провинции
L>>>- Реализовать хотелось бы на javascript + sql (web kit html5), так как интересно сделать L>>>конструктор на чистом браузере (для тачскринов). L>>А зачем? L>для iPad-а и других тачскринов.
Таки да, объять необъятное
Здравствуйте, gandjustas, Вы писали:
R3>>Ну пусть ссылка. Да, пусть система сама разбирается. Но таких систем, к сожалению, нет. G>Как это нет? Я вот пользую Entity Framework, он вполне умеет понимать ссылки и генерить из них схему БД. G>Есть Orchard CMS, который тоже понимает ссылки. G>Более высокоуровневые системы: 1C, SharePoint, Dynamics, в них также ты описываешь ссылки между сущностями, а он сам занимается раскладываением их в хранилище. Вот только если ты будешь путать ссылки и функции, то ниче хорошего у тебя не выйдет изначально.
Ну тогда я ещё раз прошу тебя описать, как ляжет пример с принтером в эти системы?
R3>>Основная проблема не в существующем функционале, а том, что этот функционал никто не может просто использовать отдельно от продукта, в котором он реализован. G>не понял мысли. Ты используешь некоторую платформу, будь это просто dll, подключаемая к проекту или готовое приложение.
Я написал dll, которая на вход получает string, а на выходе — string, в котором каждая буква "о" заменена на "О".
Потом я запустил Word (Writer).
Что мне надо сделать, чтобы воспользоваться своей dll? Макросы не предлагать, ибо это тоже самое, что написать свой Word.
R3>>>>Сори, возможно, я в чём-то не последователен: у меня некоторые идеи ещё не обдуманы, а в обдуманных идеях я забегаю вперёд. R3>>>>Я не путаю объекты и функции. Я их — объединяю. G>>>Выделенное — очень зря. Функции объективны, а какие объекты — зависит от задачи и от взгляда человека на эту задачу (предельно субъективны). R3>>Не зная объект, ты не сможешь сказать, применима ли к нему определённая функция. G>И что? Тебе ведь не нужны объекты сами по себе, тебе (и пользователю) нужны функции. А объекты обеспечивают возможность выполнения функций.
А почему мне (и пользователям) не нужны объекты? Текст, видео-файл, звук, картинка — это всё объекты, которые нужны.
R3>>Объект может состоять не только из одной функции — от может содержать вызовы других функций. G>Объект не может состоять из функций. Пока этого не поймешь дальше не продвинешься.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
R3>>>Ну пусть ссылка. Да, пусть система сама разбирается. Но таких систем, к сожалению, нет. G>>Как это нет? Я вот пользую Entity Framework, он вполне умеет понимать ссылки и генерить из них схему БД. G>>Есть Orchard CMS, который тоже понимает ссылки. G>>Более высокоуровневые системы: 1C, SharePoint, Dynamics, в них также ты описываешь ссылки между сущностями, а он сам занимается раскладываением их в хранилище. Вот только если ты будешь путать ссылки и функции, то ниче хорошего у тебя не выйдет изначально.
R3>Ну тогда я ещё раз прошу тебя описать, как ляжет пример с принтером в эти системы?
Еще раз говорю: никак. Потому что принтер, это не объект, а функция печати. Во всех указанных системах функция реализована.
R3>>>Основная проблема не в существующем функционале, а том, что этот функционал никто не может просто использовать отдельно от продукта, в котором он реализован. G>>не понял мысли. Ты используешь некоторую платформу, будь это просто dll, подключаемая к проекту или готовое приложение.
R3>Я написал dll, которая на вход получает string, а на выходе — string, в котором каждая буква "о" заменена на "О". R3>Потом я запустил Word (Writer). R3>Что мне надо сделать, чтобы воспользоваться своей dll? Макросы не предлагать, ибо это тоже самое, что написать свой Word.
Опиши какая функция тебе нужна. Напрмиер есть стандартная функция замены, у нее есть некоторый интерфейс. Придумай интерфейс для своего кода, реализуй и пользуй. Можешь например в сторону VSTO посмотреть.
R3>>>>>Сори, возможно, я в чём-то не последователен: у меня некоторые идеи ещё не обдуманы, а в обдуманных идеях я забегаю вперёд. R3>>>>>Я не путаю объекты и функции. Я их — объединяю. G>>>>Выделенное — очень зря. Функции объективны, а какие объекты — зависит от задачи и от взгляда человека на эту задачу (предельно субъективны). R3>>>Не зная объект, ты не сможешь сказать, применима ли к нему определённая функция. G>>И что? Тебе ведь не нужны объекты сами по себе, тебе (и пользователю) нужны функции. А объекты обеспечивают возможность выполнения функций. R3>А почему мне (и пользователям) не нужны объекты? Текст, видео-файл, звук, картинка — это всё объекты, которые нужны.
Ну открой SharePoint там все это есть. В 1С нету, в ней нет функций, для которых нужен объект "файл".
R3>>>Объект может состоять не только из одной функции — от может содержать вызовы других функций. G>>Объект не может состоять из функций. Пока этого не поймешь дальше не продвинешься. R3>Реальный мир с тобой не согласен.
Как раз реальный мир со мной согласен ибо я в неделю как минимум одну постановку\ТЗ\SRS изучаю с целью понять какие объекты нужны для реализации указанных в документе функций.
Здравствуйте, gandjustas, Вы писали:
G>ФЯ тут не при чем. Посмотрите люблю бизнес-постановку задачи. Людям нужны функции, приходится долго анализировать постановку что понять какие там объекты нужны.
Я написал не один десяток функциональных спецификай (да и просто по опыту), и не встречал ни одной системы, состоящей только из функций.
Я соглашусь с этим твоим утверждением только тогда, когда система никогда не будет выдавать ничего, кроме надписи — "Всё хорошо!".
Текущие же системы генерируют отчёты, графики, уведомления, напоминания, предупреждения и т.д. для того, чтобы дальнейшие действия принял человек. Т.е. системы создают объекты.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
G>>ФЯ тут не при чем. Посмотрите люблю бизнес-постановку задачи. Людям нужны функции, приходится долго анализировать постановку что понять какие там объекты нужны.
R3>Я написал не один десяток функциональных спецификай (да и просто по опыту), и не встречал ни одной системы, состоящей только из функций.
И я не встречал. И что?
R3>Я соглашусь с этим твоим утверждением только тогда, когда система никогда не будет выдавать ничего, кроме надписи — "Всё хорошо!".
Ниче не понял.
R3>Текущие же системы генерируют отчёты, графики, уведомления, напоминания, предупреждения и т.д. для того, чтобы дальнейшие действия принял человек. Т.е. системы создают объекты.
Не-а, генерация отчета — функция, напоминание — функция.
Увы, пока этого не поймешь продвинуться дальше не получится.
Здравствуйте, gandjustas, Вы писали:
R3>>Ну тогда я ещё раз прошу тебя описать, как ляжет пример с принтером в эти системы? G>Еще раз говорю: никак. Потому что принтер, это не объект, а функция печати. Во всех указанных системах функция реализована.
Ясно. Значит я не смогу привязать к этой функции что-то своё, например, упомянутое определение местоположения.
Следовательно, данные системы (на данном этапе) не могут предложить ничего более, чем "вариться в собственном соку".
G>Опиши какая функция тебе нужна. Напрмиер есть стандартная функция замены, у нее есть некоторый интерфейс. Придумай интерфейс для своего кода, реализуй и пользуй. Можешь например в сторону VSTO посмотреть.
Здравствуйте, gandjustas, Вы писали:
R3>>Текущие же системы генерируют отчёты, графики, уведомления, напоминания, предупреждения и т.д. для того, чтобы дальнейшие действия принял человек. Т.е. системы создают объекты. G>Не-а, генерация отчета — функция, напоминание — функция.
Главное в генерации отчета не генерация, а отчёт.
G>Увы, пока этого не поймешь продвинуться дальше не получится.
Ну, кое в чём я уже продвинулся. Например всё то, что Apple представил в последнем своём продукте (привязка определения местоположения к планировщику дел или iCloud) — это примеры того, что можно сделать на моей системе.
Вероятно потому, что они считаю что "магазин" — это не только функция "купить".
G>По сути это все одно и тоже (синонимы). Важно не название, а суть.
это тебе так кажется. каждое из этих действий специфицируется по своему: каждое из них берет свой вход, выдает свой выход, используется свой контекст и делает специфичные для себя преобразования.
допустим, мы все-таки хотим получить "объективную" функцию, и попробуем ее специфировать.
выход, на первый взгляд, специфицировать получается достаточно просто: кипа бумаги с нанесенным на нее изображением(текстом),
с входом уже намного сложнее. что на входе? документ? что это такое? набор байт? в каком формате? поток символов? в каком стандарте? postscript-элементы? они в виде массива? потока? дерева? графа?
функция печатать включает в себя получение документа из какого-либо источника? или нет?
функция печатать включает в себя преобразование документов в печатный вид? или уже принимает печатный вид?
функция печатать включает в себя поиск принтера или нет?
функция печатать включает в себя организацию взаимодействия между принтером и пользователем, если например бумага кончилась, или нет?
если принтер понимает несколько форматов, а документ может быть преобразован тоже в несколько форматов, то функция печатать ищет наилучший вариант преобразования или нет?
и таких или/или вагон и маленькая тележка, которая как раз и размывает "объективность" что функций, что объектов
DG>>зы DG>>это есть опасное заблуждение, культивируемое на рсдн-е и в рядах фя-шников, что функция более объективна, чем объект. G>ФЯ тут не при чем. Посмотрите люблю бизнес-постановку задачи. Людям нужны функции, приходится долго анализировать постановку что понять какие там объекты нужны. G>А вот программистам проще наоборот, они сначала выдумывают объекты (классы), а потом прилепляют к ним функции.
с объектами проще, они хотя бы статичны
например, намного проще специфицировать что такое картинка, чем что такое вывод изображения.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
R3>>>Ну тогда я ещё раз прошу тебя описать, как ляжет пример с принтером в эти системы? G>>Еще раз говорю: никак. Потому что принтер, это не объект, а функция печати. Во всех указанных системах функция реализована.
R3>Ясно. Значит я не смогу привязать к этой функции что-то своё, например, упомянутое определение местоположения. R3>Следовательно, данные системы (на данном этапе) не могут предложить ничего более, чем "вариться в собственном соку".
Вполне возможно. Только причем тут объекты?
G>>Опиши какая функция тебе нужна. Напрмиер есть стандартная функция замены, у нее есть некоторый интерфейс. Придумай интерфейс для своего кода, реализуй и пользуй. Можешь например в сторону VSTO посмотреть.
R3>Про что я и говорил — "напиши свой Word".
Это ты сильно перегибаешь палку.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, gandjustas, Вы писали:
R3>>>Текущие же системы генерируют отчёты, графики, уведомления, напоминания, предупреждения и т.д. для того, чтобы дальнейшие действия принял человек. Т.е. системы создают объекты. G>>Не-а, генерация отчета — функция, напоминание — функция. R3>Главное в генерации отчета не генерация, а отчёт.
Демагогия. Пользоватею необходимо уметь получать от программы отчет на основании тех данных, которые он вносил. Если ты ему один раз сделаешь отчет толку будет мало. Поэтому как раз наоборот генерация гораздо важнее отчета как такового.
G>>Увы, пока этого не поймешь продвинуться дальше не получится. R3>Ну, кое в чём я уже продвинулся. Например всё то, что Apple представил в последнем своём продукте (привязка определения местоположения к планировщику дел или iCloud) — это примеры того, что можно сделать на моей системе. R3>Вероятно потому, что они считаю что "магазин" — это не только функция "купить".
В магазине самое главное не купть, а помочь пользователю найти то что ему нужно.
Здравствуйте, DarkGray, Вы писали:
G>>По сути это все одно и тоже (синонимы). Важно не название, а суть.
DG>это тебе так кажется. каждое из этих действий специфицируется по своему: каждое из них берет свой вход, выдает свой выход, используется свой контекст и делает специфичные для себя преобразования.
Возможно, но ты сразу по это не написал, поэтому мое утверждение остается верным.
DG>допустим, мы все-таки хотим получить "объективную" функцию, и попробуем ее специфировать. DG>выход, на первый взгляд, специфицировать получается достаточно просто: кипа бумаги с нанесенным на нее изображением(текстом), DG>с входом уже намного сложнее. что на входе? документ? что это такое? набор байт? в каком формате? поток символов? в каком стандарте? postscript-элементы? они в виде массива? потока? дерева? графа? DG>функция печатать включает в себя получение документа из какого-либо источника? или нет? DG>функция печатать включает в себя преобразование документов в печатный вид? или уже принимает печатный вид? DG>функция печатать включает в себя поиск принтера или нет? DG>функция печатать включает в себя организацию взаимодействия между принтером и пользователем, если например бумага кончилась, или нет? DG>если принтер понимает несколько форматов, а документ может быть преобразован тоже в несколько форматов, то функция печатать ищет наилучший вариант преобразования или нет? DG>и таких или/или вагон и маленькая тележка, которая как раз и размывает "объективность" что функций, что объектов
Это ты о чем вообще? Я говорю что функция печати объективна, ибо людям надо получать что-либо на бумаге. А с какими данными (объектами) будет эта функция работать уже зависит от конкретного приложения. Чтобы что-то распечатать пользователь будет искать функцию печати, а не "объект" принтер.
DG>>>зы DG>>>это есть опасное заблуждение, культивируемое на рсдн-е и в рядах фя-шников, что функция более объективна, чем объект. G>>ФЯ тут не при чем. Посмотрите люблю бизнес-постановку задачи. Людям нужны функции, приходится долго анализировать постановку что понять какие там объекты нужны. G>>А вот программистам проще наоборот, они сначала выдумывают объекты (классы), а потом прилепляют к ним функции.
DG>с объектами проще, они хотя бы статичны DG>например, намного проще специфицировать что такое картинка, чем что такое вывод изображения.
Именно. Поэтому программисты часто занимаются спецификациями картинок вместо вывода изображений.
Здравствуйте, gandjustas, Вы писали:
R3>>Ясно. Значит я не смогу привязать к этой функции что-то своё, например, упомянутое определение местоположения. R3>>Следовательно, данные системы (на данном этапе) не могут предложить ничего более, чем "вариться в собственном соку". G>Вполне возможно. Только причем тут объекты?
Извини, но мне надоело объяснять.
R3>>Про что я и говорил — "напиши свой Word". G>Это ты сильно перегибаешь палку.
Это ты скажи всем разрабочикам, которые пишут клоны существующих продуктов.
