поиск по форуму

> никак не могу найти, чем тип от класса отличается

Это всё на уровне словоблудия. Точек зрения как грязи. Например, что операции по отношению к типу внешние, а по отношению к классу — внутренние. И так далее.

>чем тип от класса отличается

Гради Буч Объектно-ориентированный анализ и проектирование http://pco.iis.nsk.su/~shv/GraBooch/index.htm

Про то как Луговский не осилил ООП?

> Это всё на уровне словоблудия.

поддерживаю

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

Вообще забавно, некоторые чрезмерно фанатичные граждане преподносят OOD/OOP как панацею, с которой толпы индусов будут мегакодить быстро и безглючно. А на практике индусы и к ним примкнувшие как раз и не осиливают, что по тому же ЛОРу хорошо видно (каждый второй не осиливший балбес считает своим долгом в ООП плюнуть).

Может, ООП все таки для элиты, а не для шпаны всякой?

>Может, ООП все таки для элиты, а не для шпаны всякой?

Это относится не только к ООП, а к программированию вообще. А индусы пусть кодят на 1С и пыхапэ:)

> Это относится не только к ООП, а к программированию вообще.

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

Я всегда говорил и буду говорить, что ООП - это очень мощно и очень сложно, и что если кто ООП не понимает, то пусть в программирование не лезет.

>Может, ООП все таки для элиты, а не для шпаны всякой?

нет ООП это для шпаны, неосилившей содержания

> нет ООП это для шпаны, неосилившей содержания

Да? Расскажи нам, не-шпана, как "не осилив содержания" объектную декомпозицию предметной области делать.

ООП не самая общая сущность, но многие пытаются её выдать за самую общую

посмотри про автоматы

> ООП не самая общая сущность, но многие пытаются её выдать за самую общую

Те же самые и пытаются выдать, кто кричит, что ООП годится для домохозяек.

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

>объектную декомпозицию предметной области делать.

зависит от исходных данных и целей декомпозиции?

>ООП в задаче место находится, и места этого - процентов за 90 точно.

в какой задаче?

>те, кто ООП не осилил

я вижу кто-то мат. модели не осилил и общие схемы моделирования D,F,P,Q,N и A

Re^2: [vsl] формальная теория ООП

> Однако, реальность такова, что в большинстве случаев для ООП в задаче место находится, и места этого - процентов за 90 точно.

"Если в руках молоток, всё остальное кажется гвоздями."

> "Если в руках молоток, всё остальное кажется гвоздями."

Ну не совсем так. Молоток у нас очень мощный, а электродрель ручная -- и естественно хочется молоток.

Кроме того, то, что называют ООП, возможно покатило бы и в других местах. Как например насчет наследования автоматов (например путем расширения множества состояний) -- это будет ООП или ?

* молоток у нас очень мощный, пневматический,

зачем их наследовать, когда их можно соединить в новый?

реквестирую мигеля.

> а _электро_дрель _ручная_

А электричество в ней для чего? :)

Re^4: [vsl] формальная теория ООП

>> "Если в руках молоток, всё остальное кажется гвоздями."

> Ну не совсем так. Молоток у нас очень мощный, а электродрель ручная -- и естественно хочется молоток.

> Кроме того, то, что называют ООП, возможно покатило бы и в других местах. Как например насчет наследования автоматов (например путем расширения множества состояний) -- это будет ООП или ?

Ты очень хорошо проиллюстрировал мой тезис своим примером ;) Действительно, что угодно можно за уши или, в крайнем случае, за яйца, притянуть к ООП. А эффективно ли это будет? А насколько сложнее такой код будет потом поддерживать?

Судя по индустрии - и эффективно и поддерживать можно.

Еще формальную теорию ООП http://www.linux.org.ru/jump-message.jsp?msgid=3066290&cid=3067126 посоветуем

> > а _электро_дрель _ручная_

> А электричество в ней для чего? :)

чтобы она под линупсом крутилась:)

>http://www.linux.org.ru/jump-message.jsp?msgid=3066290&cid=3067126 

Вминательно читаем топик:

>Пискунова
>Карделли

> Судя по индустрии - и эффективно и поддерживать можно.

Судя по индустрии, индустрия колется, но ест. Ибо ничего более не умеет.

> Я всегда говорил и буду говорить, что ООП - это очень мощно и очень сложно, и что если кто ООП не понимает, то пусть в программирование не лезет.

"ООП -- это замыкания для бедных" (C) ;-)

> как "не осилив содержания" объектную декомпозицию предметной области делать.

Если объектную декомпозицию ставить за фетиш, тогда да, без ООП не обойтись. Но в жизни чаще рулит функциональная декомпозиция :-).

> "ООП -- это замыкания для бедных" (C) ;-)

Блаженны нищие духом ибо их есть царствие ООП.

>> а _электро_дрель _ручная_

> А электричество в ней для чего? :)

электричество для понтов :-) конечно не электрическая дрель, я уже засыпал.

> "ООП -- это замыкания для бедных" (C) ;-)

Замыкания в ООП делаются, но почему они для бедных? Пример в студию, когда нужно замыкание именно в не-ООП стиле.

>> Кроме того, то, что называют ООП, возможно покатило бы и в других местах. Как например насчет наследования автоматов (например путем расширения множества состояний) -- это будет ООП или ?

> Ты очень хорошо проиллюстрировал мой тезис своим примером ;) Действительно, что угодно можно за уши или, в крайнем случае, за яйца, притянуть к ООП. А эффективно ли это будет? А насколько сложнее такой код будет потом поддерживать?

Ты похоже меня не понял. Подумай о наследовании автоматов, и можно ли это назвать ООП.

> зачем их наследовать, когда их можно соединить в новый?

Ну это уже множественное наследование получается.

А вообще-то наследование автоматов имеет проивоположную (ко/контра)вариантность обычному наследованию.

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

Это к ООП вряд ли относится, так как сложности будут из-за неправильной реализации ООП языком программирования.

Именно, наследование автоматов имеет противоположную (ко/контра)вариантность наследованию классов, так что через классы их выражать м.б. неудобно, но значит ли это непременимость ООП? (однако наследование тут явно к месту)

> Замыкания в ООП делаются, но почему они для бедных?

Потому что, все, что есть в ООП, можно сделать через замыкания. Но те, кто ниасилил замыкания, используют ООП.

>Именно, наследование автоматов имеет противоположную

их не надо наследовать, надо понимать может ли один автомат имитировать другой и за какое время

>> Замыкания в ООП делаются, но почему они для бедных?

> Потому что, все, что есть в ООП, можно сделать через замыкания.

А всё, что есть в замыканиях, можно сделать через ООП. И всё, что есть в ООП, можно сделать в чистом Си. И что это доказывает?

http://www.odnoklassniki.ru/user/53630105767 vsl delivered. Сходите и спросите.

> А всё, что есть в замыканиях, можно сделать через ООП

Можно и на машине Тьюринга сделать, но вручную. Замыкания хороши тем, что контекст захватывается автоматически. Этим же они и плохи - в ООП его надо явно засунуть в поля класса.

> Но в жизни чаще рулит функциональная декомпозиция :-).

Представь в виде монады модель, допустим, автомобиля. ООП - тривиально, все на объекты и сообщения разбивается, с замкнутым в объектах состоянием. Функционально - можно, но нелепо и сложно.

Мнение кретинов не должно волновать белого шерифа.

Спрашивать надо у Буча. Можно и у Фаулера. Только не трогайте Степанова и Александреску, они дураки.

>> А всё, что есть в замыканиях, можно сделать через ООП

> Можно и на машине Тьюринга сделать, но вручную.

Конечно. Об этом и речь - реализовать можно всё на всём, и _сама возможность_ реализации - ни разу не аргумент.

Ага. Вопрос в удобстве. Но почему-то функционанисты постоянно тыкают людям своими замыканиями vs. ООП, тогда как реальная killer feature, которая у некоторых из них есть, и на которую и в самом деле нельзя смотреть без зависти - это continuations.

Работа Пискунова на полноценную формализацию ООП не тянет.

Работа Карделли является формализацией наиболее общей объектной системы типов.

Чего реально нет на данный момент - это объектной операционной семантики. Но, собственно, на фиг она и не нужна.

>Представь в виде монады модель, допустим, автомобиля. ООП - тривиально, все на объекты и сообщения разбивается, с замкнутым в объектах состоянием. Функционально - можно, но нелепо и сложно.

моделируют для моделирования, только имитаторы бурной деятельности, пока их инсайдер не утрясёт процент отката. Все остальные моделируют не просто так, а чтобы какие-то свойства реального объекта исследовать без наличия этого реального объекта. Если считать формальным языком для ООП UML, то я так и не понял какой профит можно получить нарисовав автомобиль в виде диаграмм ???

> Если считать формальным языком для ООП UML, то я так и не понял какой профит можно получить нарисовав автомобиль в виде диаграмм ???

Например, формально выяснить, на каждое ли возможное событие есть заложенная в системе реакция.

>Например, формально выяснить, на каждое ли возможное событие есть заложенная в системе реакция.

если нет реакции для события, то этого события для системы не существует. Ну а как мне UML поможет сократить перебор, я без UML диаграммы не могу узнать на какие события реагирует система?

> Об этом и речь - реализовать можно всё на всём, и _сама возможность_ реализации - ни разу не аргумент.

угу. Тогда уж происследуйте операции, какая реализация общей модели каким способом более эффективна в целом, область применимости и ограничения каждой такой реализации.

UML - частный случай. Важно же то, что для такого рода анализа ты обязан представить систему в виде множества объектов и сообщений. То есть, мыслить именно в ООП-парадигме. И любое другое представление будет усложненным вариантом ООП. Так зачем усложнять? Надо решать задачи адекватными методами.