Интерфейс - это класс, все методы которого абстрактные.

Интерфейс — это структура, полями которой являются указатели на функции.

Как раз сегодня снились упоротые битвы покемонов.

>>201947
Ну это при реализации в Си, наверное. В плюсах это структура без полей, но с таблицей виртуальных методов.

>>201957
Просто к сведению, что на Си тоже можно писать в стиле ООП, но это еще то извращение.

>>201958
У нас городской ежегодный фестиваль "Ночь музыки", пришлось выпить припасенную для гостей бутылку сидра.

>>201959
Какое совпадение, у меня был неучтенный вермут:3
Залипаю за новерем.

>>201958

> ядро Линукс — извращение

Еретик!

>>201943
Прекрасный. Дефолтная вакаба

>>201963
Помню ещё, программа начального старта (аналог Sun`овского OpenBoot PROM) для двух линеек отечественных процессоров написана в таком же стиле.

Инерфейс это междулицо.

>>201963
Так и знал что будут разговоры про линукс. Там может это и оправдано, но в эмбедеде, например, не очень. Хотя встречал и такое.
Да, и, вообще, достаточно коряво это все выглядит. Приходится постоянно передавать в метод ссылку на объект, иначе функция просто не знает с чем работать. По сравнению с ООП ориентированными языками это все костыли.

>>201986
Не, это не костыли, а как раз таки наоборот, оригинальный паттерн, который может быть довольно громоздким, а может и не быть. В ООП вся эта механика, которую именуете костылями, оптимизирована, автоматизирована и скрыта.

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

Хотя, в связи с ориентированностью только на один объект, ООП-языки типа Java начинают лагать, когда нужно провести сценарий над двумя объектами.
То есть, например, взять какую-нибудь Циву или Монополию, где юнит переходит на клетку, и с ним, и с клеткой от этого что-то происходит в зависимости от типа юнита и типа клетки. Тут, получается, для запуска нужного сценария по идее должна быть трёхмерная таблица виртуальных методов, что-то типа scenario[cellType, unitType](cell, unit). Но так делать нельзя, потому что инкапсуляция наше всё и менять что-то извне — грех, сравнимый с использованием goto, и потому что автоматическая таблица виртуальных методов может быть только по одному типу, а не по двум сразу.

Возникает также проблема: пихать метод наступания юнита на клетку в класс юнита или в класс клетки. Оба друг друга меняют, и главного во взаимодействии выделить нельзя. В любом случае, в таком методе будет гора if-ов типа if(unit is SettlerUnit), либо гора if(cell is SettlerManglingCell), либо разбивка на очень узкоспецифичные виртуальные методы, распиханные по разным файлам и нацеленные на взаимодействие только с конкретным типом или аспектом типа юнита/клетки, переиспользование которых без copypaste-ы при изменении типа юнита/клетки затруднительно. Полиморфизм в таком случае продаждает быть пыткой.

>>201990

>грех, сравнимый с использованием goto

https://beza1e1.tuxen.de/articles/when_goto_is_fine.html

>>201990

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

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

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

>>201990
>>201992
ооп это хуета для обезьян. появилось оно как возможность тупому манагеру притвориться что он "понимает" суть проектируемой системы, не вникая в её суть.

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

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

как же я, сука, ненавижу миддлмэнеджмент.

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

>Возникает также проблема: пихать метод наступания юнита на клетку в класс юнита или в класс клетки.

все современные двиглы перешли на ECS, которая и есть тот самый дата-дривен, о котором я вам твержу. есть системы(то есть по сути функции), есть компоненты которые этими системами обрабатываются. а гей-дизайнеры там уже собирают из компонентов юниты под конкретный геймплей.

>>201998
Чень, а как писать функционально? Структуры в С это можно, или нельзя? А если аккуратно?

>>202001
не писать, а проектировать. в рамках продюсер - данные - трансформация - консумер.

структуры, и даже интерфейсы, это просто способ описать формат данных, обрабатываемых функцией.

>>202001
Сначала берёшь какой-нибудь лисп. Потом пишешь в нём что-нибудь строго в рамках ФП на функциях высшего порядка или рекурсии. После того, как достигаешь сути того, как перемалываются при этом подходе данные, берёшь и переписываешь пайплайн на си, тут уже главное - не следить за чистотой ФП, а вбухивать ФП с контролируемой мутацией где можно. Я такой код называю вырожденным кодом - он вроде бы на глаз без мутаций, но снизу в том же map! данные меняются, а не создаются новые.

>Структуры в С это можно, или нельзя? А если аккуратно?

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

Если дойти до деталей, то рекурсия (или letrec) выражается в while с мутацией входных аргументов и возвращаемого значения, а замыкания заменяем на явно прописанный аргумент в функции обратного вызова (можно указатель на структурку с данными, вообще во всём этом деле проще жонглировать указателями, а не данными) и сперва пишутся простенькие map, fold, filter со списками или в чём ты там будешь жонглировать данными.

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

>>202076
а чё просто вареник не заюзать, в котором уже есть эти мап фолд итд?

уважаю твою дисциплину с двумя языками, однако сам так делать не хочу.

>>202079

>в котором уже есть эти мап фолд итд?

Спрашивали в >>202001 про си, ответ был тоже про си. Написать свой простенький map, fold и так далее на си - это просто, проще, чем выдержать код в нужном стиле. Для того, чтобы научиться выдерживать - тут надо доставать язык, сделанный для того, чтобы на нём писали по законам ФП и на нём практиковаться.