>>967453 (OP)
>Инкапсуляция в ООП. Ну пиздец же. Сам от себя свой же код прятать.

Не от себя лол, а от пользователей твоих классов, тебе что проще, вызвать у библиотечного класса метод или разбираться, как он устроен изнутри?

>>967453 (OP)

в етом ИТТ треде мы выяснили что новомодные анальные игрушки для быдляков ПИСТОН и ХАЧКЕЛЬ

сосут у олдфажных мега языков на все времена C-шки и perl-а все время

лучий вариант на ПИСТОНЕ: http://ideone.com/udDJ9 (императивный понос)

2 варианта на ХАЧКЕЛЕ

ебаный пиздец во всех смыслах и имеперативное гавнище: http://ideone.com/M42su (сосет у C-шки)

деклашотивное петушение http://ideone.com/0e3qE (сосет у декларотивного петушения на perl)

для сравнения

perl: http://ideone.com/i0ob4 http://ideone.com/olq5B

C: http://ideone.com/ap43H

LUA: http://ideone.com/DVdhr http://ideone.com/Xkj4D

http://ideone.com/6cZYq лисп как и ожидалось сонул, ну и возможно ответ неправильный

(какието черезжопные варианты с 33 кратной вложеностю скобок быле побыстрее но натая хуйне никому не сдалась когда есть простое и самое быстрое решение на C-шке)

>>967453 (OP)
лисперы как дети
придумываюи всякую хуету, дают ей красивые названия навроде "лямбда" "функция высшего порядка" "первокласный обьект" и всем
заявляют что ето алмазы которых нигде больше нет.
а если приглядется и почитать ихнюю невнятную документацию то видиш что никакие ето не алмазы а стекляшки которых полно на
улице валяется

>>967453 (OP)
монады ето динамический массив содержащией еллементы любых типов
такое есть во всех быдлокодерских языках
а в лиспах ничего кроме монад нету
вот они на них и молятся, пишут книги, дрочат, сочиняют сказки и легенды

>>967453 (OP)
Подписался на годный тред. Унижаем адептов ООП и ФП в этом ИТТ тренде! Только КОП, только юнити-ультра-хардкор!

Годный трет от го-довена.

>>967453 (OP)
>Инкапсуляция в ООП. Ну пиздец же. Сам от себя свой же код прятать
Это скрытие ненужных деталей за минимальным интерфейсом.

Или у тебя кран на кухне загромождён огромным количеством водопроводных труб, вентилей в разные квартиры и счётчиками воды вперемешку?

>>967453 (OP)
Самое петуханское: любая браузерная фронтопараша.

/thread

>>967453 (OP)
>Инкапсуляция в ООП. Ну пиздец же. Сам от себя свой же код прятать.
Была уже в 50-е, даже задолго до ЕС ЭВМ.

>>967704
Двачаю.

Но лучше всего как в Питоне, чтобы private функции отличались от public лишь формально (там ведь так, да?). То есть есть методы "бери и используй", а есть "тут нужно понимать внутреннюю структуру, но тоже можно вызвать, если очень надо".
Чтобы не было лишней ебли со всякими private наследованиями, дружественными классами и прочим.

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

>>967453 (OP)
>Лямда-программирование
Чего, блять? Если кукарекать, то правильно. Читай по губам, ОП-хуй: лямбда функции

Алсо, тред до сих пор не обосрал наследование. Плохой тред

>>967453 (OP)
>Инкапсуляция в ООП. Ну пиздец же. Сам от себя свой же код прятать.
Тебя тоже бесит что внутренние органы спрятаны под кожей и мышцами, и нельзя сделать себе прямой массаж сердца?

>>969009
Что плохого в наследовании?

>>967453 (OP)
питухон
и
т
у
х
о
н

>>969080
Неприменимость в продакшне.

>>967459
Ну а если мне всего то переменную взять надо? Делать геттер? Пиздец какой-то, его надо делать когда действительно нужно, а не когда можно.

>>969004
Ненужно, для дебажки есть gdb, IDA.

>>969082
Немношк неправ. Если ты начинаешь писать код "с нуля", то тебе нужно постепенно двигаться от простого объекта к сложному, наследуя все свойства и методы предыдущего. Пример: ректангл->сёрфейс->поле->выпадающий список. И всё это единообразно пишется на буфер экрана, потому что методы создания/уничтожения наследуются от самого от ректангла

>>969178
А теперь мне нужно сделать радиальное меню а не выпадающий список. Или сёрфейс у меня треугольник, а не прямоугольник.

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

Говнище же

>>969227
Предложи вариант лучше? Микромодульная система?

>>969290
Интерфейсы/контракты вместо наследования. Интерфейс/контракт имеет единственную область ответственности. Интерфейсы/контракты склеиваются друг с другом композицией.

Есть интерфейс ISelector, в котором есть список опций и текущее выбранное значение.
Есть интерфес ISelectorPresenter с функциями GetRadialMenuDrawables(ISelector) и GetDropdownMenuDrawables(ISelector), на выходе которых ты получаешь список говна, которое тебе надо отрендерить. Есть рендерер, который отвечает только за рендер списка говна.

>>969309
Слушай, годно. Решает многие проблемы ООП, кстати. Но явно передавать по цепочке объект иногда слишком долго. Особенно если у тебя в техдоках архитектом чётко описан функционал каждого куска (в пример: Для разработчиков интерфейса требуется дропдаун с мультиселектом под GUI-библиотеку библиотекасобственнойразработкидлякофеварокподлуа, дропдаун должен быть написан на чтонибудьсиподобное с целью улучшения подддерживаемости и сопровождаемости кода и реализовывать следующие возможности: длинный список говна от UI-шников), то проще сделать это объектами

>>969374
Расскажите вашему архитектору про SOLID как-нибудь.

>>969380
Не, ну круто, как будто никто не знал этого. Но реально так никто и никогда не пишет, как прошлый архитект делал, так и следующий делает, а потом следующий за ним... Это как дедываивале-дедыговножрале, только в ИТ.

>>969400
Рассказываешь архитектору про МИКРОСЕРВИСЫ, что так сейчас модно и все так делают. Архитектор соглашается, ты уходишь делать свой микросервис с блекджеком и барышнями.

>>969082
Если твой "продакшн" - это лаба2, то там наследование не нужно, согласен.

>>969553
Если твой продакшн содержит 5м строк кода и наследование в 5 уровней, то там вообще ничего не нужно. Это неподдерживаемый пиздец.

>>969572
Мой продакшен содержит 5м строк в 1 классе в 1 файле. Я все правильно делаю?

>>969578
Да. Продолжай в том же духе.

>>969580
Вот и я так думаю, а все эти ваши наследования, абсракции и интерфейсы - это всё от лукавого.

>>969572
> 5 уровней наследования, сложна, сложна блядь, нихуя непонятно

>>969596
5 больше 3, а 3 уже много. Как обычно, прыщеглазик опозорился. Надо было 20 писать минимум, а то и 50.

>>969309
Интерфейсы - это конечно пиздато, но мне нужно внутреннее поведение наследовать. Пример: 2 класса процессоров сообщений из очереди абсолютно одинаково работают с кешем, но сам метод Process() реализован по разному. Так нахуя мне дублировать код, м?

>>969605
передай процессор сообщений в конструкторе. Будь мужиком - используй DEPENDENCY INJECTION

>>969606
Тогда чем это принципиально будет отличаться от ФП?

>>969606
Туда и так передается ICache. Или надо еще одну сущность ДоставательИзКеша написать и интерфейс к ней, и ее инжектить. Охуенная бритва Оккама.

>>969608
Процессор значит передавай, лол
>>969607
Тем, что все "лямбда-функции" у тебя заменены на интерфейсы и поименованны.

>>969611
Нихуя не понял, куда надо передать процессор в данном примере
https://pastebin.com/K1NKnT77

>>969619
Хули у вас всё так сложно?
https://pastebin.com/ru3dZN6d

>>969624
Т.е. поведение должно зависеть от того как создан инстанс, а не от типа? Ебать ты АРХИТЕКТОР.

>>969626
Подожди, мы же не создаем инстансы, они достаются из контейнера с помощью контейнерных гномов.

>>969626
Естественно. Ты вот этого послушай >>969627, он шарит

>>969627
Какая разница, кто их создает. У тебя два инстанса одного типа отличаются поведением. Если ты тут не чуешь подвоха, то он тебя сам найдет на этапе отладки и тестирования. Кстати, что ты там выше пиздил про интерфейсы, а сам передаешь в конструктор какую-то ссаную лямбду.

>>969630
Какая разница какой у них тип?

>>969630
Наследование + тестирование? А вы, батенька, извращенец.

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

>>969633
Стало все просто и понятно
https://pastebin.com/zNTFs4V3

>>969634
Поздравляю. Ты понял всю суть ООП. Теперь можешь устраиваться сениор девелопером на 500к в месяц в любую контору. И замени ICache на ICache<T>. А то параша получается.

>>969634
поэтому передай Func<T> и не выёбывайся

>>969635
Я пока только на 180к синьор. Хорошо что у меня в команде нет таких мастеров архитектуры.

>>969638
Я правда не понимаю, что с этим кодом не так. Ну кроме интерфейса ICache, у которого сейчас слишком много методов Get.
Ты жил в крестовом лесу последние 10 лет и концепция IoC для тебя является асральной магией?

>>967453 (OP)
>я не умею в лямбды
>я не умею в ООП
>все, кто умеет в лямбды и ООП - пидоры
Ок, держи в курсе.

>>967453 (OP)
Большего говна чем Java технологии не видел. Хотя Gradle и сам язык вполне себе кошерны.

>>969670
Проблема в том, что в лямбды и ООП не умеют очень многие, но они всё равно их пытаются применять. Не потому что нужно, а потому что иначе все будут считать их неквалифицированными программистами. Вот и хуярят их везде. А ОПу (да и мне, собственно) от этого печёт.

>>969670
Я так же не умею в анальных секс с кавказцами. Держу в курсе.

>>969728
Ты, главное, не сдавайся. Если много пытаться - обязательно получится.

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

>>969731
Если логически дальше идти, то и обычные функции не нужны. Ебашь всё в мейне, не инкапсулирй переменные в свою область видимости, ебись с кавказцами.

>>969742
все, кроме сама - не нужно синтаксический сахар

>>969746
асма, естественно

>>969742
Так не иди дальше. Можно же пойти еще дальше, а там перфокарты.
А можно пойти вперед, и запихнуть в джаву/питон/шарп префиксную нотация, и сказать збс вышло, вункциональщина во все поля, экономия на длине записи, ебну один раз знак умножения вместо трех, * 3 4 5, ура, товарищи! Нахуя только?

>>969747
Машинных кодов тогда уж.

>>969749
Потому что код var disabledAccounts = accounts.Where(account => account.Disabled) читается в отличие от варианта без лямбды

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

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

>>969752
Они тоже не нужны, только логические вентили, только ХАРДКОР!

>>970713
Контакты проволочкой замыкать

>>969731
какой юзлес синтаксис лошара блять :3
А ну-ка пиздуй лабы доделывать

>>967464
>ихнюю
быдло в треде

>>971580
Ньюфаг в треде.

>>971580
Училка по русскому на дваче

>>972007
Пруфы будут?

нейронные сети, хуета на рэндоме

>>967453 (OP)
>инкапсуляция нинужна
И тут я понял, что жирно.
Или оп просто никогда не слышал про интелисенс, который будет подсказывать самому же программеру, что он может использовать
Вот у тебя 100 полей, из которых тебе нужно каждый раз выбирать только 2, а остальные ты использовать вне класса даже не собираешься. Зочем тогда они тебе нужны в выпадашке?

А так сделал их приватными и не мозолят они тебе глаза. А как же ридонли поля? Как ты их без инкапсуляции сделаешь? Напрмер, в либе.

>>972167
Если у тебя в классе 100 полей то у меня для тебя плохие новости.

>>972167
>100 полей
Чую синглтон.

>>972196
Пора вам уже узнать про контейнерных гномов.

>>972178
Ты серьезно все буквально воспринимаешь?
Допустим класс ты делаешь, у которого одна цель - десериализовать в себя json.

>>972178
Да хоть 1000 полей, почему ты буквально воспринимаешь?
Даже 10 полей глаза мозолят.

>>972285
>>972283
обосрался с постами, но мысль, надеюсь, выразил понятно.

>>969083
Геттер далеко не всегда просто возвращает свойства класса. Проще всегда делать его, потому что хуй знает, когда тебе понадобится сделать его более умным.

>>969083
Потому что иначе тебе не нужны классы, просто пиши все в глобальной области и дергай переменные по имени, то есть программируй, как это делали 30 лет назад

>>967453 (OP)
>ИТТ обсуждает самые петуханские технологии и техники програмирования
Вим, линукс дома.