Стоит ли использовать ООП?

Здравствуйте.
Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп?
Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами.
Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.

5

Сообщение от Fulcrum_013 А алгоритмы по любому завязаны на структуру данных которые они обрабатывают.

Абстрактно завязаны, ибо сам алгоритм есть абстрактная сущность, но которую можно выразить математически(множества состояний, сложность и т.д. ).

Сообщение от Fulcrum_013 ООП позволяет именно обойти жесткие завязки на данные заменив их завязками на абстрактные методы.

Которые жёстко привязаны к своим классам?
Тогда методы уже не будут абстрактны. Они же стали составной частью класса.
Абстрактный метод может работать с любой сущностью, на которую завязан абстрактно. В этом его сила.
Что такое абстракция? Это всего лишь заключение в одно обозначение некоего конгломерата функций, которые в свою очередь являются абстрактными обозначениями более мелких действий. Именно действий, а не данных!
Данные - сами по себе! Каждый тип данных самодостаточен сам по себе, поэтому его нельзя ни от кого наследовать.
ООП позиционировался как отображение окружающего нас мира. В мире есть (якобы) отдельные обьекты, которые (как бы) самостоятельно функционируют. Однако не принимается во внимание, что обьекты, являются потоком энергии, действия, а не статики. Там во всём одно лишь действие, - нет там статичных обьектов, которые можно было бы назвать статичными данными. Абстрактно наследуются действия, причём от действий же.. Наивысшая функция - точка, это - человек, последнее слово программы.. Данные скрыты, глубоко скрыты. Данные принадлежат всем. Данные - элементарные типы. Данные - вещество, функции - энергия. Энергия всегда выше данных, абстрактнее их, ибо данные сами по себе тоже производные этой энергии на самом низшем уровне.
Чем большее количество кода будет исполнятся под единственым обозначением, тем абстрактнее действие. Самое главное - отрешиться от низкоуровневых вещей, когда они уже обёрнуты в абстрактные оболочки, и функционировать уже там, на высшем уровне. Наращивание слоёв абстракций и есть функциональное программирование, а не то, чем его считают ныне. А в ООП всё вывернуто наизнанку мира..

0

Сообщение от CoderHuligan Наращивание слоёв абстракций и есть функциональное программирование, а не то, чем его считают ныне.

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

0

Сообщение от Fulcrum_013 Ну это как бы проблемы не ООП а этих псевдопрограммистов.

Скоро, кстати, в вашем любимом c++ будут удалены указатели, вот тогда наверно псевдопрограммистов станет в разы больше, что конечно хорошо, с точки зрения конкуренции, ибо низкоуровневые специалисты будут востребованы как никогда..https://habrahabr.ru/post/352570/#habracut

Добавлено через 2 минуты
Ой, забыл что сегодня 1 апреля.. Ну нехай живе

0

CoderHuligan, Главный вредитель в С++ - коммитет. Это с самого начала ясно было.

0

Сообщение от Fulcrum_013 Абстракция должна не наращиваться а конкретизироваться по определению абстракции.

Догма объектников.
Конкретизирование по определению ограничено своей сущностью, например классом. Поэтому такие обьекты не могут развиваться и свободно изменятся. "Сокрытие данных" некогда было обьявлено архиважнецкой вещью, и по всей видимости, нанесло индустрии непоправимый вред. Сокрывать нужно не данные, а функции, которые должны быть чёрными ящиками для других клиентов, но каждая функция должна заботиться не только о том, что у неё имеется на входе, но и о том, КУДА (не КОМУ) она отдаёт свой выхлоп. Принцип - ты мне, я - тебе. Так в природе принято. Там всё функционирует на взаимном узнавании, ибо если было бы иначе, вирусы уже давно погубили бы всё живое.

0

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

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


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

0

Сообщение от Shamil1 Проще время от времени проводить масштабный рефакторинг отдельных подсистем.

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

- недостаток "классовости" - да, есть такое дело. Ф-ции с 10 и даже 15 аргументами - дело рядовое, пользоваться ими весьма неудобно. Но дело не только в том что "нет классов", а может и "не столько". Другие вещи не менее важны, и на них уходит по крайней мере не меньше времени. С др стороны многое в тупеньком "процедурном стиле" пашет весьма удачно и лепить там классы неуместно

0

Сообщение от Igor3D Вот я его и провожу с прошлого августа

Сторонние продукты, типа ReSharper, используете?

0

Сообщение от CoderHuligan но и о том, КУДА (не КОМУ) она отдаёт свой выхлоп

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

Добавлено через 1 минуту

Сообщение от CoderHuligan Конкретизирование по определению ограничено своей сущностью, например классом. Поэтому такие обьекты не могут развиваться и свободно изменятся.

Во первых найдите 10 отличий между классом и объектом.

0

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

Представьте себе ситуацию.
Имеем функцию, которая принимает на вход тип указателя на динамическую строку, неважно какого устройства. Функция возвращает новую реаллоцированную строку, и при необходимости что-то туда записывает.
Возникает вопрос: если функция возвратит новый указатель на новую строку обычным образом(положит его в регистр EAX к примеру, в зависимости от платформы и соглашений) , то что делать с прежним входным указателем, если принимающая сторона не удосужится положить новый указатель в старый? А? Правильно - возникнет висячий указатель, как это ОЧЕНЬ часто бывает.. Поэтому, правильней и намного, передавать функции не просто указатель, а указатель на указатель, и возвращать его разыменовывая в функции. А кодом возврата возвращать ошибку либо успех! В этом случае никаких висячих ссылок не образуется, ибо функция "ложит" новый адрес в тот указатель, который получила на входе. Она это делает САМА, поэтому она в курсе КУДА отправляет выходной параметр!!

0

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

0

Сообщение от Fulcrum_013 Передаются при этом не сами указатели а объекты-холдеры по значению которые содержат указатель на буфер и осуществляют рефкаунтинг. Все.Никаких проблем в этом плане нет и никогда не было.

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

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

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

0

Сообщение от CoderHuligan Имеем функцию, которая принимает на вход тип указателя на динамическую строку, неважно какого устройства. Функция возвращает новую реаллоцированную строку, и при необходимости что-то туда записывает. Возникает вопрос: если функция возвратит новый указатель на новую строку обычным образом(положит его в регистр EAX к примеру, в зависимости от платформы и соглашений) , то что делать с прежним входным указателем, если принимающая сторона не удосужится положить новый указатель в старый?

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

0

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

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

Сообщение от Shamil1 Если функция изменяет строку, то передавать в неё нужно не указатель, а адрес указателя.

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

0

Сообщение от CoderHuligan Вызывающей стороне вообще не нужно думать об указателях.

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

0

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

0

Сообщение от Fulcrum_013 один раз пишем шаблонный класс "динамический буффер" который сам думает о указателях.

Тут ведь вот какая незадача: я лично не пишу на с++.. Я делаю это проще:
Это из моей библиотеки, которая находится в разработке(уже реализовано 18 функций). Вся низкоуровневая логика скрыта внутри функций, в том числе все проверки, работа с указателями, выделения памяти. Функции возвращают код ошибки или не ошибки.

0

Сообщение от Fulcrum_013 Shamil1, один раз пишем шаблонный класс "динамический буффер" который сам думает о указателях.

Я отвечал на более общий вопрос, когда речь ещё не шла о буферах.

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

0

В функциях скрыта и логика проверки с какими строками она работает - с сишными строками или с dms строками.

Добавлено через 1 час 44 минуты
Как видно, в функцию передаётся адрес указателя, то есть образуется косвенность вызова, а это позволяет в функции изменить указатель. dms строки имеют magic-поле, по которому можно определить отличие от сишной строки. Magic-поля довольно обычны в структурах, которые описывают различные типы файлов, однако применительно к динамическим строкам, я такого не встречал. Это очень удобно, хотя и увеличивает длину строки, но кто сейчас думает об экономии 4 лишних байтов?

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

0

Сообщение от CoderHuligan Это очень удобно

Ещё удобней везде в системе использовать один и тот же формат.

0