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

@@KOT@ · Регистрация: 29.01.2010

Студворк — интернет-сервис помощи студентам

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

@TRam_ · 22.09.2017, 02:42

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

@pycture · 22.09.2017, 05:45

Сообщение от Shamil1

Проблема в том, что я не знаю, можно ли использовать ф111 вместо ф123.

это надуманная проблема т.к.

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

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

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

функция не описана значит ее нет - пиши свою.

@Shamil1 · 22.09.2017, 10:25

Сообщение от pycture

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

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

Сообщение от TRam_

А речь шла именно об обдумывании логических частей процесса, с написанием прототипов функций

Совсем не похоже на "сверху-вниз".
Разбиваем задачу на несколько более простых шагов/подзадач. Затем повторяем с каждой из подзадач. Если текущая подзадача выглядит достаточно простой, то пишем код без дальнейшего разбиения.

@pycture · 22.09.2017, 10:44

Сообщение от Shamil1

если я провожу декомпозицию по функциональности, то мне нужно будет просматривать только функции требуемой специализации

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

@Shamil1 · 22.09.2017, 13:56

Сообщение от pycture

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

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

@korvin_ · 22.09.2017, 20:53

Сообщение от Shamil1

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

И как это связано с направлением проектирования?

@Shamil1 · 23.09.2017, 15:19

Сообщение от korvin_

И как это связано с направлением проектирования?

Не с направлением, а с методом. "сверху-вниз" - это метод проектирования. И у этого метода есть недостаток, который я упоминал выше. Другой метод - ООП - более-менее решает эту проблему.

@pycture · 23.09.2017, 17:46

Сообщение от Shamil1

Примерно как между просмотром паблик методов одного класса и просмотром паблик и приват методов всех классов.

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

@korvin_ · 23.09.2017, 21:13

Сообщение от Shamil1

Другой метод - ООП - более-менее решает эту проблему.

Не решает. И ООП ортогонально проектированию «сверху-вниз» или «снизу-вверх».

@Shamil1 · 24.09.2017, 08:23

Сообщение от korvin_

ООП ортогонально проектированию «сверху-вниз»

Видимо, под проектированием "сверху-вниз" Вы понимаете не то, что я.

@korvin_ · 24.09.2017, 10:53

Сообщение от Shamil1

Видимо, под проектированием "сверху-вниз" Вы понимаете не то, что я.

Видимо. Что ты под этим понимаешь, и какое это имеет отношение к ООП?

@Fulcrum_013 · 19.10.2017, 01:17

Сообщение от CoderHuligan

как абстрактный общий тип данных

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

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

Сообщение от Shamil1

Видимо, под проектированием "сверху-вниз" Вы понимаете не то, что я.

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

@CoderHuligan · 19.10.2017, 13:29

Сообщение от Fulcrum_013

Абстрактный как раз и означает что его нельзя использовать напрямую

Тогда он бессмысленнен.

@Shamil1 · 19.10.2017, 14:43

Сообщение от Fulcrum_013

С применением ООП снизу вверх проектировать можно разве что

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

з.ы. Основное достоинство проектирования сверху вниз в том, что думать не надо, можно сразу начинать писать. А основной недостаток в том, что пишешь, не подумав.

@ILinker · 09.11.2017, 19:28

Да, однозначно стОит.

@Fulcrum_013 · 01.01.2018, 13:36

Сообщение от Shamil1

Основное достоинство проектирования сверху вниз в том, что думать не надо, можно сразу начинать писать. А основной недостаток в том, что пишешь, не подумав.

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

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
    class TEntity {
    private:
        HINTERNET FHandle = nullptr;
    protected:
        void DestroyHandle() {
            if (FHandle) {
                WinHttpSetStatusCallback(FHandle, nullptr, 0, 0);
                WinHttpCloseHandle(FHandle);
                FHandle = nullptr;
            }
        };
        virtual HINTERNET DoCreateHandle() = 0;
        virtual void HandleEvent(long Status, void* StatusInfo, long StatusLength) = 0;
        static  void CALLBACK HandleProc(HINTERNET ObjHandle, DWORD_PTR Object, DWORD Status, void* StatusInfo, DWORD StatusLength);
        TEntity() {};
        void CreateHandle() {
            if (FHandle) return;
            FHandle = DoCreateHandle();
            WinHttpSetStatusCallback(FHandle, &TEntity::HandleProc, WINHTTP_CALLBACK_FLAG_ALL_NOTIFICATIONS, 0);
            void *Ptr = this;
            WinHttpSetOption(FHandle,WINHTTP_OPTION_CONTEXT_VALUE,&Ptr,sizeof(Ptr));
            
        };
    public:
        AnsiString Name;
        virtual ~TEntity() { DestroyHandle(); };
        HINTERNET GetHandle() { if (!HandleAllocated) CreateHandle(); return FHandle; }
        bool   GetHandleAllocated() { return FHandle != nullptr; }
 
        operator HINTERNET () { return Handle; }
 
        __declspec(property(get = GetHandle)) HINTERNET Handle;
        __declspec(property(get = GetHandleAllocated)) bool HandleAllocated;
    };

т.е. известно что оно хэндл. извесно что оно как то создается и как то удаляется. тому что создано нужно установить калбэк. что и описано. Как именно оно создается и удаляется - это уже ниже по иерархииб потому что не известно на данном этапе.

@Shamil1 · 01.01.2018, 20:21

Сообщение от Fulcrum_013

В ООП программист делает абстрактный класс

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

@Fulcrum_013 · 02.01.2018, 07:24

Сообщение от Shamil1

Большинство программистов таким опытом не обладают.

А никто и не говорит что ООП это инструмент быдлокодера. Напротив ООП это инструмент профессионала. Ну и опять же в квалификации/должности слово инженер имеет свойство стоять на первом месте а программист на втором. Да он за примерами далеко ходить не надо - те же Delph/Builder считаются быдлоформошлепками только по той причине что в СНГ явно недостаточно спецорв способных вести разработку расширением фреймворка а не навешивать бизнес-логику на обработчики кнопок. Там же оная формошлепка практически монополист в сфере создания внутреннего софта крупных корпораций. А к быдлоформошлепкам относят WPF и т.п. не преспособленные к расширению фреймверка.

Сообщение от Shamil1

А для этого нужен опыт

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

Сообщение от Shamil1

Большинство программистов таким опытом не обладают.

Ну это как бы проблемы не ООП а этих псевдопрограммистов. Да кстати за бугром программист давно уже не обязательно инженер. К примеру на позиции быдлокодеров (developers или programers) особенно web особенно frontend особенно Java и JavaScript большинство вакансий требует образования школа. Наивно полагать что у них такой опыт/знания будут. Но как бы и инженерами-программистами и даже инженерами-техниками их считать нельзя. А вот тот кто инженер-программист (Software Engineer) тот без оного опыта диплом фиг получит. При этом за время обучения в ВУЗе предостаточно возможностей оный опыт получить.

@pycture · 03.01.2018, 16:37

Сообщение от Fulcrum_013

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

А к быдлоформошлепкам относят WPF и т.п. не преспособленные к расширению фреймверка.

ищо! на бис!

@WH · 31.03.2018, 11:01

В опросе не хватает одного пункта - Стоит, но не всегда ))

Кстати, есть ли совсем не большие задачи, года ООП оправдано? Ведь обычно манипулируют терминами - "для больших задач". И напротив, есть ли большие задачи, когда ООП не нужно?

Результаты опроса: используете ли вы ооп
да	238	86.55%
нет	37	13.45%
Голосовавшие: 275. Вы ещё не голосовали в этом опросе

Новые блоги и статьи Все статьи Все блоги /
SUNO Ai - Река Без Дна zorxor 31.07.2026 Автор стихотворения - астрофизик Марина Катыс Ссылка на сгенерированную музыкальную композицию: https:/ / suno. com/ song/ 6f6e5464-b290-4650-be6c-44c85f8d8013 Я говорю, что Время- как вода течет. . .	Из невошедшего на форум (диалог с ИИ-гугла) zorxor 29.07.2026 А вот, что интересно, сказал мне ИИ-гугла: Этот текст — эмоциональный пост пользователя под ником zorxor на интернет-форуме (вероятно, посвященном мистике, непознанному или альтернативной науке). . . .	Был праздник вчера, а я и не знал. kumehtar 28.07.2026 27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет Новости компьютерного мира и их обсуждение (4) Салют, шампанское, овации! :drink:	Нейтральные знания, чистый код - бла-бла-бла-бла, на самом деле кликбейт и самореклама, плагиат, и вот почему Hrethgir 27.07.2026 То-есть отклонение такой публикации говорит само за себя, и пусть только возьмут на вооружение после отклонения публикации - это будет чистейшим актом плагиата. Отклонял Хабр. Дословно, отклонённая. . .
тв 16 бой ии anaschu 27.07.2026 Великий Перелом ИИ: Как уравнения ОДУ Radau дожали цензурные фильтры Алисы Фиксируем в мемофонде Теории Всего беспрецедентный факт в истории ИИ-зондирования. В затяжном многораундовом. . .	мв 15. непроверенное, возможно, глюк anaschu 27.07.2026 НАУЧНО-АНАЛИТИЧЕСКИЙ ОТЧЕТ. РАЗДЕЛ 1. 1: «НАУКА» (РАСШИРЕННАЯ СТЕХИОМЕТРИЧЕСКАЯ И ГЕНЕТИЧЕСКАЯ ВЕРСИЯ)Тема: Теоретическое обоснование инвариантности 19-мерного тензорного ядра непрерывных ОДУ и. . .	Очистка реквизитов и табличных частей документа при копировании (вариант 2) Maks 26.07.2026 Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРаботу", разработанного в КА2. Задача: Заменить алгоритм запрета копирования документов для сотрудников с ролью "Стажер",. . .	Доктрина интенционального знания - Доктрина для портала "Срез". Hrethgir 25.07.2026 Может найдётся кто захочет оценить доктрину. . . Написания правил участия для меня роскошь, требующая лимита времени, поэтому все сообщения не прошедшие модерацию будут видны только участникам портала,. . .

@@KOT@ 81 / 39 / 3 Регистрация: 29.01.2010 Сообщений: 386

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

@TRam_ зомбяк 1585 / 1219 / 345 Регистрация: 14.05.2017 Сообщений: 3,940
	22.09.2017, 02:42
	Shamil1, это если вписывать заглушки в код в процессе его написания. А речь шла именно об обдумывании логических частей процесса, с написанием прототипов функций, и уже последующей компоновкой их в виде заглушек в код. 0

@ILinker Фриланс Pascal/Delphi etc 67 / 73 / 16 Регистрация: 25.11.2016 Сообщений: 263
	09.11.2017, 19:28
	Да, однозначно стОит. 0

@WH 1589 / 817 / 192 Регистрация: 10.09.2013 Сообщений: 3,293 Записей в блоге: 3
	31.03.2018, 11:01
	В опросе не хватает одного пункта - Стоит, но не всегда )) Кстати, есть ли совсем не большие задачи, года ООП оправдано? Ведь обычно манипулируют терминами - "для больших задач". И напротив, есть ли большие задачи, когда ООП не нужно? 0