Зачем нужны объекты?

Зачем нужны объекты?

0

Сообщение от castorsky А нормальные люди по модулям =)

Сначала по классам (или процедурам), а потом по модулям.

Сообщение от castorsky ОО в равной степени подходит для больших проектов как и ФП или ИП

Только тогда почему-то никто об этом не догадался. Если бы ФП и ПП удовлетворяли текущие потребности, то вряд ли стали придумывать ООП. (ООП - это одна из разновидностей ИП, поэтому нет смысла их противопоставлять.)
Использование функциональных ЯП для рисования интерфейса или для работы с БД для Вас не выглядит странным?

Сообщение от castorsky 1. было и есть без ООП 2. наследование или интерфейсы? Вот в чем вопрос. Что в чем и что исправляет? 3. прекрасно работает в ФП, легко налаживается в ИП.

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

Сообщение от castorsky win

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

0

Сообщение от Shamil1 Сначала по классам (или процедурам), а потом по модулям.

А куда деть namespaces, наследование? Не вяжется с модулями.

Сообщение от Shamil1 Только тогда почему-то никто об этом не догадался.

Хотите бугурт? Тыц

Сообщение от Shamil1 Если бы ФП и ПП удовлетворяли текущие потребности, то вряд ли стали придумывать ООП.

Почему это? А карьерный рост? А обправдание потраченного бюджета? А пыль в глаза, в конце концов? Главное убедить совет директоров, а они уже отдел маркетинга нахлобучат как положено.

Сообщение от Shamil1 ООП - это одна из разновидностей ИП, поэтому нет смысла их противопоставлять

Есть смысл. Современные языки (как Вы сначала упомянули) имют тенденцию к совмещению ООП и ФП, как можно более избавляясь от ИП.

Сообщение от Shamil1 Какое имеет значение, было это до ООП или нет? Речь идёт о том, как модульность сочетается с ООП. О других языках речь не идёт.

Модульность какбэ никак не сочетается с ООП.

Сообщение от Shamil1 В контексте модульности - интерфейсы.

Понимаете ли, модуль - независимая, самостоятельная единица компиляции и точка. Нет модульности в ООП. И не было никогда, и не будет по той причине что ООП - это свои единицы компиляции. В них нет ни порядка, ни точного стандарта, да и самих модулей в ООП нет и не упоминается.

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

Так почему бы нам не описывать свои ЯП пейзажами, например?

0

Сообщение от castorsky А куда деть namespaces, наследование? Не вяжется с модулями.

Чем namespaces мешают? Никто Вас не заставляет наследовать от модулей. Кривыми руками можно любую идею загубить. Аргумент из серии "не могу писать на Си, потому что там память не освобождается".

Сообщение от castorsky Хотите бугурт? Тыц

Прочитал первые несколько страниц.
1. ООП там рассматривается на примере С++, который не является чистым ОО языком и сильно страдает от поддержки совместимости с Си.
2. Производительность измеряется в строчках кода. Ага. Тогда копи-паст - самый продуктивный метод повторного использования кода.
3. Статья начинается со слов, что другие исследователи получили совсем другие результаты, но автор статьи с ними не согласен. Так что это всего лишь один из взглядов.

Сообщение от castorsky Модульность какбэ никак не сочетается с ООП.

Я уже привёл Вам объяснение, как сочетается. Но можете взглянуть, например, на учебные проекты типа Prism.

Нет модульности в ООП. И не было никогда, и не будет по той причине что ООП - это свои единицы компиляции.

По Вашей логике, если бы в Хаскеле модули назвали "кводулями", то Хаскель не поддерживал бы модульность.
И что это за единый для всех модульных языков стандарт модуля, о котором Вы говорите?

Сообщение от castorsky Так почему бы нам не описывать свои ЯП пейзажами, например?

Пейзажи не подходят для этих целей. А вот термины "объект", "класс", "прототип", "наследование" и т.д. - замечательно подходят.

0

Сообщение от Shamil1 Аргумент из серии "не могу писать на Си, потому что там память не освобождается".

Аргумент железобетонный. Потому что

Сообщение от castorsky Понимаете ли, модуль - независимая, самостоятельная единица компиляции и точка.

А пространство имен тоже единица компиляции. Взаимоисключающие параграфы.

Сообщение от Shamil1 Прочитал первые несколько страниц. 1. ООП там рассматривается на примере С++, который не является чистым ОО языком и сильно страдает от поддержки совместимости с Си. 2. Производительность измеряется в строчках кода. Ага. Тогда копи-паст - самый продуктивный метод повторного использования кода. 3. Статья начинается со слов, что другие исследователи получили совсем другие результаты, но автор статьи с ними не согласен. Так что это всего лишь один из взглядов.

1. несовершенство с++ не делает его не ООЯП.
2. Речь не о производительности программы, а о производительности труда программиста.
3. Ну не нра эта статья, почитайте чтоли статьи Степанова (автор крестовых шаблонов).

Сообщение от Shamil1 Я уже привёл Вам объяснение, как сочетается.

Я уже опровергнул как бы. Не понимаете? Модуль - независимая самостоятельная единица компиляции. ООП противоречит этому some1.foo(), some2.foo(). Когда модульность в купе с полиморфизмом позволит написать foo(some1), foo(some2). Разницу чувствуете?

Сообщение от Shamil1 По Вашей логике, если бы в Хаскеле модули назвали "кводулями", то Хаскель не поддерживал бы модульность.

В haskell модули и так называются иначе - пакеты =)) и он (haskell) поддерживает модульность.

Сообщение от Shamil1 И что это за единый для всех модульных языков стандарт модуля, о котором Вы говорите?

algol68 какбэ. Оттуда корни растут.

Сообщение от Shamil1 А вот термины "объект", "класс", "прототип", "наследование" и т.д. - замечательно подходят.

Ничем не отличается от "протрет", "пейзаж", "натюрморт", "фото".

0

Сообщение от castorsky ООП противоречит этому some1.foo(), some2.foo(). Когда модульность в купе с полиморфизмом позволит написать foo(some1), foo(some2). Разницу чувствуете?

Нет. Объясните, пожалуйста.

Сообщение от castorsky Речь не о производительности программы, а о производительности труда программиста

Я понял. Именно поэтому привёл пример с копи-пастом. Представляете, какой производительности может добиться программист, активно использующий копи-паст .

Сообщение от castorsky В haskell модули и так называются иначе - пакеты =)) и он (haskell) поддерживает модульность.

Поддерживает "пакетность", а модульность не поддерживает.

Сообщение от castorsky algol68 какбэ.

Не нашёл в гугле такого стандарта модуля. Поэтому даже не могу его сравнить с другими языками. Например, с Си.

0

Сообщение от Shamil1 Нет. Объясните, пожалуйста.

одна функция для схожих типов, или схожие объекты каждый со своим методом?

Сообщение от Shamil1 Представляете, какой производительности может добиться программист, активно использующий копи-паст

Невероятной. Или, например,

Сообщение от Shamil1 Поддерживает "пакетность", а модульность не поддерживает.

Не согласен.

Сообщение от Shamil1 Не нашёл в гугле такого стандарта модуля. Поэтому даже не могу его сравнить с другими языками. Например, с Си

два независимых модуля, способны компилироваться раздельно в объектные файлы.

0

Сообщение от castorsky одна функция для схожих типов, или схожие объекты каждый со своим методом?

В C# можно сделать одну функцию для схожих типов. Только схожесть должна быть документально подтверждена .
Какое это имеет отношение к модульности?
Можно ли в Хаскеле и в Си скомпилировать шаблонную функцию? Чтобы выделить её в отдельный модуль.

Сообщение от castorsky два независимых модуля, способны компилироваться раздельно в объектные файлы.

Вам шашечки или ехать? (если шашечки, то пакетность от модульности отличается )
Можно такое сделать, только код будет немного отличаться. (нужен код или верите на слово? только в C# не пакетные файлы, а сборки)
А если кто-то принесёт новый модуль с другой версией bar(), то модуль с foo() можно переключить на его использование - и даже пересобирать его не потребуется.
В Си/Хаскель, полагаю, такое тоже возможно?

0

Сообщение от Shamil1 Представляете, какой производительности может добиться программист, активно использующий копи-паст

Дык все копипастом и занимаются. Только одни сами копипастят, а другие заставляют копипастить компилятор.

0

хм, я уже и забыл за этот батл.

Сообщение от Shamil1 В C# можно сделать одну функцию для схожих типов

Я рад занего.

Сообщение от Shamil1 Какое это имеет отношение к модульности?

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

Сообщение от Shamil1 Можно ли в Хаскеле и в Си скомпилировать шаблонную функцию? Чтобы выделить её в отдельный модуль.

https://downloads.haskell.org/... skell.html
касательно языка Си - Вы его, очевидно, не знаете раз такую ерунду пишете. Это "почти ассемблер".

Сообщение от Shamil1 Вам шашечки или ехать? (если шашечки, то пакетность от модульности отличается )

Модульность в сях довольно условная. Но этот язык не претендует на высокий уровень.

Сообщение от Shamil1 Можно такое сделать, только код будет немного отличаться. (нужен код или верите на слово? только в C# не пакетные файлы, а сборки)

Я не говорил что что-то невозможно. Я вот что ООП не нужно - это да.

Сообщение от Shamil1 А если кто-то принесёт новый модуль с другой версией bar(), то модуль с foo() можно переключить на его использование - и даже пересобирать его не потребуется.

Это как бы преимущества не ООП, а дотнет платформы.

Сообщение от Shamil1 В Си/Хаскель, полагаю, такое тоже возможно?

Вы понимаете как исходник компилируется в нативный объектный файл? Если да, то зачем такие вопросы?

0

за этот батл.

Забавно Вы это воспринимаете.

Сообщение от castorsky такое что в данном случае модуль foo один (и экспортирует одну функцию foo), а методов для каждого объекта разных классов - 2.

О чём Вы? У меня создаётся впечатление, что Вы забыли, что в ООП методы могут принимать аргументы.

Сообщение от castorsky https://downloads.haskell.org/~ghc/7...e-haskell.html касательно языка Си - Вы его, очевидно, не знаете раз такую ерунду пишете. Это "почти ассемблер".

Просто ответить "да" или "нет" Вы не можете?
Читать статью про ненужный мне язык ради ответа на один простой вопрос у меня нет желания...

Сообщение от castorsky Я не говорил что что-то невозможно. Я вот что ООП не нужно - это да.

Нет. Вы именно говорили, что невозможно. Ваши слова были примерно такие: "Если есть объекты, то про модульность можно забыть." Да и потом Вы продолжали писать, что ОО языки не поддерживают модульность.

Сообщение от castorsky Вы понимаете как исходник компилируется в нативный объектный файл? Если да, то зачем такие вопросы?

Вам так нравится отвечать вопросом на вопрос? Просто ответить - да или нет - Вы не можете?

0

0

Сообщение от Shamil1 Забавно Вы это воспринимаете

Или юмор неудачный, или Вы его не поняли. Вероятно первое.

Сообщение от Shamil1 О чём Вы? У меня создаётся впечатление, что Вы забыли, что в ООП методы могут принимать аргументы

эмм, зачем тогда методам быть частью "объекта"?

Сообщение от Shamil1 Нет. Вы именно говорили, что невозможно

Это не мои слова (в смысле авторства). М.б. это тоже Я сказал? "Object-oriented programming is an exceptionally bad idea which could only have originated in California."

Сообщение от Shamil1 Да и потом Вы продолжали писать, что ОО языки не поддерживают модульность.

ОО как бы "втягивает" в себя модульность.

Сообщение от Shamil1 Просто ответить "да" или "нет" Вы не можете?

Сообщение от Shamil1 Просто ответить - да или нет - Вы не можете?

Не люблю быть кэпом /кэп

Добавлено через 1 минуту

0

0

Сообщение от castorsky эмм, зачем тогда методам быть частью "объекта"?

Это один из возможных способов организации кода. Причём, вполне удобный.

Сообщение от castorsky Это не мои слова (в смысле авторства).

Удобная штука интернет - можно легко найти единомышленников при любой точке зрения.

Сообщение от castorsky Не люблю быть кэпом

Если Вам что-то очевидно, то это не обязательно общеизвестно. Я вот, например, практически ничего не знаю про Хаскель. Но, видимо, ответ "нет, в хаскель/си этого нельзя сделать"?

0

Сообщение от Shamil1 Это один из возможных способов организации кода. Причём, вполне удобный.

Он удобен ровно до того момента когда проект вмещается в 2-4k строк.

Сообщение от Shamil1 Если Вам что-то очевидно, то это не обязательно общеизвестно

ok

Сообщение от Shamil1 Можно ли в Хаскеле и в Си скомпилировать шаблонную функцию?

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

Сообщение от Shamil1 В Си/Хаскель, полагаю, такое тоже возможно?

Очевидно же. Конечно да. А вопрос возник из незнания что такое объектный файл.

0

Сообщение от castorsky Поэтому вопрос: "можно ли скомпилировать шаблонную функцию?" лишен смысловой нагрузки. Это не нужно.

А потом сишники жалуются на слишком долгую компиляцию... Написал 100 строк, а компилируешь 10к строк. И возможность компилировать только то, что написал, им не нужна.

Сообщение от castorsky Он удобен ровно до того момента когда проект вмещается в 2-4k строк.

То есть, Вы считаете, что в проектах на 1к строк автоматическое освобождение ресурса - это удобно, а в проектах на 5к строк - уже неудобно?

Добавлено через 12 минут

Сообщение от castorsky Очевидно же. Конечно да. А вопрос возник из незнания что такое объектный файл.

А если модуль по сути должен реализовывать шаблонный интерфейс?

0

Сообщение от Shamil1 То есть, Вы считаете, что в проектах на 1к строк автоматическое освобождение ресурса - это удобно, а в проектах на 5к строк - уже неудобно?

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

Добавлено через 3 минуты

Сообщение от Shamil1 А если модуль по сути должен реализовывать шаблонный интерфейс?

То что? Какие-то особенности с компилированием шаблонов есть только в C++. Впрочем и сами шаблоны есть тоже только в C++, AFAIK.
И, казалось бы, при чём тут ООП?

0

Сообщение от Shamil1 А потом сишники жалуются на слишком долгую компиляцию... Написал 100 строк, а компилируешь 10к строк. И возможность компилировать только то, что написал, им не нужна.

Никогда такого не слышал. Плюсисты, да, жалуются (м.б. потому что объекты? хаха). В сях нет никаких шаблонов и абстракций вообще нет. Только pure lang & shared objects.

Сообщение от Shamil1 То есть, Вы считаете, что в проектах на 1к строк автоматическое освобождение ресурса - это удобно, а в проектах на 5к строк - уже неудобно?

Я вообще не могу понять с какой стороны тут оказалось raii. Я говорил о том что Вы называете "организация кода". Организовывать исходные тексты такм образом удобно ровно до какой-то черты. Лично Вы сколько уровней наследования способны запоминать? А теперь то же только для 4 классов нижнего уровня с учетом ромбовидности?

Сообщение от Shamil1 А если модуль по сути должен реализовывать шаблонный интерфейс?

А этот вопрос уже от незнания что такое модульность. В общем - сплошное незнание.

0

Сообщение от castorsky Я вообще не могу понять с какой стороны тут оказалось raii.

Вы спросили "зачем методам быть частью объекта". Это один из примеров.
Поняли теперь, зачем методам быть частью объекта? А то Вы как-то резко на другую тему перешли, что мне не ясно, поняли Вы или нет.
(Похоже, Вы изучали ООП давно и до сих пор представляете его в виде шаблонов типа ActiveRecord. Я ещё в своём первом сообщении в данной теме написал, что подобные шаблоны устарели, и что для хранения/передачи данных используют классы без методов)

Сообщение от castorsky Я говорил о том что Вы называете "организация кода".

В последних сообщениях Вы просто цепляетесь за слова. Выбираете в моём ответе слова, выдёргиваете их из контекста и придумываете комментарий.

Сообщение от castorsky Лично Вы сколько уровней наследования способны запоминать?

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

Сообщение от castorsky А теперь то же только для 4 классов нижнего уровня с учетом ромбовидности?

Этот вопрос Вам лучше задать тем, кто использует множественное наследование.

Сообщение от castorsky А этот вопрос уже от незнания что такое модульность. В общем - сплошное незнание.

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

Пример:
Есть модуль для сохранения данных в постоянном хранилище. Интерфейс: insert/update/delete/get/list. Гораздо удобнее сделать интерфейс с параметром типа и реализовать его в виде класса Repository<T> реализуещего методы insert<T>(T item) и т.д. Если есть сущности, для которых сохранение отличается, то мы создадим для них специальные классы, пронаследовав их от Repository<T>.

Добавлено через 11 минут

Сообщение от korvin_ И, казалось бы, при чём тут ООП?

Вы видимо не следили за нашей дискуссией, поэтому поясню.
castorsky, писал, что в ООП нельзя сделать "одну функцию для схожих типов", а можно только "схожие объекты каждый со своим методом". И, якобы, по этой причине ООП не совместимо с модульностью.

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

Кроме памяти есть ещё и другие ресурсы. Например, файлы, подключения к БД и так далее.
Это один из паттернов ООП, поэтому к ООП имеет самое прямое отношение.

0

Сообщение от Shamil1 Кроме памяти есть ещё и другие ресурсы. Например, файлы, подключения к БД и так далее.

Это не важно, RAII в C++ работает исключительно из-за обязательного вызова деструктора, в котором ресурс освобождается. В языках с GC нет деструкторов и соответственно освободить ресурс таким образом не получится.

Сообщение от Shamil1 Это один из паттернов ООП, поэтому к ООП имеет самое прямое отношение.

Это плюсовый паттерн, а не ООПшный.

0