ООП - в топку!

Цитата D_KEY @ 20.05.19, 18:03

Я не спорю с представлением об ООП.

Ты отрицаешь его наличие.

Цитата Flex Ferrum @ 20.05.19, 18:07

А отсылать к Бочу или Мейеру - зачем?

Я читал, спасибо. Неплохое описание практик

Добавлено 20.05.19, 18:11

Цитата Qraizer @ 20.05.19, 18:08

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

Именно. Согласен.

Добавлено 20.05.19, 18:12

Цитата Flex Ferrum @ 20.05.19, 18:07

И статьи очередного неосилятора на хабре.

Статья хреновая, кстати.

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

Цитата Flex Ferrum @ 20.05.19, 18:17

В таком случае процедурного

Разбиение программы на процедуры.

Цитата

функционального

Представление процесса вычисления в виде вычисления функций в математическом смысле. Хорошо формализовано.

Цитата

аспектного

Практически не применял и очень мало знаю.

Цитата D_KEY @ 20.05.19, 18:21

Разбиение программы на процедуры.

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

Цитата D_KEY @ 20.05.19, 18:21

Представление процесса вычисления в виде вычисления функций в математическом смысле.

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

На самом деле, не ясно, чем тебе тогда да хотя бы Кеевское определение ООП не устраивает. Выглядит как простая упёртость в стиле двойных стандартов. Ну или, проще говоря, жопа есть, а слова, получается, нету. Будем называть "жопу" как набор признаков: две булки, щель между ними, а в щели - анальный сфинктор.

Мда. Любая хрень с этими признаками безусловно будет жопой. Вот только жопа не обязательно обладает этими признаками. Иногда это завтра дидлайн.

Цитата D_KEY @ 20.05.19, 18:21

Представление процесса вычисления в виде вычисления функций в математическом смысле. Хорошо формализовано.

То есть нельзя программировать функционально не в математическом смысле? А что такое вообще "математический смысл"? Дай определение, будь ласка

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

Лично я, в последнее время избегаю термина "ООП" в аргументации. По мне, разделение проходит по оси императивность/функциональность, так как именно на этой границе рвутся шаблоны из-за иммутабельности и (прости господи) чистоты функций.

Сообщение отредактировано: applegame - 21.05.19, 09:14

Цитата applegame @ 21.05.19, 07:30

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

Наша жизнь с тем же успехом событийно-ориентирована Так что в топку это все, давайте писать код

Ну так ООП - это про дизайн, а не про императивщину/функциональщину.

Цитата Flex Ferrum @ 21.05.19, 07:36

Ну так ООП - это про дизайн, а не про императивщину/функциональщину.

Так и он про

Цитата applegame @ 21.05.19, 07:30

разделение проходит

И в чем-то прав, поскольку разделение, по крайней мере в мозгах программистов, нынче проходит именно тут.

Цитата Астарот @ 21.05.19, 07:40

И в чем-то прав, поскольку разделение, по крайней мере в мозгах программистов, нынче проходит именно тут.

Да. В этом он прав. Но ООП - оно ведь вообще не про это, если рассудить то. ООП про то, как дизайнить. А имплементить ты можешь хоть императивно, хоть функционально, хоть квадратно-гнездово на CSS... Поэтому и вопрос D_KEY'я (про кусок кода) немного, гм, странен.

Цитата applegame @ 21.05.19, 07:30

Лично я, в последнее время избегаю термина "ООП" в аргументации. По мне, разделение проходит по оси императивность/функциональность, так как именно на этой границе рвутся шаблоны из-за иммутабельности и (прости господи) чистоты функций.

+1

Добавлено 21.05.19, 10:22

Цитата Астарот @ 21.05.19, 06:49

А что такое вообще "математический смысл"? Дай определение, будь ласка

https://ru.m.wikipedia.org/wiki/Функция_(математика)

Добавлено 21.05.19, 10:30

Цитата Flex Ferrum @ 20.05.19, 19:35

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

Есть повод или нет, но разделение четкое.

Цитата

На самом деле, не ясно, чем тебе тогда да хотя бы Кеевское определение ООП не устраивает.

Тем, что в узком смысле под него не попадает почти ничего из существующих систем (а большинство языком не имеет поддержки ООП). А в широком - почти все из существующих
Бесполезное определение.

Цитата

Ну или, проще говоря, жопа есть, а слова, получается, нету. Будем называть "жопу" как набор признаков: две булки, щель между ними, а в щели - анальный сфинктор.

Так а что делать, если сторонники того, что у ООП есть четкое определение, вместо того, чтобы его озвучить, как раз занимаются перечислением признаков и еще учат, как дизайнить по ООП

Добавлено 21.05.19, 10:32

Цитата Flex Ferrum @ 21.05.19, 08:27

Поэтому и вопрос D_KEY'я (про кусок кода) немного, гм, странен.

Зависит от того, ради чего задается вопрос

Цитата D_KEY @ 21.05.19, 10:18

Так а что делать, если сторонники того, что у ООП есть четкое определение, вместо того, чтобы его озвучить

Озвучивал. Здесь: ООП - в топку! (сообщение #3799452)

Прекрасное определение. Если тебя оно не устраивает - Значит, чего-то ты перестал понимать. Или не хочешь. Или толсто троллишь. Ещё раз (для тех, кто в танке). ООП - это не про написание кода. Это про его дизайн. Писать ты можешь хоть на ассемблере, хоть в машинных кодах с любой подходящей для этого парадигмой.

Цитата Flex Ferrum @ 20.05.19, 15:59

Расскажи, как применяются принципы SOLID при процедурном подходе.

S — каждая процедура выполняет «что-то одно».
O — для любой процедуры можно написать другую, с такой же сигнатурой, выполняющую какой-то дополнительный код + код исходной процедуры. Также можно воспользоваться замыканиями, если язык позволяет.
L — такая расширенная процедура будет являться (с некоторыми оговорками, справедливыми, впрочем и для классов) подтипом оригинальной. Также можно воспользоваться замыканиями, если язык позволяет.
I — см. S, всё аналогично.
D — передача процедур/указателей-на-процедуры как параметров в другие процедуры.