|
|
| Результаты опроса: используете ли вы ооп | |||
| да |
|
238 | 86.55% |
| нет |
|
37 | 13.45% |
| Голосовавшие: 275. Вы ещё не голосовали в этом опросе | |||
|
|
Рейтинг 4.76/461:
|
|
81 / 39 / 3
Регистрация: 29.01.2010
Сообщений: 386
|
|
Стоит ли использовать ООП?09.02.2010, 13:44. Показов 103067. Ответов 793
Метки нет (Все метки)
Здравствуйте.
Возник такой вопрос: стоит ли использовать ооп. Даже не так, когда использовать ооп? Иногда (даже чаще всего) легче написать простые функции, а не мутить с классами обектами и методами. Раздражает инкапсуляция - какой вообще ее смысл? Чтобы получить переменную класса по правилам ооп нужно создавать метод для ее чтения? когда такой подход оправдан - ведь затрачивается куча лишнего времени.
5
|
|
| 09.02.2010, 13:44 | |
|
Ответы с готовыми решениями:
793
Стоит ли использовать ООП -- часть вторая
|
|
10 / 10 / 4
Регистрация: 12.10.2013
Сообщений: 249
|
|||
| 30.12.2013, 12:07 | |||
![]()
0
|
|||
| 30.12.2013, 12:10 | |
|
2
|
|
|
5828 / 3479 / 358
Регистрация: 08.02.2010
Сообщений: 7,448
|
||
| 30.12.2013, 12:15 | ||
|
Помимо контроля за корректностью значений поля, эти геттеры/сеттеры могут выполнять дополнительные функции, например, запись в лог, работу с кэшем и т. д.
0
|
||
|
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
|
|||||||||||
| 30.12.2013, 12:25 | |||||||||||
0
|
|||||||||||
|
|
||
| 30.12.2013, 12:32 | ||
|
1
|
||
|
10 / 10 / 4
Регистрация: 12.10.2013
Сообщений: 249
|
|||||||
| 30.12.2013, 15:29 | |||||||
0
|
|||||||
|
5828 / 3479 / 358
Регистрация: 08.02.2010
Сообщений: 7,448
|
|||||||||||||
| 30.12.2013, 15:35 | |||||||||||||
0
|
|||||||||||||
| 30.12.2013, 17:36 | |||
На таком примере ничего не увидеть (хотя и здесь контроль диапазона - верный пример). Вообще пока Вы берете один класс (без разницы простой или сложный) - никаких проблем нет. Они начинаются когда классы начинают взаимодействовать друг с другом. Понятно что один класс что-то должен знать о другом - иначе этого другого никак не использовать. Но вот "сколько" - это баааальшой вопрос Прямолинейный подход - да просто все о всех знают! (все public) очень быстро оказывается плохим, тупиковым. Ну это надо пережить/прочувствовать на практике.
0
|
|||
|
10 / 10 / 4
Регистрация: 12.10.2013
Сообщений: 249
|
|||||||
| 30.12.2013, 19:09 | |||||||
0
|
|||||||
|
5828 / 3479 / 358
Регистрация: 08.02.2010
Сообщений: 7,448
|
||
| 30.12.2013, 19:46 | ||
|
Смысл проверок не столько в том, чтобы не допустить некорректных значений, а в том, чтобы выявить эти некорректные значения как можно раньше. Также нужно иметь возможность локализовать место возникновения некорректных данных. Как только ты присвоил полю H некорректное значение, можешь считать, что твой объект поломан. Узнать, что он поломан, ты можешь только вызвав метод CalcArea и получив исключение. Но от момента "поломки" объекта до вызова CalcArea может произойти какое-то время, и сам вызов этот может произойти в совсем другой точке программы. При этом ты уже не сможешь узнать, в каком именно месте ты передал неверные данные. Также не стоит забывать, что доступ к этим полям всегда может вернуть некорректные данные, поэтому тебе придётся их проверять.
0
|
||
|
10 / 10 / 4
Регистрация: 12.10.2013
Сообщений: 249
|
|
| 30.12.2013, 21:09 | |
|
0
|
|
|
5828 / 3479 / 358
Регистрация: 08.02.2010
Сообщений: 7,448
|
||||||
| 30.12.2013, 22:19 | ||||||
|
Нитонисе, ясное дело, что можно. Но для этого пользователям твоего класса нужно обязательно знать, какие допустимые значения могут принимать поля твоего класса. И не дай б-г они забудут сделать проверку перед тем, как записать некорректное значение в поле Rectangle — никакого внятного сообщения об ошибке они в этом случае не получат. В худшем случае даже самой ошибки (исключения) не будет, твоя программа просто продолжит работать неправильно.
А теперь рассмотрим пример чуток посложнее. Представь, что ты пишешь класс рациональных дробей (Fraction). Дроби поддерживают операции +, -, *, /. Класс использует два целочисленных поля — числитель и знаменатель, причем знак числителя определяет знак дроби. Сокращение дроби надо производить только тогда, когда понадобится её строковое значение либо значение её компонент (числителя/знаменателя). Попробуй написать реализацию этого класса без свойств так, чтобы инвариант класса (знаменатель положителен) выполнялся и дробь сокращалась только тогда, когда это нужно. Вот для сравнения код на Scala со свойствами: Кликните здесь для просмотра всего текста
0
|
||||||
|
10 / 10 / 4
Регистрация: 12.10.2013
Сообщений: 249
|
||
| 31.12.2013, 02:20 | ||
|
0
|
||
|
5828 / 3479 / 358
Регистрация: 08.02.2010
Сообщений: 7,448
|
|||||
| 31.12.2013, 05:57 | |||||
|
В конце концов, проще и логичнее написать одну проверку внутри класса, чем N внешних проверок. А вообще, для себя ты можешь писать как угодно, хоть циклы на безусловных переходах делать.
0
|
|||||
|
Фрилансер
3709 / 2083 / 567
Регистрация: 31.05.2009
Сообщений: 6,683
|
||
| 01.01.2014, 23:53 | ||
|
Но еще раз повторю уже прозвучавшую мысль: ООП - инструмент. Если Вам трудно работать с ООП - не работайте. И еще одно повторю: ООП не столько инструмент программирования, сколько инструмент организации предметной области. Грубо говоря, о проекте проще думать уже в терминах ООП. И опять же - если Вам это не подходит - не используйте
3
|
||
|
|
|
| 02.01.2014, 15:02 | |
|
Black Fregat, позволю себе добавить: использование интерфейсов в отличии от публичных методов позволяет расширять класс, не изменяя его кода. Например, навесить функционал логирования, профилирования или кеширования результатов сложных вычислений через декоратор, прописав его инициализацию в фабрике. Пользователь объекта даже не узнает, что работает с экземпляром другого класса, что позволит избежать изменений в коде этого пользователя.
Кроме того, использование интерфейсов позволяет производить полную подмену реализации. Например, использовать различные стратегии вычислений в зависимости от доступных наборов инструкций.
0
|
|
|
10 / 10 / 4
Регистрация: 12.10.2013
Сообщений: 249
|
|||||||
| 02.01.2014, 16:22 | |||||||
Что касается ООП в общем, то я считаю кое-где этот принцип использовать можно. Но важно не перестараться и очень умело выделять сущности. Часто можно все обернуть в классы и тем самым усложнить все сверх меры. Если отдавать себе отчет в том, какую конкретно можно извлечь пользу из объектного подхода - тогда ООП может облегчить разработку.
0
|
|||||||
|
5828 / 3479 / 358
Регистрация: 08.02.2010
Сообщений: 7,448
|
|
| 02.01.2014, 16:32 | |
|
0
|
|
| 02.01.2014, 16:32 | |
|
Стоит ли учить ООП в одно время с Яп Как использовать ООП в 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
Решил тут подумать о возможности сделать лор некоторой комп игры - стратегии, или худжественной книги антиутопии, которые будут юзать планету,которая максимально будет похожа на нашу землю, но где. . .
|