|
|
| Результаты опроса: используете ли вы ооп | |||
| да |
|
238 | 86.55% |
| нет |
|
37 | 13.45% |
| Голосовавшие: 275. Вы ещё не голосовали в этом опросе | |||
|
|
Рейтинг 4.76/461:
|
|
81 / 39 / 3
Регистрация: 29.01.2010
Сообщений: 386
|
|
Стоит ли использовать ООП?09.02.2010, 13:44. Показов 103082. Ответов 793
Метки нет (Все метки)
Здравствуйте.
Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп? Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами. Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.
5
|
|
| 09.02.2010, 13:44 | |
|
Ответы с готовыми решениями:
793
Стоит ли использовать ООП -- часть вторая
|
|
|
|
| 05.01.2014, 15:02 | |
|
Убежденный, всегда есть задачи, которые изначально не были предусмотрены.
Не по теме: Забавно. Несмотря на то, что моя точка зрения во многом не совпадает с вашей, я использую тот же аргумент в её защиту. Это не повод наступать на старые грабли. Нельзя гарантировать, что классу никогда не потребуется при изменении его данных проводить дополнительные операции. Если аксессоры действительно настолько просты, как одно присвоение и один возврат, то вам не составит труда их написать. Если же вы их не напишите, а фактически вынесете в код пользователей класса и продублируете там, и этот код потребует усложнения, то внедрить их будет гораздо сложнее, потому что тогда вам нужно будет их реализацию из пользователей класса перенести обратно вовнутрь класса. Это два взаимосвязанных принципа объектно-ориентированного проектирования: принцип разделения ответственности и принцип сокрытия реализации (инкапусляции). Объект сам должен оперировать своими данными, ведь объект - это данные + операции, связанные с ними. Перекладывать эту ответственность на пользователей объекта - не просто не по-феншую (тут бы и спора не было). Это чревато. Не по теме: Строго говоря, изначальная идея была в том, что объекты "шлют сообщения" друг другу, толком даже не зная конкретного типа получателя. О прямом доступе к данным и речи не было. Объекты отражали состояние системы, а то, как они в себе хранили ту часть состояния, за которые отвечали, было их личным делом. Эти "сообщения" в большинстве современных языков реализованы вызовами методов.
1
|
|
|
Ушел с форума
|
||||
| 05.01.2014, 23:27 | ||||
|
аксессоров иногда выглядит неестественно. Где-то выше был приведен пример, типа вместо "rect.x += offset" пишут такое: "rect.set_x(rect.get_x() + offset)". Жаль, что в C++ не такой вещи, как properties, это все упростило бы.
Иногда и для public-членов есть место, и для goto, и т.д.
Означает ли это, что ответственность за работу с данными переложена на пользователя и тем самым нарушена инкапсуляция и другие принципы проектирования ? Мой ответ на этот вопрос - нет. Это классы данных, для которых прямой доступ к содержимому так же естественен, как, скажем, взятие адреса или присваивание. Еще раз подчеркну - я не против аксессоров, я против догматического подхода к решению подобных вопросов. Нет таких правил, которые работают везде и всегда и для которых не существует исключений.
1
|
||||
|
|
||||||||||||||||
| 06.01.2014, 16:56 | ||||||||||||||||
|
Убежденный, приведу ещё один довод.
Допустим вы работаете со своими Rectangle:
Если Rectangle реализовать как класс с открытыми членами, то такую подмену реализации так просто провести не удастся.
0
|
||||||||||||||||
|
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
|
||
| 06.01.2014, 17:00 | ||
|
2
|
||
|
Ушел с форума
|
||
| 06.01.2014, 22:14 | ||
|
Из простой сущности с 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
|
|
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
||
| 06.05.2014, 13:32 | ||
|
0
|
||
|
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
|
|||
| 06.05.2014, 15:59 | |||
![]() Но чаще для этого используются другие средства. Не надо путать молоток с отверткой. Но. Где МОЖНО применить ООП - там оно должно быть применено. И то, что Вы не умеете мыслить в категориях ООП, а продолжаете решать свои проблемы структурным программированием - это Ваша проблема. Если бы Вы знали и применяли ООП - то даже вопрос так не стоял бы, про повторное использование кода и тп... ------- Хочу, однако, заметить, что есть одно единственное ограничение ООП, которое я знаю, которое может ограничить его применимость. Это производительность выполняемых операций. Да. ООП добавляет некоторые накладные расходы на вычисления. Поэтому, когда нужны очень скоростные вещи реалтайм или переработка больших объемов информации, то, скорее всего, придется несколько ОПТИМИЗИРОВАТЬ выполнение операций. Но не отказываться от ООП! А оптимизировать тонкие участки. В большинстве случаев - 99% решаемых задач - не особо чувствительны к небольшим потерям, поэтому ловить блох в таких случаях и программировать в машинных кодах - излишне. Прочитав синтаксис языка и пару умных книжек, уже считают себя знатоками ООП. Как же! Они же могут создавать классы! И даже методы умеют писать! Более того! Наследовать классы могут! Вот оно, счастье! А потом встречаю классы с несколькими десятками статических методов по 900 строк кода в каждом. И человек искренне считает, что он написал объектно-ориентированный код.
0
|
|||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
|||||||
| 06.05.2014, 16:45 | |||||||
|
Ну похоже я был прав насчет твоей неосведомленности. Там справа список, можешь ознакомиться.
0
|
|||||||
|
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
|
|
| 06.05.2014, 17:46 | |
|
korvin_
Спасибо за ссылки. ![]() Да, я больше практик, чем теоретик. Поэтому немного плаваю в понятиях, как Вы правильно заметили. И не телепат это точно. Сужу по высказываниям... Работал с очень большим количеством программистов. Были разные мнения и разные споры, как лучше программировать. Возможно, я просто влез со своим мнением немного не в тему, не учел, что здесь обсуждается очень большой набор областей применимости. Мой опыт больше всего касается именно программирования прикладных задач на языках высокого уровня. Задач для конечного пользователя. Поэтому я был так категоричен в отношении применения ООП. Если рассматривать шире, то, как я уже и говорил - давайте закручивать шурупы отвертками, а гвозди забивать? Erlang - как я понял специально разработан для программирования серверных компонент и многопоточных приложений. Возможно (даже скорее всего), его применение будет более оправданно для разработки подобных приложений и операционных систем, чем, например, тот же С. Так же можно сказать, что для разработки сайтов используется php и другие специализированные языки. Там тоже есть, как ни странно ООП, но на самом верхнем уровне. Когда в 99% случаев используются уже ранее разработанные сущности, а не проектируются новые структуры с нуля. Мне, по роду моей работы, приходится работать с очень большим количеством программного кода, качество которого, к сожалению, в большинстве случаев, оставляет желать лучшего. Поэтому я так категоричен в своих высказываниях насчет ООП. Когда начинаешь ставить задачу программисту и говоришь о том, что нужно сделать структуру классов для обработки процесса с возможностью дополнения видов обработки и другими тонкостями и видишь круглые непонимающие глаза, а потом, при приеме работы получаешь один класс с двадцатью статическими методами... становится грустно. Очень грустно. И, главное, не понимает человек, когда ему начинаешь объяснять, что нужно было сделать по другому. Тебе в ответ - "Ну ведь работает же! И я быстро сделал! А когда нужно будет добавить новую обработку, просто добавим еще один статический метод..." А то, что потом этот хлам сыпется при малейшей правке, что методы почти полностью дублируют друг друга за исключением пары строк из 500-900, это горе-программистов не волнует. Это, конечно, крайний случай. Бывают более изощренные хламоделы. Уже опытные и знающие наследование, но не понимающие общей парадигмы ООП. Вот тут появляются такие шедевры, что просто описать невозможно... Чаще всего нарушается инкапсуляция. Да и вообще, зачем она нужна?...
0
|
|
|
|
||||
| 06.05.2014, 18:17 | ||||
|
Добавлено через 1 минуту Добавлено через 1 минуту
0
|
||||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
|
| 06.05.2014, 19:54 | |
|
0
|
|
|
|
||
| 06.05.2014, 20:09 | ||
|
Когда я учился в институте, у нас один делец через ООП решал задачу расстановки 8 ферзей на шахматном поле. Там были класс "поле", "доска", содержащая "поля", "ферзь" и много каких-то умностей, которые уже и не упомню. Жаль, что мне тогда не хватило прозорливости, чтобы сохранить этот код, как образец качественного гавнокода: всё аккуратно структурировано и чётко вылизано, только реализация заняла в 10 раз больше времени, чем простой код на Си (с, грубо говоря, одним массивом из 8 элементов) и работала в несколько раз медленнее
0
|
||
|
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
|
||||
| 07.05.2014, 00:37 | ||||
|
К сожалению, очень многие думают, что умеют, а на самом деле не умеют. Кстати, в примере про двух программистов - оба не правы. Первый слишком далек от практики. В реальной работе так может делаться только в ОЧЕНЬ заформализованных организациях. Я такого не видел. Второй получит как раз неподдерживаемый код из 1000 строк кода (в реальной программе, я не говорю про этот достаточно простой пример) об этом как раз написано в примечании UPD.2 с которым я полностью согласен. респект автору. Грамотно написанная структура с использованием ООП не сыпется. Может посыпаться какой-то конкретный модифицированный кусок функциональности. Но остальная реализация будет работать стабильно как прежде. Есть, конечно, два исключения. 1. Модификация должна делаться тоже программистом знающим ООП. был у меня такой случай. Девочке одной дали задачу - вывести сообщение какое-то при каких-то условиях. Ну она, не долго думая, посмотрела код... о! нужный метод! И в базовом классе в основном методе, который отвечает за поведение всей функциональности воткнула свое сообщение. Дальше можно не продолжать. 2. Появилось новое требование, которое влияет целиком на функциональность. Ну типа рецептов в приведенной ссылке выше, хотя это не самое страшное нововведение. Страшнее было бы например требование, чтобы хлеб выпекался не только в одной печке, а проходил гибкую обработку по нескольким различным устройствам, да еще в параллельном режиме. Ну типа он там подсахаривается и обрезается одновременно... Тут пришлось бы менять немного концепцию. В таких случаях, я оставляю существующую структуру как есть (и для сравнения полезно) и делаю полный рефакторинг кода в новую структуру классов с учетом новых требований. Если просто пытаться в таких случаях исправить поведение существующей системы - конечно, посыпаться может все что угодно.
0
|
||||
| 07.05.2014, 10:52 | ||||
|
0
|
||||
|
|
|||
| 07.05.2014, 13:21 | |||
|
0
|
|||
|
17 / 9 / 2
Регистрация: 18.01.2014
Сообщений: 155
|
|
| 11.05.2014, 01:13 | |
|
0
|
|
| 11.05.2014, 01:13 | |
|
Стоит ли учить ООП в одно время с Яп Как использовать ООП в WinAvr Js class как правильно использовать ООП Когда следует использовать ООП в РНР? WITH AS стоит ли использовать Искать еще темы с ответами Или воспользуйтесь поиском по форуму: |
|
Новые блоги и статьи
|
|||
|
Теория всего 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
Решил тут подумать о возможности сделать лор некоторой комп игры - стратегии, или худжественной книги антиутопии, которые будут юзать планету,которая максимально будет похожа на нашу землю, но где. . .
|