О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

Говнокод тоже обычно работает, но от этого не перестает быть говнокодом. А если ты про «быстро-качественно-дешево», то да, обычно дай Б-г если удается выбрать два из трех.

Там был не шаблонный класс, смысл его существования был непонятен вообще никому, кроме автора(который на момент разборок «нафига это всё» уже и в конторе-то не работал).

Один генеративный (property-based) тест.

Да, интересная тема. Почитал тут.

Понравились комментарии:

makc3d
31.03.2020 в 00:23
постойте, return 3 всё ещё успешно проходит equal(sum(1, 2), sum(2, 1))

Fen1kz
31.03.2020 в 05:41
Ну как так-то, 2 строчками ниже:

const rand = Math.random
const [n1, n2] = [ rand(), rand() ]

const actual = sum( n1, n2 )
const expected = sum( n2, n1 )

equal(actual, expected)

makc3d
31.03.2020 в 11:27
Вы не поверите, но и такой тест return 3 тоже проходит :D

До 3 версии в php небыло толкового ООП

Толкового? До 5.

В 3 версии классы и объекты были скорее ассоциативными массивами.

Причины: не хотели удлинять время сборки скриптов

Тогда особо сильного спроса не было. Разработчики были заняты переписыванием интерпретатора (а до третей версии у него даже название другое было).

«Цель жизни политиков — сделать нам на зло, чтобы нам хуже жить было»

"Цель использования ООП — сделать программе зло, чтобы она еще хуже была"

такой тест return 3 тоже проходит :D

Ну так проверяется только одно свойство функции сложения — коммутативность. Можно добавить, скажем, проверку свойства «сумма неотрицательных чисел не меньше любого из слагаемых».

Можно, конечно, сказать, что я схитрил и проверка двух свойств — это уже два теста, соответственно, с треугольником тоже потребуется не один тест.

Старинный фармакалогический справочник

Вы ещё труды про четыре жидкости Гиппократа почитайте.

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

Хабр помойка. Не читай там ничего.

Вот хорошо изложено про property based tests:

https://www.youtube.com/watch?v=IYzDFHx6QPY

Стоимость проекта — это же расходы. А капитализация вроде как должна отражать ожидаемые доходы

Должна? Кому она должна? Это прошлый век, нынче капитализации определяется пролюбленными деньгами, а не приобретенными. Вон, у Slack убытки растут в геометрической прогрессии, как и капитализация. Учись, будешь успешным бизнесменом.

Одного хватит,только интервальные входные сетапить надо

Егор Бугаенко, перелогиньтесь!

Вон, у Slack убытки растут в геометрической прогрессии, как и капитализация.

Растут и убытки, и ожидаемый поток доходов. Долго это не продлится, но вообще быть вполне может.

Хотя, может, ты просто забыл табличку «сарказм» показать %)

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

Рано или поздно работа с ООП постоянно натыкается на конфликт: как передать контекст объекту

«контекст» — это один из моих любимых шаблонов, поэтому я его часто передаю по объектам :):

«Ядро Линукс» активно использует ООП через glib-подобный костыль

Это два из принципов grasp, низкая связность и высокое зацепление вот как раз без них никак в ноомальном коде!

О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

О какого рода объектном ориентированном программировании речь идет?
Если исходить из https://ru.wikipedia.org/wiki/Объект_(программирование)

Объект, наряду с понятием класс, является важным понятием объектно-ориентированного подхода.  
Объекты обладают свойствами наследования, инкапсуляции и полиморфизма[1].  

то нельзя сказать, что это плохо или хорошо.
Иногда уместно, иногда нет.
Вот делать из этого идола - ПЛОХО.
struct является хорошим фундаментом для создания объектов разной архитектуры.
Более того, достаточно одного void …
Плохо то, что один из множества возможных архитектур объектов сделали - ИДОЛА.
Проще говоря поставили перед собой высокий забор, который не дает увидеть того, что классы а-ля C++
являются всего лишь одним из возможных способов создания архитектуры объектов.
Вот это действительно

ПЛОХО

Растут и убытки, и ожидаемый поток доходов. Долго это не продлится, но вообще быть вполне может

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

Ты сейчас как бы смеешься, как бы «ну так это ж МММ», но Tesla или Slack или Uber от них отличаются только тем, что вместо бесполезных фантиков выпускают бесполезные гробы на колесах. Да, Марводи до такой многоходовки не додумался — а там гляди уже и государство начнет бюджетные деньги отдавать только ради того, чтобы твой бизнес продолжал свое существование.

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

Еще раз повторяю: человек, у которого есть способности к ходьбе, просто берет и сам учится ходить; если человека специально учили ходить, если он может вам очень много рассказать по теории ходьбы, то с большой вероятностью перед вами калека. Это в том числе к слову о музыкантах, которые могут вам перечислить по памяти все названия аккордов.

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

низкая связность и высокое зацепление

Напридумают противоречивых терминов, потом пытяются объяснить, и не получается. :)

Тут скорее надо термины из теории графов (связность) использовать.

Плохо то, что один из множества возможных архитектур объектов сделали - ИДОЛА.

«Угораздило» меня несколько постов опубликовать …

Такое ШОУ отличное было

Sorry

Если утиная типизация не подходит так как надо использовать статическую типизацию

Одно другому не противоречит:

module Duck_tales =
  struct
    class little_duck (name : string) =
      object
        method quack = name ^ " quacks"
      end
 
    let huey  = new little_duck "Huey"
    let dewey = new little_duck "Dewey"
    let louie = new little_duck "Louie"
  end
 
module Disney =
  struct
    let donald_duck =
      object
        method quack = "Donald Duck quacks"
      end
  end
 
module Ducks_client =
  struct
    type duck = <
      quack : string
    >
 
    let sound (d : duck) = print_endline d#quack
  end
 
let _ =
  let ducks = [
    Duck_tales.huey ;
    Duck_tales.dewey ;
    Duck_tales.louie ;
    Disney.donald_duck
  ] in
  List.iter Ducks_client.sound ducks

— https://ideone.com/sWbMXJ

вухаахх так это же все для каждого случая может подойти лучше своя парадигма...
но нельзя оспаривать тот факт — что когда тебе необходимо сохранять какойто стейт — то без ООП никак не получится нормально разрешить. Использовать extern вместо ООП — вот это самый настоящий каламбур и секта. Как и использовать #define вместо constexpr для объявления констант (а еще лучше использовать enum class вместо этого всего).

И в чём разница? Что вызов будет выглядеть как method(object), а не object.method()?

а чо — у ТСа получилось — он хотел словить хайп в теме — и словил.

Усложнение архитектуры — часть развития, проект написания ядра линукс был начат в те времена, когда процедурной парадигмы вполне хватало для написания ядра

Ламера, они такие. Если что, сразу «это было никогда», ага. Просто-напросто ООП в массе говно, smalltalk что-то не прижился (я его считаю эталоном в реализации) в массах хомяков.
Учиться новому массы не хотят - сложна. А кто протолкнулся дальше, тот передать информацию не может, некуда положить.

А что такое DI? А в чём разница? И как ТЫ видишь на своём примере?

их разводили все эти годы

Ну никто их не разводил. Просто они что выучили, то и внедряют там где надо и где не надо.

А шаблоны проектирования тоже классная штука: фабрика фабрик обзерверов и всё в таком духе. :)

И в чём разница?

Синтаксический сахар

method(object):
    object.a = object.b + object.c

object.method():
    a = b + c

ооп это фп для бедных.

О вреде ООП надо говорить! Это - слишком важная тема, чтобы отмалчиваться.

https://www.youtube.com/watch?v=PpGcsrsyBjQ&ab_channel=3Com100

Вы панике не поддавайтесь.  
Спасайтесь!  
Организованно!

когда тебе необходимо сохранять какойто стейт — то без ООП никак не получится нормально разрешить

Зачем хранить состояние приложения в одном месте? Давайте размажем его по всему мясокомбинату, так ведь веселее.

Просто-напросто ООП в массе говно

В какой ещё массе? Это парадигма, применять её надо исходя из задачи.

smalltalk что-то не прижился

А джава прижилась, что с того?

Эээээ, наконец то понял кого Огурцов напоминает.
У нас сотрудник есть - «копия» Огурцова /рост, комплекция, лицо, речь, …/.

А джава прижилась

Извратив ООП до «современного понимания ООП». Зато наплодив кучу «очередей сообщений». Тем временем сами «очереди сообщений» ближе к изначальной идее ООП.

ImGui::Text(); ImGui::Button(); ImGui::InputText(); ImGui::SliderFloat()

А ImGui значит не класс со своими методами? Может по другому называется, но суть – ООП.

Раствор этилового спирта – до сих пор один из базовых антисептиков в медицине.

Использование этанола для наркоза устарело к XIX в. и в наши дни это только экстренная медицина (антишоковая терапия), если никаких более безопасных средств нет.

И в чём разница? Что вызов будет выглядеть как method(object), а не object.method()?

Ого, а меня ещё троллем обзывают!

Меньше кода, меньше файлов, более оптимальное хранение данных (как в базе данных).

Вот простой пример: HTML-CSS-Javascript. Там нет никаких классов. HTML - это просто база данных элементов (не объектов), и никто из них не «знает» как себя отображать. Отдельными файлами могут идти CSS которые описывают как отображать эти элементы. И отдельно могут идти Javascript файлы, которые могут влиять на дерево элементов, на стиль и на всё прочее.

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

Я понимаю, эта тема слишком сложная. Может показаться что создана ради хайпа. Но нет, это реально большая проблема. С ней даже связан термин Bloatware.

Вот простой пример: HTML-CSS-Javascript.

Поинтересуйтесь что там под капотом. Сплошные классы и ООП, причём давно.

Без ООП проект такой сложности просто не напишешь.

более оптимальное хранение данных

Или менее оптимальное.

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

Если обходим по строкам, то хранить массив структур выгоднее.

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

Если у нас нет массивов объектов, то DOD вообще не применим.

В Zig можно прозрачно для пользователя создать массивы каждого элемента структуры, с помощью метапрограммирования: https://youtu.be/tdgkdOui_uU?t=339

не понимаю я тебя — ты же хранишь в нужный момент стейт только определенного необходимого компонента программы — в том то и весь смысл — что бы не хранить все подряд все время.

вухахахах ага — хайп ты отличный нагнал...

С ней даже связан термин Bloatware.

Bloatware не имеет отношения к ООП.

С ней даже связан термин Bloatware.

Bloatware не имеет отношения к ООП.

Зато ООП имеет отношение к Bloatware!

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

Тучу выделили на ПВО, переходящую в ПРО, более 50 лет назад.

И не знали чем занять всю эту ораву физиков. Вот и придумали способ - ООП. Код растёт, зарплаты начисляются…

Не путай причину со следствием.

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

И конечно у всего есть минусы. Но это работает.

В последнее время пытаются использовать ФП. Есть проекты с сотнями тысяч строк на ФП, и работают, но будет ли маштабироваться ФП хотя бы до уровня сегодняшнего ООП ещё не известно. Возможно и будет, но там есть свои проблемы…

Вообще то я тоже считаю ООП очень сложной парадигмой. Неоправданно сложной … Как приедете, раскрою вам свою теорию поглубже ...

Владимир

Выскажусь по этой животрепещущей теме. Проблема не в ООП как таковом, а в объектно-ориентированных ЯП, которые жестко навязывают конкретную объектную модель памяти. Например, в С++ можно управлять семантикой памяти через PoD/StandardLayout, а в Java объектная модель на столько сильно «прибита гвоздями» к языку, что обойти её технически невозможно (прямую работу с массивами не берем в счет), не ломая саму JVM (sun.misc.Unsafe).

Технически, проблема с ООП состоит в том, что «объекты» не подходят для построения аналитических приложений. Последним нужна модель SoA, тогда как объекты по умолчанию дают AoS (array of structures), что очень плохо ложится на иерархию памяти (кэши).

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

У меня есть пример расширения объектной семантики, который я использую для data objects в Мемории.

Предположим, у нас есть десятичное число с произвольной точностью, Decimal(precision, scale). В обычном, привычном нам, ООП, оно, скорее всего, будет представлено в виде объекта-обертки над массивом чисел и двумя параметрами (precision и scale).

Все очень хорошо, пока мы храним свои объекты исключительно в куче. Во внешнее хранилище их так просто не положишь.

Ок, мы даем View-интерфейс в Decimal, который дает доступ к его внутреннему состоянию. И теперь мы можем быстро сохранять и восстанавливать данные этого объекта.

Но, данные — не объект. Если мы хотим произвести операции с объектом (прочитать его, например), мы должны восстановить объект из данных. А это, как минимум, копирование и преобразование формата. Бонусом, правда, идет возможность хранить различные фрагменты данных объекта отдельно друг от друга. Например, для таблицы параметры (precision, scale) будут, скорее всего, одинаковы. Поэтому нет необходимости физически хранить их вместе с цифрами для каждого Decimal (как это было бы, если бы мы делали всё в куче).

Для задания и управления такими объектами уже нужен не один указатель на данные в памяти (this), а сразу несколько. Т.е. примерно так:

DecimalParams* params_ptr = ...;
DecimalDigits* digits_ptr = ...;

std::cout << DecimalView(params_ptr, digits_ptr) << std::endl;

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

Однако, мы теперь отделяем данные объекта Decimal (DecimalParams, DecimalDigits) от его поведения (DecimalView). И мы можем этой, уже просто, семантикой управлять отдельно, легко реализовывая в конечном итоге дружественный к железу и аналитическим приложениям паттерн Structure of Arrays.

В частности, такой Decimal я могу хранить где угодно и как угодно, и, если формат хранения совпадает с форматом обработки, то у меня zero copy между хранилищем данных объектов и, собственно, кодом, эти объекты использующим.

Минусом является то, что в такой модели сложнее реализовывать семантику владения памятью объектов (так как жизненный цикл View не связан теперь напрямую с жизненным циклом памяти), но тоже можно.

В Мемории этот паттерн называется SparseObjct («разреженный по памяти объект») и является разновидностью Mixin. В С++ это всё делается более-менее изящно, так как составной указатель просто прячется за zero-cost abstractions. В Java всё сильно сложнее, но ребятам, делающим Presto, более-менее удалось этот паттерн тоже реализовать.

И, последнее. Переходить от семантики объектов к семантике данных  — это вовсе не значит «вылечить ООП». Семантика данных куда сложнее и богаче семантики самих объектов, и сразу потянет за собой очень забористый «матан» — теорию информации со всеми её кодировками и продвинутыми структурами данных. Мы просто, образно говоря, «выпускаем джина из бутылки» объектов, которая сейчас закупорена инкапсуляцией.

Тем не менее, такой переход я считаю неизбежным. У меня есть свой экспериментальный форк Clang, куда я буду постепенно переносить удачные наработки из Мемории и поддерживать их на уровне языка (где С++ сам не справится) и базовых библиотек.