Когда использовать ООП?

Когда проект коммерческий и когда у бизнеса, когда поток людей - приходят и уходят .. то лучше ООП

А когда проект для души или стартап или Cuting Edge - там хоть хаскель с чистой философией и функциональщиной без ооп

Как раз таки Haskell лучше подходит для ком. проектов, так как рефакторить легче, чем technical debtкакаху, которая остается после ушедших разработчиков.

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

Я за 37 лет не встречался с ситуациями, когда применение ООП было бы оправдано. Допускаю, что такие случаи существуют в природе, но полагаю, что они крайне редки.

Domain Driven Design, Clean Architecture и всех этих дядюшек Бобов и Банд четырех

Ты всё в кучу смешал. Банда четырёх это набор паттернов. Это надо, но они эти паттерны просто описывают. Совсем не обязательно их применять. Просто иногда это к месту, иногда не к месту. Знать надо в любом случае.

А «дядюшка Боб» это информационный цыган. Он впаривает дичь. Не надо его слушать вообще.

Читай Гради Буча.

читай то, читай это, а программировать-то когда?

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

Сложные «иерархии» функций это сплошь и рядом — все состоит из функций, которые вызывают друг друга. Но ф-ция это примитив, почти как if или for а ООП абстракция гораздо высшего порядка.
То же самое относится и к модулям — это примитивная,базовая вещь для композиции, а ООП нет. Да, некоторые языки (напр. Python) делают модули достаточно сложными (вложенными, модуль это объект) но это уже их проблемы.

Где находится та грань, когда нужно использовать ООП?

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

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

Если ты про всякие думы, во-первых, тогда альтернатив особо не было, C++ до сих пор ходил пешком под стол, Ada с т.з. фич тоже, а всякие Smalltalk и прочие Eiffel были слишком тормозные для 3D в реальном времени. Во-вторых, некоторые базовые фичи ООП хочешь-не-хочешь изображали на сишке, костыльно и вручную.

Так как же поступать? Как применять инструменты правильно?

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

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

Вообще, ООП - это про состояние и связанное с ним поведение

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

Стоит попробовать выйти за пределы баш портянок.

Попробовать например qt, c#, java

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

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

Почему именно взамен?

Та же шкалка например. Целиком и полностью оопешная, но умеет из функциональщины много всего. Правда вот велью тайпс там на куче))) а от реализации кортежей я в свое время дико ржал, но кого это волнует

Java мой основной ЯП.

Не заметно.

Прошу показать мне код на жявке без ооп🤣

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

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

А. Понял.

Такой парадигмы я думаю нет и еще не скоро она появится.

Все текущие актуальные парадигмы существуют паралельно.

И никто и не стремится заменять ооп чем то другим.

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

Даже тут

System.out.println

Это ооп

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

обьекты в ооп, это просто понятия, а объекты реального мира - это лишь частный случай.

чтобы избавиться от ооп, надо избавиться от понятий. такие люди есть. это шизофреники.

пример речи шизофреника

Родился на улице Герцена, в гастрономе номер двадцать два. Известный экономист, по призванию своему — библиотекарь. В народе — колхозник. В магазине — продавец. В экономике, так сказать, необходим. Это, так сказать, система… э-э-э… в составе ста двадцати единиц. Фотографируете Мурманский полуостров и получаете «Те-ле-фун-кен». И бухгалтер работает по другой линии — по линии библиотекаря. Потому что не воздух будет, академик будет! Ну вот можно сфотографировать Мурманский полуостров. Можно стать воздушным асом. Можно стать воздушной планетой. И будешь уверен, что эту планету примут по учебнику. Значит, на пользу физике пойдёт одна планета. Величина, оторванная в область дипломатии, даёт свои колебания на всю дипломатию. А Илья Муромец даёт колебания только на семью на свою....

А поскольку понятия содержатся в любом коде, то любой код — это ООП. Ловко!

никогда

А оно точно надо? Вот, например, в иудаизме есть целостная парадигма, регламентирующая все аспекты жизни, от выской духовности, до кулинарных советов и требований как по субботам зубы чистить и задницу подтирать. А христиане как-то без этого обходятся. И не страдают. Так может и тут, ну эти целостные парадигмы. Есть разные соображения, основанные на опыте и здравом смысле, а уж как их применять в конкретном случае — дело мастера.

Это встроенный API.

Он в Java далёк от идеала, тут соглашусь. Особенно то, что проектировали давным давно, в самых первых версиях.

Но вообще для тебя, видимо, и сишный struct это ООП. Тут ты не прав.

Если говорить более предметно, то ООП это:

1. Объединение данных и методов. Это плохо, этим пользоваться не надо, данные и алгоритмы должны быть разделены. Естественно это не значит, что нельзя использовать поля, это философский пункт. Сделать сеттер с валидацией значения это нормально, сделать класс-сервис, у которого поля сервисы, инициализируемые по принципу IoC, это нормально. Сделать класс, который в себе хранит данные и сам же умеет их сохранять в БД, это уже ненормально.

2. Защита данных, разделение реализации и представления. Это нормально.

3. Использование интерфейсов и классов-реализаций. Это бывает полезно, много паттернов на этом строятся. Это нормально.

4. Наследование интерфейсов. Это тоже нормально.

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

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

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

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

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

программа не произведение искусства, а продукт

Всё ещё неочевидна необходимость очередного всепобеждающего единственноверного учения, дающего ответы на все вопросы.

с нужными потребительскими свойствами.

А тут уже уже скорее к организации процесса вопросы, нежели к деталям реализации, как конкретно программисты накодят.

Использование композиции вместо наследования это что то из книжонки толи блоха толи эккеля. Читал я это все.

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

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

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

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

уж сколько раз твердили миру. композиция не равно наследованию. композиция это отношение - состоит из. пример - «автомобиль состоит из двигателя, 4 колес, кабины…» тут используется композиция.

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

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

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

Мастер токарного цеха задумчиво чешет тромбон.

Ты удивишся сколько мусора пропихивают в «библиях жявы».

И статические билдеры вместо сеттеров. И много чего еще.

И начитавшись этого - это тянут в код.

Отдельный апофеоз это творение бугаенко конечно…

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

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

Ada с т.з. фич тоже

В Ada область основного применения накладывает драконовские ограничения на фичи, тот же равенскар профайл, потому что «надежность фёст», а все остальное, в т.ч. удобства программистов – по остаточному принципу :)

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

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

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

… Отдельный апофеоз это творение бугаенко конечно…

Бугаенко приезжал в Нижний Новгород пару недель назад с докладом об открытом исходном коде и его разработке. Находясь в должности руководителя на зарплате на крупнейшем китайском предприятии в Москве, Егор призывал всех желающих работать над его открытыми проектами совершенно бесплатно. И кто-то ведь работает, наверное.

Я забил на всю эту околожявашную тусу после того как меня забанили в их чятике за то что я осмелился перечить их божествам.

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

Получается, что ООП необходим чуть более чем всегда

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

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

У классов есть один или несколько конструкторов. Интерфейсы же в отличии от классов не определяют, как объект должен создаваться, то есть нет такого понятия как контракт конструктора выраженный в интерфейсе. Поэтому, без абстрактных базовых классов вам будет сложно построить вменяемый дизайн приложения. Например:

abstract class Animal(val name: String)
class Dog(name: String) : Animal(name)
class Cat(name: String) : Animal(name)

fun main() {

    val listAnimal = listOf(Dog("Dog"),
        Cat("Cat"),
        object : Animal("Anonymous Animal"){}
        )
    listAnimal.forEach{
        println(it.name)
    }
}

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

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

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

Поэтому люди и страдают от ООП в современных реалиях.

Ты так говоришь, как будто ты один в современных реалиях живешь. В моей современной реальности нет такой проблемы как «страдание от ООП»

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

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

тсссс

это ты еще им про дженерики не рассказал

наличие которых это просто имба и ради которой зачастую и городят иерархию абстрактных классов с интерфейсами

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

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

это ты еще им про дженерики не рассказал

дженерики

Ненужная бесполезность.

и ради которой зачастую и городят иерархию абстрактных классов с интерфейсами

А это одно из подтверждений бесполезности генериков.

Откуда ты взял «имба» вообще неясно.

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

почитать кого-нибудь из классиков, например, Мартина Фаулера

хочешь угадаю

ты програмулькер на go*не или няшной-дыряшной сишке?

ни на чем он не программирует

Использовать ООП когда в нём. Для того чтоб разобраться делаете две вещи.

1. Читаете книгу https://www.poodr.com/, можно первую версию.
2. Смотрите на Youtube лекции Sendi Metz.

После этого вы разбиаетесь во всех типах ООП.

Где находится та грань, когда нужно использовать ООП?

В книге все написано, в лекциях все рассказано.

омфг писать книгу по ооп взяв как пример руби…..