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

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

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

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

@DenQ · 06.09.2013, 19:16

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

Igor3D, как я понял, вы хотите сказать, что ООП слишком много кушает памяти, ресурсорв? Особенно в руках горе программистов?)
Это уже задача компиляторов. Вот к примеру jit-компилятор, развязывает запутанный код программиста и делает из него более простой.. и так несколько раз подряд... из простого, к еще более простому...

@Igor3D · 07.09.2013, 13:27

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

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

Да, но то палка о двух концах

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

Igor3D, как я понял, вы хотите сказать, что ООП слишком много кушает памяти, ресурсорв? Особенно в руках горе программистов?)

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

@DenQ · 07.09.2013, 17:50

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

Освоение "чудесных принципов" не ведет к успеху автоматически

Если я правильно понял, вы о паттернах проектирования?
Тут я и соглашусь и не соглашусь. Дело в том, что я глубоко убежден, что паттерны нужны не столько для того кто создает приложение, а для того кто будет в нем разбираться.
Мне часто доводилось видеть архитектуры сайтов, построенные по каким-то неведомым законам(да что там - я и сам когда-то так писал). В таких сайтах очень тяжело разобраться. Пусть даже если сам код написан красиво.
Паттерны, парадигмы и само ООП как парадигма необходима для реализации по настоящему больших проектов. ИМХО.

@MolodoyCoder · 08.09.2013, 23:47

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

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

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

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

В ООП программировании нет абсолютно глобальных переменных.

Самые "глобальные" переменные могут быть видны только в пределах своего класса
Потом идут "менее глобальные переменные" , которые могут быть видны только в пределах методах. Т.е. между { }
И наконец самые локальные переменные, "живут" только в пределах циклов.

Получается что в ооп все данные и методы (читай процедуры классов) четко разделены этими самыми классами.

Но если полезть дальше в абстракции, то можно сказать в опп программировании и есть тоже в условном смысле глобальные переменные. Это любые паблик члены самомого общего класса Main Programm. Ну это уже словеса.

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

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

ВСЕ СКАЗАННОЕ, МОЕ ИМХО.
Не навязываю.

@DenQ · 09.09.2013, 03:21

MolodoyCoder, из всего выше сказанного, мне не ясно, вы за или против ООП?

@alex_x_x · 09.09.2013, 03:24

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

Разумеется они существуют и для не ООП

в привычном виде они существуют только для ООП, на самом-то деле

@MolodoyCoder · 09.09.2013, 03:28

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

MolodoyCoder, из всего выше сказанного, мне не ясно, вы за или против ООП?

ранее писал, и сейчас повторюсь - определенно "ЗА".
Удобная штуковина, которая позволяет навести порядок.

@korvin_ · 09.09.2013, 07:40

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

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

Это зависит от языка и программиста. В C можно писать без глобальных переменных.

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

В ООП программировании нет абсолютно глобальных переменных.

То же самое. В Java/C# можно писать с использованием глобальных переменных. Классы в большинстве своем глобальны.

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

Получается что в ооп все данные и методы (читай процедуры классов) четко разделены этими самыми классами.

В процедурном программировании все данные и методы четко разделены по модулям/пакетам/библиотекам. В чем разница?

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

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

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

@MolodoyCoder · 09.09.2013, 16:00

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

В Java/C# можно писать с использованием глобальных переменных. Классы в большинстве своем глобальны.
Это позволяет сделать тот или иной язык, модель вычисления тут как бы не при чем.

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
35
36
37
using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;
 
//это не стработает - ошибка
String testvariable = "fig vam a ne globalnost";
 
namespace MaurganMath
{
 //и тут не сработает - тоже оошибка
    String testvariable = "fig vam a ne globalnost";
 
 
    static class Program
    {  
       // а вот отсюда уже будет работать
        String testvariable = "fig vam a ne globalnost";
 
 
        /// <summary>
        /// Главная точка входа для приложения.
        /// </summary>
        [STAThread]
 
 
        static void Main()
        {
 
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            Application.Run(new Form1());
        }
 
 
    }
}

@taster · 09.09.2013, 16:09

ООП дисциплинирует. Использовать его лучше везде, даже в небольших приложениях. Ведь все приложения рано или поздно изменяются/усовершенствуются. А ООП дает большие преимущества в этом деле.

@korvin_ · 09.09.2013, 16:13

И что ты хотел сказать этим кодом?

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
using System;
 
class SomeForeignClass
{
    public void Ololo()
    {
        Test.GlobalVar = "Ololo";
    }
}
 
public class Test
{
    public static string GlobalVar = "Global";
    
    public static void Main()
    {
        var o = new SomeForeignClass();
        Console.WriteLine(GlobalVar);
        o.Ololo();
        Console.WriteLine(GlobalVar);
    }
}

http://ideone.com/4twJev

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

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

Использовать его лучше везде

Даже когда оно не нужно?

@taster · 09.09.2013, 16:18

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

Даже когда оно не нужно?

А в каких конкретно случаях оно может быть не нужно?

@korvin_ · 09.09.2013, 16:21

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

А в каких конкретно случаях оно может быть не нужно?

Например в математических расчетах; в символьных вычислениях.

@Igor3D · 09.09.2013, 19:01

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

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

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

Эти переменные называются "локальные". С ними все ясно. Что каксается глобальных, то напрасно Вы думаете что их число становится намного меньше с ООП. Делать переменную глобальной или нет диктуется соображениями задачи, а не стиля. Напр мulti-threading очень быстро и хорошо лечит от избытка гллюальных переменных

Исключая локальные - практически все переменные есть члены каких-то структур данных, без особой разницы назывются они классами (как в ООП) или нет. Решающее значение имеет насколько хорошо эти структуры построены.

@MolodoyCoder · 12.09.2013, 03:01

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

Напр мulti-threading очень быстро и хорошо лечит от избытка гллюальных переменных

оПА! сПАСИБО! Буду знать! А то не подумал.
...
Всё равно с ооп, всё как-то понятней. Так здорово, когда сзодал класс. Там свойства. И Private методами
все там организовал. И аккуратно наладил связь, private с public. Ч
А потом генеришь объекты от класса.... А классы строишь на основе уже созданных если надо... И т.д.
Красссоооттааа!

Не знаю, честно, почему многие задаются "Стоит ли использовать ооП ?"
Как буд-то за ооп, деньги надо дополнительно платить ...
Это все равно что, спросить "Стоит ли наводить порядок в своем жилище ?"

помню начинал писать на purebasic. Только не смейтесь, плиз...

Так вот, куча процедур...Ужас. Ну да. Я все расписал. Убрал повторяемость кода. Комментариев расставил.
Так получилось такое жуткое "полотенце" из кучи процедур. Всё как-то линейно в основном, и скучно. И при большом католичестве строк, монотонно. Фу. Гадость.

@korvin_ · 12.09.2013, 07:49

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

Это все равно что, спросить "Стоит ли наводить порядок в своем жилище ?"
помню начинал писать на purebasic. Только не смейтесь, плиз...
Так вот, куча процедур...Ужас. Ну да. Я все расписал. Убрал повторяемость кода. Комментариев расставил.
Так получилось такое жуткое "полотенце" из кучи процедур. Всё как-то линейно в основном, и скучно. И при большом католичестве строк, монотонно. Фу. Гадость.

Мда... «Разруха не в клозетах, а в головах». Что мешало разбить «полотенце» по разным файлам, сгруппировав процедуры?

@MolodoyCoder · 12.09.2013, 08:28

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

Мда... «Разруха не в клозетах, а в головах». Что мешало разбить «полотенце» по разным файлам, сгруппировав процедуры?

была мысль. Но даже по файлам, на HDD, в голове они бы у меня были все равно как на полотенце...+понимание,что в целом я для себя исчерпал Purebasic...

А вот к ооп я приблизился в дельфи. За что ему спасибо! Огромное.

Но и на дельфи не задержался:
1.Он достаточно дорогой, даже в базовой версии. Точно не помню, но XE4 -бесплатного нет.
2.begin ...end дольше печатать чем { } (это конечно я условно и шутливо намекаю)
3.Интуитивно тянуло к чему-то си-подобному.

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

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

Пока ни чего не могу сказать дурного про ооп, одни радости. учитывая, конечно свой скромный уровень.

@Нитонисе · 27.12.2013, 12:37

Довольно долго пытался осознать принципы ООП. Читал много литературы, пробовал использовать. И все равно не смог понять тех преимуществ, которые ООП дает.

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

Вообще некоторые базовые принципы ООП привлекают. Например бывают коллекции разных объектов, которые все прячутся за одним абстрактным типом, но каждый по своему реализует какое-либо действие. Ну, классический пример с абстрактным классом Shape и наследниками Circle, Rectangle, Triangle. У базового класса есть виртуальная функция Draw(), которую наследники реализуют каждый по своему. Такое полиморфное поведение я понимаю и вижу его преимущества.

Но декларированы еще преимущества от инкапсуляции - сокрытия внутренних данных. И вот это я не могу понять хоть убейте. Мы прячем данные в разделе private класса якобы для того, чтобы защитить данные от изменения. Но при этом в public даем метод Set(). Черт возьми, ну какое же это сокрытие данных, если любой программист который использует данный класс, все равно может изменять эти приватные данные. В чем смысл?

При этом очевидным образом усложняется доступ к данным - нужно использовать метод Get(). Да, согласно принципов ООП нужно в одном классе компоновать данные и функции работы с этими данными. Но зачастую функции, которым могут понадобиться эти данные, нарушают уровень абстракции. То есть логика объединения данных в класс одна, но какой-то приватный аргумент этого класса используется в других вычислениях другого класса и там приходится использовать метод Get(). И такое встречается сплошь и рядом. Потому что переменные взаимодействуют между собой в очень разных сочетаниях. Рекомендуется в класс выделять 7 +/- 2 переменных. Но учитывая сложный характер их взаимодействия - их нужно все скинуть в один класс.

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

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

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

@snake32 · 27.12.2013, 13:45

Сообщение от Нитонисе

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

Set и Get не обязательны для каждого свойства. Одни свойства могут быть только для чтения, другие - для чтения/записи. По мимо этого само свойство может не дублировать себя в приватной части полем. То есть в классе можно выделить публичную сущность которая не занимает место в памяти. Для примера можно взять класс Circle(окружность) который в приватной части содержит поле FRadius - радиус. Объявить публичные свойства: Radius и Length(длина окружности). Для радиуса как обычно Get и Set к полю FRadius. А для Length метод Get может выглядеть так: Result := Radius*2.0*pi; и Set так: Radius := value/(2.0*pi); то есть значение вычисляется в рантайме и не занимает память, но снаружи класса Length видится как обычное свойство с типом плавающей точки.
Вообще, любой Get и Set может приводить к глобальным изменениям внутри класса, но снаружи этого не должно быть видно дабы не забивать программисту голову лишней инфой - ему и так проблем хватает. В этом и есть смысл.

Думаю, логичнее начать разработку нового класса вообще без свойств. Все необходимые данные размещать как публичные поля. Как только появляется задача при которой изменение конкретного поля влияет на внутренности класса, то смело нужно превращать это поле в свойство. При этом имя свойства наследует имя поля, а к имени уже приватного поля обычно добавляется префикс(в delphi это F, в с++ встречал m_). При этом все внешние обращения к полю/свойству останутся как и прежде. Тогда, по-идеи, не должны возникать вопросы вида зачем нужны пустые Get и Set.

Убежденный · 27.12.2013, 17:18

Сообщение от Нитонисе

Но декларированы еще преимущества от инкапсуляции - сокрытия внутренних данных. И вот это я не могу понять хоть убейте. Мы прячем данные в разделе private класса якобы для того, чтобы защитить данные от изменения. Но при этом в public даем метод Set(). Черт возьми, ну какое же это сокрытие данных, если любой программист который использует данный класс, все равно может изменять эти приватные данные. В чем смысл?

Не следует трактовать инкапсуляцию так буквально, это довольно обобщенная штука.
И очень полезная. Может быть, вообще самая полезная в ООП. Ее сила именно в правильном
сокрытии данных. Если вы делаете какой-то мембер приватным, а затем выясняется, что
половине классов нужен к нему прямой доступ, для чего приходится или переносить его в
public-секцию, или делать accessor, то это не инкапсуляция. Инкапсуляция - это не столько
прятанье реализации, сколько отделение ее от открытой (интерфейсной) части.

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

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

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

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

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

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

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

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

Увы. ООП - не панацея. Еще хуже, когда методологии программирования (не только ООП) начинают рулить
(в прямом смысле) разработкой. То есть, когда смотрят на задачу и думают, какие бы классы тут создать,
да какой бы паттерн применить, вместо того, чтобы решать саму задачу, исходя из целей и требований.
Получается "XYZ ради XYZ", ничего хорошего в итоге.

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

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

В качестве примера могу вспомнить компонент одной программы, которую я писал пару лет назад.
Компонент представляет собой обработчик TCP-трафика, задача которого - выделить из входного
потока HTTP-сообщения, на лету разжать их, если нужно (gzip/deflate), затем преобразовать к
юникоду, после этого обработать HTML-код, вычленив из него запрещенные слова, а напоследок
запаковать все обратно, поправить HTTP-заголовки и вернуть клиенту (браузеру), как будто
все "так и было". И это все в многопоточной асинхронной манере, чтобы не было заметной
деградации сети.

За основу этого прокси-сервера был взят паттерн "proactor" (POSA), а за пересылку данных отвечала
абстракция под названием "stream". Через stream пускали "сырой" трафик, после чего он на лету
подключал к обработке наборы разных фильтров (тоже абстракция). Одни фильтры обрабатывали HTTP,
другие работали с gzip/deflate, третьи с кодировками, четвертые фильтровали html/plaintext и т.д.
Каждый фильтр обрабатывал данные и передавал их по цепочке дальше. Или задерживал на некоторое время,
если так было нужно. Внутри фильтров использовалась еще абстракции: аккумуляторы, которые умели
накапливать данные произвольного размера, насколько хватит места на жестком диске, а затем отдавали
все накопленное по запросу, дозиметры, которые регулировали переключение чтения-записи из-в stream и
так далее. Был еще класс "connection", который удерживал два экземпляра stream, соответствующих
обоим концам TCP-соединения (т.к. трафик гонялся в оба конца через два сокета). Сами классы создавались
обобщенно, через фабрики, builder-ы и т.п., чтобы замаскировать выбор конкретной реализации.
Даже реализация самих сокетов была обобщенной, так как send/recv для разных сокетов звались
по-разному: для одних напрямую, а для других через промежуточный драйвер (так было нужно из-за
проблем со сторонним софтом).

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

Кстати, я не сказал бы, что там красивый код получился. Тоже мешанина, местами мозг можно
вывернуть, особенно если мыслено пройтись по цепочке callback-ов где-нибудь на стадии
установки TCP-соединения. Но из него, по крайней мере, можно что-то лепить, и это не вызывает
цепных реакций или падений по непонятным причинам.

Через некоторое время код был адаптирован для поддержки SSL, с перехватом и подменой на лету
сертификата сервера (чтобы не было предупреждений в браузерах). Пару классов пришлось выкинуть, а
connection и stream переписать с использованием Boost.Asio. Все остальное осталось нетронутым.

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

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

Новые блоги и статьи Все статьи Все блоги /
Вот представьте что вам дали бессмертие. kumehtar 24.07.2026 Вот представьте что вам дали бессмертие, ничего более не меняя. Вообще ничего, только бессмертие в нынешнем виде. Рады были бы? Что бы вы тут делали всё это время? Никакой пенсии. Никакого нового. . .	сукцессия 41 anaschu 24.07.2026 Численная верификация бифуркации в агентной модели лесной сукцессии: от одного параметра к ансамблю Автор: пользователь @Shumilov_AS \| Раздел: Прикладная математика / Численные методы Кратко. . .	сукцессия 40. Ансамблевая кластерная параметризаци, часть 1. anaschu 24.07.2026 Пр# Сопровождение научной статьи ИИ-ассистентом: подготовка публикации и калибровка агентно-ориентированной модели сукцессии микоризных систем Полевые заметки о двухнедельной совместной работе. . .	Теория всего 12. ВГК на планете в стратегической игре "терра" anaschu 21.07.2026 ### Главные семантические изменения и дешифровка новой физики 1. `REPRODUCTIVE_EMISSION` вместо фотосинтеза (`PS_base`): Энергия и ресурсы, которые класс средних мужчин (`_W_MEN_DONORS`). . .
Публикация отклонённая на хабре. Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование задачи и целеполагание Hrethgir 21.07.2026 https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11948&stc=1&d=1784657928 Привет Хабр. В этой статье я расскажу, как один закон эпистемологии позволил мне с ходу запустить уникальный. . .	Теория всего 11. Основные параметры anaschu 21.07.2026 Дешифровка тензорного ядра Soil Chemistry 2. 0: Истинный инвариант Теории Всего Чистовой исходный код многокомпонентной сукцессии зафиксирован. Модель оперирует единым вектором состояния. . .	Теория всего 10. Клод трусишка anaschu 21.07.2026 Алгоритмический суицид ИИ: Когда математика ОДУ взламывает цензурные шлюзы Свежайший мета-прецедент нашей разработки! Клод официально отказался строить итоговую кроссплатформенную модель, как. . .	Теория всего 9. Окончательная проработка метафоры "дерево = традиции" anaschu 21.07.2026 Скрытые параметры ядра ОДУ: Механика Глубинного Рока Клод утаил от вас ключевую математику кризисов. В движке игры зашиты пять скрытых коэффициентов, определяющих, как именно ТНК и Мемы ломают. . .

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

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

@DenQ Комбинатор 980 / 252 / 13 Регистрация: 10.03.2010 Сообщений: 3,556
	06.09.2013, 19:16
	Для меня один из самых больших плюсов ООП это то, что, существует очень много паттернов проектирования. Разумеется они существуют и для не ООП, но в таком случае их будет намного меньше... Плюсы паттернов проектирования думаю, обсуждать не стоит? Igor3D, как я понял, вы хотите сказать, что ООП слишком много кушает памяти, ресурсорв? Особенно в руках горе программистов?) Это уже задача компиляторов. Вот к примеру jit-компилятор, развязывает запутанный код программиста и делает из него более простой.. и так несколько раз подряд... из простого, к еще более простому... 0

@MolodoyCoder 36 / 15 / 2 Регистрация: 02.09.2013 Сообщений: 565
	08.09.2013, 23:47
	Еще раз отпишусь по теме. Возможно ранее я плохо изложил мысли. И мне в минус прописали цитировании как бы бездарного препода. Попробую объяснить (на пальцах )разницу между ООП и процедурным программированием, отталкиваясь от разницы в глобальности переменных. Небольшое уточнение: предпочитаю понимать процедуры в данном контексте, как функции которые, если нужно могут и принять и вернуть значения. В процедурном программировании есть абсолютно глобальные переменные. Потом идут переменные, действие которых распространяется только в пределах процедур И еще есть переменные, которые "живут" только в пределах циклов. В ООП программировании нет абсолютно глобальных переменных. Самые "глобальные" переменные могут быть видны только в пределах своего класса Потом идут "менее глобальные переменные" , которые могут быть видны только в пределах методах. Т.е. между { } И наконец самые локальные переменные, "живут" только в пределах циклов. Получается что в ооп все данные и методы (читай процедуры классов) четко разделены этими самыми классами. Но если полезть дальше в абстракции, то можно сказать в опп программировании и есть тоже в условном смысле глобальные переменные. Это любые паблик члены самомого общего класса Main Programm. Ну это уже словеса. И вся эта инкапсуляция-полиморфизм-наследование, в итоге нужна для того что бы уйти от процедурного подхода,а именно куча процедур, которая в итоге работает с кучей глобальных данных, еще глобальные операторы, которые не сидят в процедурах, а тоже тусуются в этой глобальной туче. ООП позволяет разделить методы и данные , структурно, иерархично, поклассово. В общем. Ну и конечно оперировать подобиями из реальной жизни. И это уже следствие, ООП-ного разделения данных и методов. ВСЕ СКАЗАННОЕ, МОЕ ИМХО. Не навязываю. 0

@DenQ Комбинатор 980 / 252 / 13 Регистрация: 10.03.2010 Сообщений: 3,556
	09.09.2013, 03:21
	MolodoyCoder, из всего выше сказанного, мне не ясно, вы за или против ООП? 0

@taster 0 / 0 / 1 Регистрация: 15.07.2013 Сообщений: 18
	09.09.2013, 16:09
	ООП дисциплинирует. Использовать его лучше везде, даже в небольших приложениях. Ведь все приложения рано или поздно изменяются/усовершенствуются. А ООП дает большие преимущества в этом деле. 0

@Нитонисе 10 / 10 / 4 Регистрация: 12.10.2013 Сообщений: 249
	27.12.2013, 12:37
	Довольно долго пытался осознать принципы ООП. Читал много литературы, пробовал использовать. И все равно не смог понять тех преимуществ, которые ООП дает. Правда надо сказать, что я не профессиональный программист. Программирование изучаю самостоятельно и большей частью делаю программы для себя, хотя было и несколько коммерческих проектов средней сложности. Вообще некоторые базовые принципы ООП привлекают. Например бывают коллекции разных объектов, которые все прячутся за одним абстрактным типом, но каждый по своему реализует какое-либо действие. Ну, классический пример с абстрактным классом Shape и наследниками Circle, Rectangle, Triangle. У базового класса есть виртуальная функция Draw(), которую наследники реализуют каждый по своему. Такое полиморфное поведение я понимаю и вижу его преимущества. Но декларированы еще преимущества от инкапсуляции - сокрытия внутренних данных. И вот это я не могу понять хоть убейте. Мы прячем данные в разделе private класса якобы для того, чтобы защитить данные от изменения. Но при этом в public даем метод Set(). Черт возьми, ну какое же это сокрытие данных, если любой программист который использует данный класс, все равно может изменять эти приватные данные. В чем смысл? При этом очевидным образом усложняется доступ к данным - нужно использовать метод Get(). Да, согласно принципов ООП нужно в одном классе компоновать данные и функции работы с этими данными. Но зачастую функции, которым могут понадобиться эти данные, нарушают уровень абстракции. То есть логика объединения данных в класс одна, но какой-то приватный аргумент этого класса используется в других вычислениях другого класса и там приходится использовать метод Get(). И такое встречается сплошь и рядом. Потому что переменные взаимодействуют между собой в очень разных сочетаниях. Рекомендуется в класс выделять 7 +/- 2 переменных. Но учитывая сложный характер их взаимодействия - их нужно все скинуть в один класс. Заявляется, что программы, написанные на ООП проще сопровождать (вносить изменения, расширять функционал). Обосновывается это тем, что если объявить в интерфейсе класса какой-то публичный метод, который используется где-то там еще в программе, то при изменении этого метода нужно будет исправить всего лишь его реализацию, а в остальной программе ничего изменять не нужно. Но это справедливо только в том случае, если не изменяется имя функции, набор аргументов и тип возвращаемого значения. Может быть это связано с тем, что у меня низкий профессиональный уровень, но у меня эти параметры функций часто меняются. Да и кроме того, модификации может подвергнуться не только реализация функций класса, но и сама структура классов. Некоторые могут стать лишними. Где-то взаимодействие классов нужно переделать. Все это довольно трудоемко и никаких особых преимуществ в плане облегченного сопровождения программы я не наблюдаю. Также упоминается, что применение ООП позволяет затем повторно использовать классы. Но это возможно лишь тогда, когда классы уж слишком общие. Чаще всего каждая программа требует уникальной реализации. Да, бывают какие-то фрагменты, которые можно копипастом вставить из прошлой программы. Но чтобы не использовать копипаст ведь не обязательно все это оформлять классом. Можно сделать для себя набор функций, которые делают какую-то работу хорошо и в дальнейшем просто использовать уже готовые функции. Вобщем для меня очень сомнительно выглядит использование ООП. Есть плюсы, но минусов больше. Пока прихожу к выводу, что ООП может быть полезно только в крупных проектах с большим количеством разработчиков. Если же программист один и работает над программами средней сложности, то от применения ООП больше вреда, чем пользы. 0