Здравствуйте, elmal, Вы писали:
E>Здравствуйте, SV., Вы писали:
SV.>>Давайте сделаем так. Приведите в пример не-ОО кусок API вашего продукта (можно воображаемого), который яснее, чем ОО, и мы продолжим с этой точки. E>
E>public class NotNullUtils {
E> public static <T> List<T> processNull(List<T> list) {
E> if (list == null) {
E> return new ArrayList<T>();
E> }
E> return list;
E> }
E> public static String processNull(String string) {
E> if (string == null) {
E> return"";
E> }
E> return string;
E> }
E>...
E>
E>Пожалуйста. Набор статических функций без какого либо состояния, которыми очень часто пользуюсь.
Оффтоп: всё же я люблю шарп
public static class NotNullUtils {
public static List<T> processNull<T>(List<T> list) {
return list ?? new ArrayList<T>();
}
public static String processNull(String string) {
return string ?? "";
}
...
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Да в общем нет такой проблемы, "чей именно это метод". По крайней мере, она не обязательно должна быть. Питон вот справляется с такими вещами во вполне ОО-ключе. Строго говоря, код вида "x + y" рассахаривается в "x.__add__ y".
1. Тут нет ничего ОО-шного. Напомню, что ООП — это про посылку сообщений. То, что у нас операция сложения "внутри" реализована через отправку сообщений, вообще говоря лишняя подробность. Если ещё поглубже копнуть, то окажется, что и объектов никаких нету, а происходит банальный лукап по символьной таблице, а потом косвенный вызов.
2. Я вовсе не уверен в том, что операция __add__ реализована "объектным" образом, а не является всего лишь частью описания ADT. Ну вот struct-типы в дотнете, строго говоря, объектами не являются (не будучи забоксенными).
3. Проблемы, к которым приводит такой подход, хорошо описаны у Lazy Crow Rhrr: http://rsdn.ru/forum/philosophy/4837534.1.aspx
Здравствуйте, AndrewVK, Вы писали:
K>>Вопрос в соотношении. Одним подавай язык для задания бизнес-правил, у них все во вполне конкретных терминах и все абстракции заранее проанализированы
AVK>Это не программисты уже в привычном понимании.
Здравствуйте, AndrewVK, Вы писали:
AVK>Кто бы сомневался — с твоим то подходок к ФП как к серебряной пуле.
Отлично, пошли в ход убедительные аргументы за ООП. Начинаем с голословного утверждения о моей неадекватности.
AVK>Только вот твои качественно-экспертные оценки лично меня нисколечко не убеждают.
Не беда!
Во-первых, это не частная переписка, а открытое обсуждение, так что вполне возмоджно, что найдутся читатели, которых мои экспертные оценки убедят.
Во-вторых, вы легко можете ознакомится со статьями лучших экспертов по этим вопросам с помощью сети интернет.
K>>1) — абстракции в ООП слабенькие и протекающие, но это можно исправить AVK>Субъективно
Объективно. ООП-шные абстракции 1) теряют информацию 2) легко "вскрываются" штатными средствами. При этом первое диктует необходимость второго.
K>>Формальное описание у ООП просто мозгоразрывающее и малоспособствющее нахождению каких-то полезных, нетривиальных свойств AVK>Субъективно. Особенно по сравнению с некоторыми мозгоразрывающими конструкциями из ФП-языков.
Объективно. Формальное описание нетривиального ООП — это высшая точка TAPL — самая сложная часть требующая (почти) всех знаний приобретаемых в ходе этого курса. Забавный факт: это формальное описание оказалось достаточно мозгоразрывающим даже для Пирса (самого настоящего, а не форумного эксперта по обсуждаемому вопросу) так что он совершил ошибку, которую потом пришлось исправлять.
Это формальное описание требует F^omega_sub, которая, собственно, содержит все мозгоразрывающее из ФЯ (то, что разрывает мозги сильнее уже и языками-то не считается, а считается приф-ассистантами) + нешуточная экстра. С половиной из этих ужасов программист на ФЯ вообще не сталкивается, а с большей частью из того, с чем сталкивается — сталкивается меньшую часть времени.
Самое же обидное, что при такой сложности извлекать из этого формального описания затруднительно.
AVK>Вообще какая то игра терминами. Наследование и агрегация — основные способы комбинирования в ООП — вполне себе удобные способы комбинирования, хоть и не идеальные.
В чем тут игра терминами? Комбинатор в ФП — это обычная функция, которую можно применить к другим и получить нужную "комбинацию" функций. Комбинаторы объектов это не обычные объекты, в коде, а страницы неформальных рассуждений и схемы со стрелочками. Нельзя скомбинировать объекты послав им какие-то "сообщения" — можно только произвести "комбинирование" в уме и записать его результат в коде. Одно из немногих исключений — наследование — тоже не является полноценной операцией а только синтаксисом для записи результата — как в случае операций над алг. типами * и + в недоФЯ. По-моему, это совсем не то, что понимается под словом "удобство".
AVK>У чистого ФП — больше. Сигнатура функции слишком примитивна,
Это можно как-то раскрыть подробнее?
AVK>приходится даже на нижнем уровне вводить всякие подпорки типа карринга,
Почему карринг — подпорка?
AVK>туплов, АлгТД и т.п.
Туплы — это и есть АлгТД.
AVK>Сущностей в итоге больше — это плохо, даже если они и переиспользуются в других ситуациях.
То, что сущностей в ФП больше — голословное утверждение.
AVK>Набор функций как раз и потребовался
Вопрос в том, в чем "дополнительность сущности" набора функций по отношению к набору функций. Функция и функция — одна и та же сущность.
AVK>из-за проблем с хранением всей спецификации в сигнатурах функций.
Претензия к "автоматическому протягиванию" тайпклассов через неявный параметр — это претензия к дополнительной сущностности того же уровня, что претензия к неявному this в ООП.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Ikemefula, Вы писали:
I>Это зависит от задачи.
В некотором смысле — да. Вернее, не от задачи, а от решения. Если мы всегда изменяем по месту, ничего не возвращая из методов — (т.е. если по факту "функции" запрещены) абстракция достаточно сильная. Если запретить даункасты — не протекающая. Но в реальности так писать невозможно, да и не хочется.
I>А как быть с чистотой АПИ у ФП ? Здесь, мягко говоря, конь не валялся.
Не понял вопроса.
K>>Реальное преимущество ООП — простота реализации ОО-языка. I>Простота реализации вообще ничего не значит, наглядным примером является такой язык как С++
Эта проблема становится понятна в сравнении. Простота (сложность) реализации имеет значение, поэтому существующие реализации ФЯ делятся на три категории: игрушечные, компромиссные-и-недоделанные и несуществующие. При этом еще совсем недавно категории было две — первая и третья.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Sinclair, Вы писали:
S>Непонятно, при чём тут ООП. Всё, чего вы попросили, выражается при помощи замены "простейшей функцией" её шаблонным аналогом: S>
S>(T, T) resolveSqEq<T>(T a, T b, T c);
S>
S>Потому, что алгоритму неважно, какая там точность. Ему важно, чтобы для T были определены операции умножения, сложения, возведения в степени -1 и 1/2, и получения обратного элемента. Всё. А, ещё пригодится константа 0. S>Кормите алгоритм хоть октонионами, хоть матрицами — дайте определения операций, и дело в шляпе.
Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа (формат IEEE-666, 50 знаков). i = 100. Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта?
Надо ли говорить, что первой моей мыслью при ознакомлении с подобным проектом будет поискать класс, инкапсулирующий число, который умеет хранить его с заданной точностью, и поддерживает вход и выход?
SV.>>Про бухгалтерию я не знаю, что ответить. Я ее знаю на уровне ведения ООО и у меня идея класса Account отторжения не вызывает. S>У этого класса нет никакого поведения, поэтому совершенно непонятно, что именно инкапсулировать. "Состояние" объекта Account полностью прозрачно. Еще есть такая проблема, что в принципе понятие "состояние" у счёта штука очень условная. Грубо говоря, бухгалтерия — это набор проводок. S>Исходя из этого набора мы можем высчитать всякие виртуальные вещи — типа "каков у нас остаток дебиторской задолженности на 1 августа 2012".
Ну а кто должен считать баланс? "Мы" — это кто? Состояния у нас нет, а есть обработчик суммы проводок, но где он у вас сидит? Кроме того, есть же еще функциональность типа обработки и хранения внешних атрибутов счета, не связанных с балансом.
S>Но сами эти вещи назвать "состоянием счёта" у меня мозг не поворачивается — просто потому, что через полчаса я попрошу посчитать тот же остаток на совершенно другую дату, и он будет ничуть не хуже, чем первый.
У кого попросите? Да, забыл упомянуть. Если счет мультивалютный, то где и как мультивалютность будет обеспечиваться?
>Есть ещё куча показателей, которые совсем никак не похожи на "объекты", существующие объективно и независимо от наблюдателя — к примеру, тот же "оборот дебиторской задолженности за период".
Оборот за период не выглядит объектом для наблюдателя. Ну, разве что, если учесть валюту и какие-то иные атрибуты... Но тогда их и будет разумно инкапсулировать вместе с числом.
S>Решение, в котором счета — это объекты, а проводки — сообщения, которыми они обмениваются, потребует гонять эти проводки туда-сюда каждый раз, как мне захочется заглянуть в прошлое. Внезапно обнаруженный первичный документ, датированный прошлым сентябрём, сломает нафиг эту модель, т.к. его не "вставишь" между уже отправленными сообщениями.
Это плохое решение, но оно результат плохой декомпозиции, а не подхода.
S>Поэтому в бухгалтерии гораздо полезнее модель, в которой счёт — это просто номер; даже не число, а идентификатор. Проводка — это тоже не объект, а просто запись некоторого факта. Поверх этого рисуются всякие расчётные операции, которые тоже нифига не объекты, а просто формулы (уровня пятого класса). Сведение баланса = проведение примитивного расчёта.
Здравствуйте, Sinclair, Вы писали:
V>>"Эта штука" как раз и спровоцировала появление ООП. Бо в Фортране и многих других языках никаких указателей не было. А как только в ЯВУ появился ссылочный тип данных, так очень быстро затем появилось ООП для целей его обслуживания. S>В С и паскале ссылочные типы данных имеются в полный рост, без малейших признаков ООП.
Отличный пример, ЧТД. Поэтому получили из него совместимый по исходникам С++.
Насчет паскаля ты в курсе.
S>В коде x86 есть понятие указателей, но нет понятия объектов.
Даже есть условные переходы, но нет циклов. Есть вызов подпрограмм по неизвестному в compile-time адресу, но нет ФВП. Продолжить?
V>>Занавес. S>Опять клоунада? Я говорю не про макросистему, а про команды косвенной адресации.
Дык, а чего бы мне не поклоунадничать, если косвенная адресация — это и есть на сегодня вотчина ООП. Заметь, что ФП старательно этого вопроса избегает или прячет его от программиста. Например, явная косвенная адресация ставит раком т.н. иммутабельность в Немерле, т.к. непонятно, к чему начинает относится та самая иммутабельность: к ссылочной переменной или к ссылаемому объекту... И не понятно, как далеко ее можно распространить, даже если сделать так, чтобы иммутабельность относилась к ссылаемому объекту. Кстате, это перекликается с обсуждаением const, бо константность можно распространить и на мемберы (хотя тоже с оговорками).
Здравствуйте, samius, Вы писали:
V>>Зачем бэкдор, если код комбинаторного парсера содержит бесконечные рекурсии? То бишь, чистое ФП в энергичной манере зациклило бы этот код до исчерпания памяти. Но ленивость, в сочетании с порядком вычисления аргументов при if-then-else или в конструкциях ПМ, задает определенный порядок вычисления, который не дает программе вечно зациклиться. S>Покажи сайд-эффект if-а Хаскеля, не балаболь.
В выделенном смысле уже показал.
S>>>В итоге выходит что чистый ФП не имеет отношения к SP, т.к. не содержит statement-ов, изменяющих состояние программы.
V>>Функциональная программа так же состоит из выражений языка, которые в процессе работы меняют состояние программы. Просто некоторые слишком молодые адепты ФП в пылу споров забывают, что состояние стека вычислений + положение указателя инструкций в потоке исполнения образуют то самое состояние программы. S>Ты хотел сказать состояние вычислителя? Покажи мне изменяемое состояние в ПРОГРАММЕ на хаскеле.
В исходнике, что ле? С ума сошел? Я могу рассуждать только о работе программы в рантайм. И я тебе уже всё показал.
V>>Предположу, что только у наследованных от структурной. V>>Например, в логическом программировании никакого ветвления нет. S>Т.е. у Ф программы состояние вычислителя ты обнаружил, а у Л программы нет? S>
Ты точно на этот пост хотел ответить? (см выделенное)
Здравствуйте, Sinclair, Вы писали:
S>Коллега, плотность бреда на квадратный пост превысила ПДК. Ваши заблуждения настолько всеобъемлющи (я пока не нашёл области, где хотя бы 20% ваших утверждений соответствовали действительному положению вещей), что впредь я буду игнорировать все ваши посты на любые темы.
Ну дык, надо больше интересоваться как оно всё устроено и работает и меньше поддаваться догмам. Тогда бы ты понимал, скажем, чуть быстрее. А то мне приходится объяснять тебе простейшие вещи в десятках постов, в попытке преодолеть косность мышления.
То, что я высказываю точку зрения, не совпадающую со многими коллегами на этом сайте — я для этого сюда и пишу, собственно. Бо вторить банальностям как попугай — банально неинтересно, я их наизусть уже 20 лет знаю. Просто надо уметь смотреть на любой технический момент под разными углами, а не только с "единственно правильного".
Здравствуйте, SV., Вы писали:
SV.>Допустим, я хочу посчитать a — длинноцелое, b — строка на входе (неизвестное число знаков), c — бинарное представление вещественного числа X(формат IEEE-666, 50 знаков). i = 100.
Что такое i?
Результат, в зависимости от сиюминутных потребностей, требуется использовать при форматировании строк (пугать комиссии, ага), и отдавать в бинарях для хранения в базе DB-3000. Как будет выглядеть (хотя бы примерно) код вашего проекта?
Я не понимаю вашего вопроса. SV.>Надо ли говорить, что первой моей мыслью при ознакомлении с подобным проектом будет поискать класс, инкапсулирующий число, который умеет хранить его с заданной точностью, и поддерживает вход и выход?
Надо. Потому что эта мысль совершенно неочевидна. Зачем вы собрались искать "класс" для штуки, которая не обладает идентичностью и поведением?
Почему вы не хотите найти АТД, т.е. штуку, которая принимает некоторые значения и имеет некоторое определённое поведение?
То, что вы ищете "класс", выдаёт наличие шрамов в сознании, оставленных С++.
SV.>Ну а кто должен считать баланс? "Мы" — это кто? Состояния у нас нет, а есть обработчик суммы проводок, но где он у вас сидит?
Там, где удобно с точки зрения архитектуры программы.
Обработка суммы проводок — это функция, имеющая простой вход и простой выход. SV.>Кроме того, есть же еще функциональность типа обработки и хранения внешних атрибутов счета, не связанных с балансом.
Конечно. Есть ненулевой шанс, что при ООП-шной декомпозиции будет выделен объект, отвечающий за хранение атрибутов счетов. Но он не будет привязан к конкретному счёту — зачем?
S>>Но сами эти вещи назвать "состоянием счёта" у меня мозг не поворачивается — просто потому, что через полчаса я попрошу посчитать тот же остаток на совершенно другую дату, и он будет ничуть не хуже, чем первый. SV.>У кого попросите?
Я — попрошу у программы. Мне всё равно, я пользователь. SV.>Да, забыл упомянуть. Если счет мультивалютный, то где и как мультивалютность будет обеспечиваться?
Ну, я не настолько хорошо разбираюсь в бухгалтерии, чтобы сходу написать архитектуру мультивалютности. Но, надо полагать, что она будет обеспечиваться там же, где и всё остальное.
SV.>Оборот за период не выглядит объектом для наблюдателя. Ну, разве что, если учесть валюту и какие-то иные атрибуты... Но тогда их и будет разумно инкапсулировать вместе с числом.
В том-то и дело, что не выглядит. И счёт тоже не выглядит объектом. В общем и целом, внезапно оказывается, что ООП-шных объектов в бухгалтерии нет.
SV.>Это плохое решение, но оно результат плохой декомпозиции, а не подхода.
Совершенно верно. Но именно такой способ декомпозиции навязывают обычные курсы ООП.
При ОО-анализе бухгалтерской программы мы будем спрашивать не "что делает счёт", а "что должна делать программа".
Допустим, у нас возникает ответ "должна рассчитывать оборотно-сальдовую ведомость". Дальнейшее движение мысли приводит нас к набору объектов, которые соответствуют "механизмам расчёта" этой оборотно-сальдовой ведомости. Но никаким объектам в предметной области они соответствовать, увы, не будут. Проводки так и останутся структурами, счета останутся идентификаторами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали: S>Надо. Потому что эта мысль совершенно неочевидна. Зачем вы собрались искать "класс" для штуки, которая не обладает идентичностью и поведением? S>Почему вы не хотите найти АТД, т.е. штуку, которая принимает некоторые значения и имеет некоторое определённое поведение?
Тьфу блин, зарапортовался. Имелось в виду "для неё задан некоторый определённый набор операций". Поведения никакого у чисел нет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, samius, Вы писали:
V>>Реальность такова, что в ООП применимы любые наработки ФП безо-всяких адаптаций, зато наоборот — увы и ах. S>твоя позиция это что-то в духе "давайте будем мешать чистое ООП со всем что мешается, но мешать чистый ФП не будем". Возьми нечистый ФП и сравнивай его с нечистым ООП.
Дык, в том-то и дело, что нет в природе никакого "нечистого ООП". Есть просто некие вычисления и есть сохранение результатов вычислений в полях объектов или передача их как сообщений другим объектам. Способ вычислений в ООП никогда не ограничивался, в отличие от чистого ФП, где полно ограничений.
А "нечистое ФП" — это процедурный подход + функциональный тип. ))
S>>>И причем тут ООП?
V>>При том, что мы склонны наделять свои абстракции-образы: V>>- характеристиками; V>>- поведением, зависящим от характеристик; V>>- отношениями с другими абстракциями.
V>>За счет этого мы можем моделировать поведение окружающего мира, в свою очередь за счет этого у человека работает воля, появляется вообще такое понятие как работать "на будущее", будь это будущее даже не далее сегодняшнего ужина. S>Бла-бла
Т.е. ты не понял, как "моделирование мира" относится к "воле"? Просто недавно давали определение: воля — это способность принимать решения вопреки безусловным реакциям на внешние раздражители, то бишь умение делать себе чуть хуже сейчас, чтобы получить какие-то бенефиты в будущем. Для работы этого механизма то самое будущее надо уметь моделировать в разных вариантах и сравнивать их.
Ключевое в связи ООП с мышлением я вижу именно в способности мышления человека моделировать окружающий мир.
V>>Указанный выше список разве не описывает ОО-парадигму? S>и почему-же он описывает только лишь ее?
Из-за поведения. В чистом ФП нет поведения, бо поведение — это побочный эффект, эта реакция, которая зависит от всей истории предыдущих воздействий. В ФП же "реакции" функций безусловные, зависят только от текущего воздействия.
С отношениями в ФП тоже большие проблемы из-за наличия лишь одного вида декомпозиции — функционального.
Здравствуйте, vdimas, Вы писали:
V>Ну а теперь вики: V>
V>Структу́рное программи́рование ...
V>1. Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
V> * последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
V> * ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
V> * цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).
V>В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается.
V>2. Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы.
V>Про последовательное исполнение в Хаскеле — do-стрелки.
Структурное программирование есть машина тьюринга. Функциональное — лямбда-счисление черча. Функциональное на низком уровне реализовано через структурное, так процессор работает, пока что в природе нет процессоров которые умеют лямбда-счисление.
Соответсвенно ты снова попутал идею и реализацию идеи
Здравствуйте, SV., Вы писали:
SV.>Немного позже покажу, как такую задачу решал я.
Небольшая поправка — не решал, а решал бы. Я сейчас вспомнил детали того, что реально решал, и там среда диктовала свои условия. И как раз ООП очень не хватало.
Так вот. Свой счет я посадил бы поверх таблицы проводок, и он бы хранил внутренний уникальный идентификатор плюс банковскую атрибутику. Получение состояния на любой момент времени, оборотов за период (а также входящее и исходящее сальдо периода) было бы реализовано в нем в виде методов. Там же — валютный пересчет на основе входящей ссылки на объект, представляющий Форекс (или, по-простому, конфиг текущей сессии). И это как раз и есть модель реального счета. С одной стороны она соответствует модели в голове у бухгалтера, поскольку основывается на проводках. С другой стороны, ее можно отдать, допустим, программисту гуёв, и он найдет в ней и .CalcCurrentBalance(), и что его душе угодно. Не проблема хранить пачку счетов (вектор, например), поскольку реальные инкапсулируемые данные в памяти малы.
S>Проводки так и останутся структурами, счета останутся идентификаторами.
Это детали реализации.
Счет-то все равно объектом остается с соответствующими сообщениями:
— зарегистрировать еще одну операцию,
— вывести текущее состояние по счету,
— вывести историю операций и т.д.
Например, когда заходишь в инет-банк, то со счетами работаешь как с объектами: выбираешь объект (счет, транзакцию) и посылаешь ему сообщение посредством нажатия соответствующей кнопки. При этом не важно, как он реализован в js-е или на сервере: как идентификатор, как запись в базе, как еще что-то — для использования через gui инет-банка, счет удобнее воспринимать как объект.
ps
Основная моя мысль, что счет одновременно является и идентификатором, и объектом (еще чаще нечетким объектом — когда набор методов и набор состояния такого объекта зависит от контекста использования)
Здравствуйте, Sinclair, Вы писали:
V>>Математика вполне делится на области, которые можно сложить иерархически. Другое дело, что там получается полноценный направленный граф, а не урезанный его вариант — дерево. S>Иерархия и есть дерево. Появился цикл — прощай иерархия.
ОМГ. В деревяхе у каждого узла лишь один потомок, либо лишь один родитель в перевернутой деревяхе. В направленном графе и тех и тех может быть более одного даже без циклов.
S>Я не очень понимаю, что вы называете "делением на области". Вот, скажем, топология и мат.анализ — это такие области? И как вы сложите их "иерархически"?
Предлагаешь складывать в иерархически независимые узлы? Их можно складывать только через общих родителей или общих детей. Мат.анализ — это комплексная область математики сама по себе. Но она пересекается по своему низлежащему аппарату с другими комплексными областями математики.
V>>Именно потому. Иерархии абстракций хорошо подходят человеческому мышлению — от общего к частному. S> Есть много форм разных форм человеческого мышления. Основные — анализ, синтез, сравнение, абстракция, обобщение. Вы упомянули только одну из них.
А одна и есть, просто я привел базис, а ты производные:
анализ — от общего к частному;
сравнение — от общего к частному;
абстракция — умение отбрасывать детали;
обобщение — умение ограничивать сравнение неким уровнем абстракции;
V>>Производственное удобство связано с удобством для производителя-человека. Как ни крути, но он так мыслит. Как бы некоторым не хотелось думать, что уж они-то мыслят не так. Чем мутнее образ в мозгу, тем он абстрактнее... только и всего. S>Не надо натягивать презерватив на глобус. Человек не мыслит объектами из ООП, как бы некоторым ни хотелось думать, что уж они-то мыслят именно объектами.
А что есть, по-твоему, объект в ООП? Почему в дизайне мы называем объекты и/или классы "сущностями"? Дай своими словами определение "сущности".
Здравствуйте, Lazy Cjow Rhrr, Вы писали:
LCR>Короче, реализация бинарных соотношений и операций как методов — это ужасно граблеобразно и неестественно. Это как минимум некрасиво. А решение-то на поверхности: отказаться от клеящего объекта, ввести сообщения приходящие из ниоткуда — свободные функции и ввести ограничения для аргументов функций в виде классов типов или обобщённых интерфейсов.
