Форум программистов, компьютерный форум, киберфорум
ООП и паттерны
Войти
Регистрация
Восстановить пароль
Блоги Сообщество Поиск  
Результаты опроса: используете ли вы ооп
да 238 86.55%
нет 37 13.45%
Голосовавшие: 275. Вы ещё не голосовали в этом опросе

 
 
Рейтинг 4.76/461: Рейтинг темы: голосов - 461, средняя оценка - 4.76
81 / 39 / 3
Регистрация: 29.01.2010
Сообщений: 386

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

09.02.2010, 13:44. Показов 103073. Ответов 793
Метки нет (Все метки)

Студворк — интернет-сервис помощи студентам
Здравствуйте.
Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп?
Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами.
Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.
5
cpp_developer
Эксперт
20123 / 5690 / 1417
Регистрация: 09.04.2010
Сообщений: 22,546
Блог
09.02.2010, 13:44
Ответы с готовыми решениями:

Стоит ли использовать ООП -- часть вторая
У людей задающих подобные вопросы не все в порядке с пониманием ООП. Например, в параллельной теме человек интересуется: На самом...

Какие РЕАЛЬНО есть причины НЕ использовать ООП?
Появился такой вопрос. Все мы знаем о шумихе вокруг ООП, спорной идее наследования, других невнятных идей которых можно добиться...

Где стоит использовать bootstrap и стоит ли вообще использовать CSS фреймворки?
Здравствуйте. Лично я ужасаюсь ковырять стили, когда к сайту подключен bootstrap и мало понимаю, чем он хорош вообще. В данной теме я бы...

793
 Аватар для talis
794 / 546 / 61
Регистрация: 11.05.2010
Сообщений: 1,298
Записей в блоге: 1
05.01.2014, 15:02
Студворк — интернет-сервис помощи студентам
Убежденный, всегда есть задачи, которые изначально не были предусмотрены.

Не по теме:

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



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

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

Не по теме:

Строго говоря, изначальная идея была в том, что объекты "шлют сообщения" друг другу, толком даже не зная конкретного типа получателя. О прямом доступе к данным и речи не было. Объекты отражали состояние системы, а то, как они в себе хранили ту часть состояния, за которые отвечали, было их личным делом. Эти "сообщения" в большинстве современных языков реализованы вызовами методов.

1
Ушел с форума
Эксперт С++
 Аватар для Убежденный
16481 / 7444 / 1187
Регистрация: 02.05.2013
Сообщений: 11,616
Записей в блоге: 1
05.01.2014, 23:27
Цитата Сообщение от talis Посмотреть сообщение
Нельзя гарантировать, что классу никогда не потребуется при изменении его данных проводить дополнительные операции. Если аксессоры действительно настолько просты, как одно присвоение и один возврат, то вам не составит труда их написать.
Так дело не в том, что их трудно написать, а в том, что код с использованием
аксессоров иногда выглядит неестественно. Где-то выше был приведен пример, типа
вместо "rect.x += offset" пишут такое: "rect.set_x(rect.get_x() + offset)".
Жаль, что в C++ не такой вещи, как properties, это все упростило бы.

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

Это два взаимосвязанных принципа объектно-ориентированного проектирования: принцип разделения ответственности и принцип сокрытия реализации (инкапусляции). Объект сам должен оперировать своими данными, ведь объект - это данные + операции, связанные с ними. Перекладывать эту ответственность на пользователей объекта - не просто не по-феншую (тут бы и спора не было). Это чревато.
У встроенных типов (int, bool, char и т.д.) аксессоры отсутствуют напрочь.
Означает ли это, что ответственность за работу с данными переложена на пользователя и
тем самым нарушена инкапсуляция и другие принципы проектирования ? Мой ответ на
этот вопрос - нет. Это классы данных, для которых прямой доступ к содержимому так же
естественен, как, скажем, взятие адреса или присваивание.

Еще раз подчеркну - я не против аксессоров, я против догматического подхода к решению
подобных вопросов. Нет таких правил, которые работают везде и всегда и для которых не
существует исключений.
1
 Аватар для talis
794 / 546 / 61
Регистрация: 11.05.2010
Сообщений: 1,298
Записей в блоге: 1
06.01.2014, 16:56
Убежденный, приведу ещё один довод.

Допустим вы работаете со своими Rectangle:

C++
1
2
3
4
5
6
7
class Rectangle
{
    public:
        double x1, y1, width, height;
    
    // ...
};
Потом у вас появляется некая сторонняя библиотека (скажем, физический движок или какой-нибудь импортер из svg/dxf/etc), чьи ресурсы (и прямоугольники тоже) вы хотите использовать в своей программе, при этом работая с оригинальными объектами (скажем, для дальнейшего сохранения назад в dxf)). Но вот беда: у них другой набор переменных.

C++
1
2
3
4
5
6
7
class OtherRect
{
    public:
        double x1, y1, x2, y2;
    
    // ...
};
Был бы у вас интерфейс, можно было бы сделать адаптер для этого OtherRect:

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
#include <iostream>
 
class IRectangle
{
    public:
        virtual IRectangle & SetX( double ) = 0;
        virtual double GetX() const = 0;
 
        virtual IRectangle & SetY( double ) = 0;
        virtual double GetY() const = 0;
 
        virtual IRectangle & SetWidth( double ) = 0;
        virtual double GetWidth() const = 0;
 
        virtual IRectangle & SetHeight( double ) = 0;
        virtual double GetHeight() const = 0;
};
 
/**
 * Это "родной" Rectangle
 */
class Rectangle :
    public IRectangle
{
    protected:
        double x1, y1, width, height;
 
    public:
        Rectangle( double _x, double _y, double _w, double _h ) :
            x1( _x ),
            y1( _y ),
            width( _w ),
            height( _h )
        {
        }
 
        virtual IRectangle & SetX( double x )
        {
             x1 = x;
             return *this;
        }
 
        virtual double GetX() const
        {
             return x1;
        }
 
 
 
        virtual IRectangle & SetY( double y )
        {
             y1 = y;
             return *this;
        }
 
        virtual double GetY() const
        {
             return y1;
        }
 
 
 
        virtual IRectangle & SetWidth( double w )
        {
             width = w;
             return *this;
        }
 
        virtual double GetWidth() const
        {
             return width;
        }
 
 
 
        virtual IRectangle & SetHeight( double h )
        {
             height = h;
             return *this;
        }
 
        virtual double GetHeight() const
        {
             return height;
        }
};
 
 
/**
 * Это "чужой" Rectangle
 */
class OtherRect
{
    public:
        double x1, y1, x2, y2;
};
 
 
/**
 * Это адаптер, позволяющий использовать "чужой" Rectangle как "родной"
 */
class OtherRectAdapter
    : public IRectangle
{
    protected:
        OtherRect * rect;
 
    public:
        OtherRectAdapter( OtherRect &_rect )
            : rect( &_rect )
        {
        }
 
        OtherRect & getOtherRect()
        {
            return *rect;
        }
 
 
        virtual IRectangle & SetX( double x )
        {
             double width = GetWidth();
             rect->x1 = x;
             rect->x2 = x + width;
 
             return *this;
        }
 
        virtual double GetX() const
        {
             return rect->x1;
        }
 
 
 
        virtual IRectangle & SetY( double y )
        {
             double height = GetHeight();
             rect->y1 = y;
             rect->y2 = y + height;
 
             return *this;
        }
 
        virtual double GetY() const
        {
             return rect->y1;
        }
 
 
 
        virtual IRectangle & SetWidth( double w )
        {
             rect->x2 = rect->x1 + w;
             return *this;
        }
 
        virtual double GetWidth() const
        {
             return rect->x2 - rect->x1;
        }
 
 
 
        virtual IRectangle & SetHeight( double h )
        {
             rect->y2 = rect->y1 + h;
             return *this;
        }
 
        virtual double GetHeight() const
        {
             return rect->y2 - rect->y1;
        }
};
 
 
//
// Оператор вывода IRectangle
//
std::ostream & operator<< ( std::ostream & out, const IRectangle &rect )
{
    out << "{ X: " << rect.GetX() << ", Y: " << rect.GetY()
        << ", W: " << rect.GetWidth() << ", H: " << rect.GetHeight() << " }";
 
    return out;
}
 
//
// Оператор вывода OtherRect для просмотра полей объекта в чистом виде
//
std::ostream & operator<< ( std::ostream & out, const OtherRect &rect )
{
    out << "{ X1: " << rect.x1 << ", Y1: " << rect.y1
        << ", X2: " << rect.x2 << ", Y2: " << rect.y2 << " }";
 
    return out;
}
 
//
// Проверяем
//
int main()
{
    Rectangle native_rect( 5, 5, 5, 5 );
    OtherRect other_rect_foreign = { 5, 5, 10, 10 };
    OtherRectAdapter other_rect( other_rect_foreign );
 
    std::cout << "native:\n" << native_rect << "\nother:\n" << other_rect << "\nother RAW:\n" << other_rect_foreign << "\n\n";
 
    native_rect
        .SetWidth( 25 )
        .SetX( 4 )
        .SetY( 14 );
 
    other_rect
        .SetWidth( 25 )
        .SetX( 4 )
        .SetY( 14 );
 
    std::cout << "native:\n" << native_rect << "\nother:\n" << other_rect << "\nother RAW:\n" << other_rect_foreign << "\n";
 
    return 0;
}
В этом случае любые операции (пересечения того же), работающие с IRectangle, тут же начнут работать и с OtherRect. Можете из прямо в IRectangle описать (строго говоря, сделав из интерфейса абстрактный класс).

Если Rectangle реализовать как класс с открытыми членами, то такую подмену реализации так просто провести не удастся.
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
06.01.2014, 17:00
Цитата Сообщение от Убежденный Посмотреть сообщение
Иногда и для public-членов есть место, и для goto, и т.д.
и даже для программирования прямо в опкодах. Но ЭНИАК не зря остался в прошлом.
2
Ушел с форума
Эксперт С++
 Аватар для Убежденный
16481 / 7444 / 1187
Регистрация: 02.05.2013
Сообщений: 11,616
Записей в блоге: 1
06.01.2014, 22:14
Цитата Сообщение от talis Посмотреть сообщение
Потом у вас появляется некая сторонняя библиотека (скажем, физический движок или
какой-нибудь импортер из svg/dxf/etc), чьи ресурсы (и прямоугольники тоже) вы хотите использовать в своей
программе, при этом работая с оригинальными объектами (скажем, для дальнейшего сохранения назад в dxf)). Но
вот беда: у них другой набор переменных.
Был бы у вас интерфейс, можно было бы сделать адаптер для этого OtherRect

...

В этом случае любые операции (пересечения того же), работающие с IRectangle, тут же начнут работать и с
OtherRect. Можете из прямо в IRectangle описать (строго говоря, сделав из интерфейса абстрактный класс).
Если Rectangle реализовать как класс с открытыми членами, то такую подмену реализации так просто провести
не удастся.
Хороший пример, не спорю, но не для такого класса, как Rectangle.

Из простой сущности с value-семантикой и нулевым во всех отношениях оверхедом
получилась полиморфная иерархия, построенная на интерфейсах. Да, это гибко, но
объекты этого класса теперь занимают больше памяти из-за vptr, доступ к членам
осуществляется в несколько уровней косвенности, как, например, в случае с
OtherRectAdapter::GetWidth: сначала разыменование vptr, потом вызов метода,
после этого получение rect.x1 и rect.x2, и напоследок операция вычитания.
Но это все мелочи.

Чтобы заработала полиморфность, объекты нужно передавать по указателю, а там,
где указатели, там new/delete и проблемы управления временем жизни. Чуть больше
сложности - и мы будем вынуждены управлять интерфейсами через умные указатели и
обертки с подсчетом ссылок. ObjectRectAdapter в приведенной имплементации хранит
указатель на OtherRect - это тоже вопрос управления временем жизни, который просто
так не решается. С достижением гибкости пришли и проблемы, требующие внимания.

Если это решение вопроса унификации типов со сторонней библиотекой, то оно может
быть другим. Типы, скорее всего, будут известны на стадии компиляции, по крайней
мере в том месте, где мы получаем OtherRect из сторонней библиотеки или передаем
OtherRect в нее. А значит, незачем выводить их в рантайме, достаточно написать
две функции-прокладки, преобразующие Rectangle в OtherRect и обратно, и выполнять
нужные преобразования на всем пограничном слое, который взаимодействует с этой
библиотекой. И в итоге в основном коде все равно останется один тип - Rectangle,
только без виртуальности, смарт-поинтеров и других заморочек. Этот подход может
применяться для "стыковки" программных интерфейсов, использующих несовместимые,
но концептуально единые типы, например char */string/CString/QString и другие.
Максимум, что при этом получается - одно дополнительное разыменование или
одно дополнительное копирование.

А можно добавить в Rectangle конструктор, принимающий ссылку на OtherRect и
выводить один тип из другого, или ввести класс-агрегат, конструирующийся из разных
типов или преобразующийся в разные типы с помощью перегруженных операторов.
Сам Rectangle, разумеется, так и останется value-типом.

Напоследок повторю, что я не против accessor-ов, просто не верю, что они должны
быть обязательно и всегда, безо всяких "если".
1
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
06.05.2014, 10:48
Все очень просто.
Если программист УМЕЕТ использовать ООП, то лучше использовать ООП. Без вариантов. Думаю, это понятно любому программисту, который реально работал с большими программами.
Если же программист НЕ УМЕЕТ использовать ООП, то лучше его вообще не использовать. Потому что не зная принципов работы ООП, у такого программиста получается тот же структурированный процедурный код, но разбросанный на кучу классов, методов, статических методов, причем, обычно, совершенно не логично и даже абсурдно, с точки зрения ООП. Разобраться в такой мешанине бывает гораздо сложнее, чем просмотреть реально большой, но простой структурный код.
0
Evg
Эксперт CАвтор FAQ
 Аватар для Evg
21281 / 8305 / 637
Регистрация: 30.03.2009
Сообщений: 22,660
Записей в блоге: 30
06.05.2014, 11:26
Цитата Сообщение от taancer Посмотреть сообщение
Если программист УМЕЕТ использовать ООП
...
Если же программист НЕ УМЕЕТ использовать ООП
А что делать тем, кто не умеет, но думает, что умеет? Таких, по ощущениям, большинство
0
1443 / 1326 / 131
Регистрация: 20.03.2009
Сообщений: 4,689
Записей в блоге: 11
06.05.2014, 12:21
Цитата Сообщение от Evg Посмотреть сообщение
А что делать тем, кто не умеет, но думает, что умеет?
Писать код.
0
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
06.05.2014, 13:32
Цитата Сообщение от taancer Посмотреть сообщение
Если программист УМЕЕТ использовать ООП, то лучше использовать ООП. Без вариантов.
А ты в курсе, что существуют другие вычислительные модели и задачи, которые проще решать с их использование, нежели с ООП?
0
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
06.05.2014, 15:59
Цитата Сообщение от korvin_ Посмотреть сообщение
А ты в курсе, что существуют другие вычислительные модели и задачи, которые проще решать с их использование, нежели с ООП?
Программировать станки с ЧПУ и микросхемы с использованием ООП - это, конечно, было бы круто
Но чаще для этого используются другие средства.
Не надо путать молоток с отверткой.
Но. Где МОЖНО применить ООП - там оно должно быть применено.
И то, что Вы не умеете мыслить в категориях ООП, а продолжаете решать свои проблемы структурным программированием - это Ваша проблема.
Если бы Вы знали и применяли ООП - то даже вопрос так не стоял бы, про повторное использование кода и тп...
-------
Хочу, однако, заметить, что есть одно единственное ограничение ООП, которое я знаю, которое может ограничить его применимость.
Это производительность выполняемых операций.
Да. ООП добавляет некоторые накладные расходы на вычисления.
Поэтому, когда нужны очень скоростные вещи реалтайм или переработка больших объемов информации, то, скорее всего, придется несколько ОПТИМИЗИРОВАТЬ выполнение операций.
Но не отказываться от ООП! А оптимизировать тонкие участки.
В большинстве случаев - 99% решаемых задач - не особо чувствительны к небольшим потерям, поэтому ловить блох в таких случаях и программировать в машинных кодах - излишне.

Цитата Сообщение от Evg Посмотреть сообщение
А что делать тем, кто не умеет, но думает, что умеет? Таких, по ощущениям, большинство
К сожалению - ДА.
Прочитав синтаксис языка и пару умных книжек, уже считают себя знатоками ООП.
Как же! Они же могут создавать классы! И даже методы умеют писать! Более того! Наследовать классы могут!
Вот оно, счастье!
А потом встречаю классы с несколькими десятками статических методов по 900 строк кода в каждом.
И человек искренне считает, что он написал объектно-ориентированный код.
0
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
06.05.2014, 16:45
Цитата Сообщение от taancer Посмотреть сообщение
Программировать станки с ЧПУ и микросхемы с использованием ООП - это, конечно, было бы круто
При чем тут станки? Загугли Erlang например.

Цитата Сообщение от taancer Посмотреть сообщение
Но. Где МОЖНО применить ООП - там оно должно быть применено.
Ну это же совсем другое дело и кардинально отличается от
Цитата Сообщение от taancer Посмотреть сообщение
лучше использовать ООП. Без вариантов.
Но еще правильней заменить «МОЖНО» на «ЦЕЛЕСООБРАЗНО»

Цитата Сообщение от taancer Посмотреть сообщение
И то, что Вы не умеете мыслить в категориях ООП
А ты телепат? Похоже, что нет.

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

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

Цитата Сообщение от taancer Посмотреть сообщение
Если бы Вы знали и применяли ООП - то даже вопрос так не стоял бы, про повторное использование кода и тп...
Ну точно не телепат. Да еще и подменяешь понятия.
0
1443 / 1326 / 131
Регистрация: 20.03.2009
Сообщений: 4,689
Записей в блоге: 11
06.05.2014, 17:08
Цитата Сообщение от taancer Посмотреть сообщение
Но. Где МОЖНО применить ООП - там оно должно быть применено.
Функциональная парадигма опровергла это утверждение.
Реальные программы на C++11 уже не чисто ООП, шаблоны и функторы это не ООП, но сними чертовски удобно.
0
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
06.05.2014, 17:46
korvin_
Спасибо за ссылки.
Да, я больше практик, чем теоретик. Поэтому немного плаваю в понятиях, как Вы правильно заметили.
И не телепат это точно.
Сужу по высказываниям...
Работал с очень большим количеством программистов.
Были разные мнения и разные споры, как лучше программировать.
Возможно, я просто влез со своим мнением немного не в тему, не учел, что здесь обсуждается очень большой набор областей применимости.
Мой опыт больше всего касается именно программирования прикладных задач на языках высокого уровня.
Задач для конечного пользователя.
Поэтому я был так категоричен в отношении применения ООП.
Если рассматривать шире, то, как я уже и говорил - давайте закручивать шурупы отвертками, а гвозди забивать?

Erlang - как я понял специально разработан для программирования серверных компонент и многопоточных приложений. Возможно (даже скорее всего), его применение будет более оправданно для разработки подобных приложений и операционных систем, чем, например, тот же С.

Так же можно сказать, что для разработки сайтов используется php и другие специализированные языки.
Там тоже есть, как ни странно ООП, но на самом верхнем уровне. Когда в 99% случаев используются уже ранее разработанные сущности, а не проектируются новые структуры с нуля.

Мне, по роду моей работы, приходится работать с очень большим количеством программного кода, качество которого, к сожалению, в большинстве случаев, оставляет желать лучшего. Поэтому я так категоричен в своих высказываниях насчет ООП.
Когда начинаешь ставить задачу программисту и говоришь о том, что нужно сделать структуру классов для обработки процесса с возможностью дополнения видов обработки и другими тонкостями и видишь круглые непонимающие глаза, а потом, при приеме работы получаешь один класс с двадцатью статическими методами... становится грустно. Очень грустно.
И, главное, не понимает человек, когда ему начинаешь объяснять, что нужно было сделать по другому. Тебе в ответ - "Ну ведь работает же! И я быстро сделал! А когда нужно будет добавить новую обработку, просто добавим еще один статический метод..."
А то, что потом этот хлам сыпется при малейшей правке, что методы почти полностью дублируют друг друга за исключением пары строк из 500-900, это горе-программистов не волнует.
Это, конечно, крайний случай.
Бывают более изощренные хламоделы. Уже опытные и знающие наследование, но не понимающие общей парадигмы ООП. Вот тут появляются такие шедевры, что просто описать невозможно... Чаще всего нарушается инкапсуляция. Да и вообще, зачем она нужна?...
0
Evg
Эксперт CАвтор FAQ
 Аватар для Evg
21281 / 8305 / 637
Регистрация: 30.03.2009
Сообщений: 22,660
Записей в блоге: 30
06.05.2014, 18:17
Цитата Сообщение от taancer Посмотреть сообщение
К сожалению - ДА.
Прочитав синтаксис языка и пару умных книжек, уже считают себя знатоками ООП.
Как же! Они же могут создавать классы! И даже методы умеют писать! Более того! Наследовать классы могут!
Вот оно, счастье!
А потом встречаю классы с несколькими десятками статических методов по 900 строк кода в каждом.
И человек искренне считает, что он написал объектно-ориентированный код.
Твой посыл в посте #446 начался с фразы "Все очень просто". Далее я задал вопрос "А что делать тем, кто не умеет, но думает, что умеет?", на который ты так и не ответил

Добавлено через 1 минуту
Цитата Сообщение от taancer Посмотреть сообщение
А то, что потом этот хлам сыпется при малейшей правке, что методы почти полностью дублируют друг друга за исключением пары строк из 500-900, это горе-программистов не волнует.
А что, если написать с использованием ООП, то оно автоматически перестанет сыпаться при малейшей правке?

Добавлено через 1 минуту
Цитата Сообщение от taancer Посмотреть сообщение
Erlang <skipe> Возможно (даже скорее всего), его применение будет более оправданно для разработки подобных приложений и операционных систем, чем, например, тот же С.
Erlang в принципе не используется для разработки операционных систем. В отличие от Си, на котором операционные системы как раз и пишут
0
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
06.05.2014, 19:54
Цитата Сообщение от taancer Посмотреть сообщение
Спасибо за ссылки.
Да, я больше практик, чем теоретик.
Цитата Сообщение от taancer Посмотреть сообщение
И, главное, не понимает человек, когда ему начинаешь объяснять, что нужно было сделать по другому. Тебе в ответ - "Ну ведь работает же! И я быстро сделал! А когда нужно будет добавить новую обработку, просто добавим еще один статический метод..."
Вроде уже было, но повторю на всякий случай: http://habrahabr.ru/post/153225/
0
Evg
Эксперт CАвтор FAQ
 Аватар для Evg
21281 / 8305 / 637
Регистрация: 30.03.2009
Сообщений: 22,660
Записей в блоге: 30
06.05.2014, 20:09
Цитата Сообщение от korvin_ Посмотреть сообщение
Вроде уже было, но повторю на всякий случай: http://habrahabr.ru/post/153225/
Зачот!

Когда я учился в институте, у нас один делец через ООП решал задачу расстановки 8 ферзей на шахматном поле. Там были класс "поле", "доска", содержащая "поля", "ферзь" и много каких-то умностей, которые уже и не упомню. Жаль, что мне тогда не хватило прозорливости, чтобы сохранить этот код, как образец качественного гавнокода: всё аккуратно структурировано и чётко вылизано, только реализация заняла в 10 раз больше времени, чем простой код на Си (с, грубо говоря, одним массивом из 8 элементов) и работала в несколько раз медленнее
0
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
07.05.2014, 00:37
Цитата Сообщение от Evg Посмотреть сообщение
А что делать тем, кто не умеет, но думает, что умеет?", на который ты так и не ответил
В этом и есть проблема.
К сожалению, очень многие думают, что умеют, а на самом деле не умеют.
Цитата Сообщение от Evg Посмотреть сообщение
Таких, по ощущениям, большинство
Ошибки проектирования очень дорого обходятся в дальнейшей разработке.
Кстати, в примере про двух программистов - оба не правы.
Первый слишком далек от практики. В реальной работе так может делаться только в ОЧЕНЬ заформализованных организациях. Я такого не видел.
Второй получит как раз неподдерживаемый код из 1000 строк кода (в реальной программе, я не говорю про этот достаточно простой пример)
об этом как раз написано в примечании UPD.2 с которым я полностью согласен. респект автору.

Цитата Сообщение от Evg Посмотреть сообщение
А что, если написать с использованием ООП, то оно автоматически перестанет сыпаться при малейшей правке?
Как ни банально звучит, но ДА.
Грамотно написанная структура с использованием ООП не сыпется.
Может посыпаться какой-то конкретный модифицированный кусок функциональности.
Но остальная реализация будет работать стабильно как прежде.
Есть, конечно, два исключения.
1. Модификация должна делаться тоже программистом знающим ООП.
был у меня такой случай. Девочке одной дали задачу - вывести сообщение какое-то при каких-то условиях.
Ну она, не долго думая, посмотрела код... о! нужный метод!
И в базовом классе в основном методе, который отвечает за поведение всей функциональности воткнула свое сообщение.
Дальше можно не продолжать.
2. Появилось новое требование, которое влияет целиком на функциональность.
Ну типа рецептов в приведенной ссылке выше, хотя это не самое страшное нововведение.
Страшнее было бы например требование, чтобы хлеб выпекался не только в одной печке, а проходил гибкую обработку по нескольким различным устройствам, да еще в параллельном режиме. Ну типа он там подсахаривается и обрезается одновременно...
Тут пришлось бы менять немного концепцию.
В таких случаях, я оставляю существующую структуру как есть (и для сравнения полезно) и делаю полный рефакторинг кода в новую структуру классов с учетом новых требований.
Если просто пытаться в таких случаях исправить поведение существующей системы - конечно, посыпаться может все что угодно.
0
1443 / 1326 / 131
Регистрация: 20.03.2009
Сообщений: 4,689
Записей в блоге: 11
07.05.2014, 10:52
Цитата Сообщение от taancer Посмотреть сообщение
Как ни банально звучит, но ДА.
Нет. Особенно если на C++, там можно обе ноги отстрелить.
Цитата Сообщение от taancer Посмотреть сообщение
Грамотно написанная структура с использованием ООП не сыпется.
Сыпятся не из-за структуры, а из-за банальных ошибок: нет проверки указателя, граничных условий, некорректных данных и т.д.
Цитата Сообщение от taancer Посмотреть сообщение
Может посыпаться какой-то конкретный модифицированный кусок функциональности.
Если нет тестов, то нельзя нив чем быть уверенным.
0
Evg
Эксперт CАвтор FAQ
 Аватар для Evg
21281 / 8305 / 637
Регистрация: 30.03.2009
Сообщений: 22,660
Записей в блоге: 30
07.05.2014, 13:21
Цитата Сообщение от taancer Посмотреть сообщение
Как ни банально звучит, но ДА
Значит ты теоретик, а вовсе не практик. Или практик, который, условно говоря, из одного эксперимента делает далеко идущие выводы

Цитата Сообщение от taancer Посмотреть сообщение
Грамотно написанная структура с использованием ООП не сыпется
Грамотно написанная программа не сыплется независимо от того, с использованием ООП она написана, или без него.
0
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
11.05.2014, 01:13
Цитата Сообщение от Evg Посмотреть сообщение
Грамотно написанная программа не сыплется
каждый верит в то, во что он верит.
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
raxper
Эксперт
30234 / 6612 / 1498
Регистрация: 28.12.2010
Сообщений: 21,154
Блог
11.05.2014, 01:13

Стоит ли учить ООП в одно время с Яп
Добрый день! Начал активно изучать c#. Читаю Шилдта в свободное от учебы время и стараюсь практиковаться и всё выходит пока нормально. Но...

Как использовать ООП в WinAvr
Класс я создал. А вот объект класса создать не получается! Полазив по интернету выяснил что оператор new не поддерживается компилятором! ...

Js class как правильно использовать ООП
Накидал вот такой простенький код, авторизация проходит, data.Access_token существует, но в this.Access_token почему то не сохраняется, не...

Когда следует использовать ООП в РНР?
Когда стоит учить ооп в РНР, если новичок в РНР? Стоит ли писать весь код в стиле ооп ?

WITH AS стоит ли использовать
Использую СУБД Postgresql, есть запрос SELECT * FROM Table1 WHERE Filed1 IN (SELECT Fileld1 FROM Table2 WHERE Fileld2='A' AND...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
460
Ответ Создать тему
Новые блоги и статьи
Теория всего 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
Скрытые параметры ядра ОДУ: Механика Глубинного Рока Клод утаил от вас ключевую математику кризисов. В движке игры зашиты пять скрытых коэффициентов, определяющих, как именно ТНК и Мемы ломают. . .
Теория всего 8. Clauude трусишка. Ответ джемени
anaschu 21.07.2026
Игровой баланс «Модели Всего»: Алгоритмический блок как механика Семантического БуфераЭтот скриншот отказа Клода — идеальный, чистейший прецедент для нашей Теории Всего. Вы столкнулись не просто с. . .
Теория всего 7. Дерево - это патриархат, грибы - это феминизм
anaschu 21.07.2026
Уничтожение Патриархата: Как ТНК, Мемы и Половой отбор зачистили «Сексуальный Пролетариат» Величайшая иллюзия современного человека — вера в «свободу воли», «социальный прогресс» и «эволюцию. . .
История и социология Терры на примере борьбы микориз за пространство. 1. Глоссарий терры.
anaschu 21.07.2026
Решил тут подумать о возможности сделать лор некоторой комп игры - стратегии, или худжественной книги антиутопии, которые будут юзать планету,которая максимально будет похожа на нашу землю, но где. . .
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2026, CyberForum.ru