Разговоры на завалинке о ООП - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Навязывать не надо, но очевидно что в процедурном виде уже просматривается логика кода без лишних телодвижений, а каждое телодвижение наемного программиста стоит работодателю денежку. Поэтому если работодатель не дурак, то он не поведется на ООП, но зато хитрый программист может ему навешать лапшу про прогрессивность ООП чтобы срубить с него побольше воспользовавшись его малограмотностью. :)
Ха !
Дык ведь в передвижении пешком - тоже просматривается логика "без лишних телодвижений", но почему-то все норовят ехать на транспорте. Доходит до маразма - садятся на автомобиль, едут два километра до фитнес-центра, чтобы там на беговой дорожке "намотать" пять километров.
Поближе к программированию - в ДОСе окно создается простой записью в видеобуффер. А для того, чтобы создать простейшее окно в Виндовс - надо зарегистрировать класс окна, создать его, запустить цикл обработки сообщений - но, почему-то все делают эти самые "лишние телодвижения".
Так и тут. ООП - выбирается вовсе не за "прогрессивность", а за те преимущества, которые эта методика предоставляет, и потому, что оно в конечном счете дешевле для работодателя. Потому, что написав что-то в процедурном стиле - вы потом его не сможете поддерживать с той же эффективностью, что и написанное в ООП-стиле.
Хорошая иллюстрация - код Peter Konov - с одной стороны, вполне себе нормальный процедурно-ориентированный код, но с другой стороны, чтобы с ним работать - нужно постоянно держать в уме такую кучу информации по структуре системы, что лично я за такую задачу даже за большие деньги не возьмусь. В тоже время, СБ, написанная в ООП-стиле - очень даже удобна для поддержки и изменения. Архитектура объектов в шаблоне ТС Стандартной Библиотеки - гораздо хитрее, чем в коде Peter'a, однако, понять и модифицировать ее - куда легче.
Все разговоры про то, что "процедурный стиль без лишних телодвижений" - это лишь до того момента, как потребуется написать реально сложную структуру, а особенно, внести в нее модификацию. Именно поэтому ООП и используется так широко - он проще для программистов, и дешевле для заказчиков. Хотя, сделать что-то совсем простое на нем требует "лишних телодвижений". Просто это самое "простое" - никому не нужно, всем нужно "сложное", которое лучше делать с помощью ООП.
P.S. И я так и не понял, как ты (давай на "Ты") предлагаешь ограничить доступ к функциям, которые не должны использоваться где попало без ООП-модификаторов доступа ?
George Merts:
Потому, что написав что-то в процедурном стиле - вы потом его не сможете поддерживать с той же эффективностью, что и написанное в ООП-стиле.
P.S. И я так и не понял, как ты (давай на "Ты") предлагаешь ограничить доступ к функциям, которые не должны использоваться где попало без ООП-модификаторов доступа ?Да нет же. Все как раз наоборот.
ООПешный код как раз таки сложно поддерживать и модифицировать ибо логика там сокрыта кучей разных выкрутасов, что потом проще заново код написать. Ведь так и говорится, что цель ООП это скрыть логику, ну вот и скрыли, а если вдруг понадобится раскрыть, то это уже сервис за дополнительную плату.
Обертка функции позволяет скрыть внутренние функции, но если вдруг руки сильно чешутся, что так и хочется абы для чего эту внутренную функцию прикрутить, то можно и в ДЛЛ-ку спрятать либо исходник в отдельный файл, а файл в самую далекую директорию чтобы при всем желании было не найти, может еще есть варианты для особо буйных программистов. :)
Да нет же. Все как раз наоборот.
ООПешный код как раз таки сложно поддерживать и модифицировать ибо логика там сокрыта кучей разных выкрутасов, что потом проще заново код написать. Ведь так и говорится, что цель ООП это скрыть логику, ну вот и скрыли, а если вдруг понадобится раскрыть, то это уже сервис за дополнительную плату.
Обертка функции позволяет скрыть внутренние функции, но если вдруг руки сильно чешутся, что так и хочется абы для чего эту внутренную функцию прикрутить, то можно и в ДЛЛ-ку спрятать либо исходник в отдельный файл, а файл в самую далекую директорию чтобы при всем желании было не найти, может еще есть варианты для особо буйных программистов. :)
С чего бы это "сложно модифицировать", если логика скрыта ? Логика для того и скрывается, чтобы у тебя не было возможности ничего модифицировать там, где этого делать нельзя.
Это как раз в процедурном подходе ты захотел что-то изменить, изменил, а потом не понимаешь, почему не работает (или хуже того - вылезают ИНОГДА непонятные ошибки). А в ООП подходе ты захотел это изменить - а у тебя нет никакого доступа к внутренностям класса. И раз доступа нет - значит, это сделано не просто так, что-то там хитрое есть, какие-то неявные условия применения. Соответственно, если хочешь что-то изменить - то берешь этот самый класс, наследуешь от него свой собственный класс, и изменяешь там то, что тебе надо, в наследнике-то ты уже к протектед-методам доступ имеешь.
Причем, даже пронаследовавшись - ты можешь нарваться на приватный метод или поле - недоступное даже в наследнике, и раз это сделано - опять же, неспроста, значит, это поле не предназначено для изменения даже в потомке.
Разговоры насчет "скрыть в ДЛЛку" - тут проблема, что ты в ДЛЛку можешь скрыть только сразу ВСЕ. А не часть объекта. А модификатор доступа как раз для того и нужен, чтобы скрыть только часть объекта. Для этого же и затевается все - чтобы программист в каждом месте программы имел доступ только к тому, что ему необходимо, и ни к чему "сверху" - это позволяет не опасаться, что он случайно изменит не то, что надо, но сможет изменить часть, которая допустима для модификации. И какой смысл тогда в ДЛЛ ? Открывать код ДЛЛ - тогда доступ открывается весь, а не части. Закрыть - опять же, закроется весь доступ.
Я не знаю, как можно ограничить доступ в процедурном стиле без применения private-protected-public секций. А это ограничение мне очень часто помогает.
С чего бы это "сложно модифицировать", если логика скрыта ? Логика для того и скрывается, чтобы у тебя не было возможности ничего модифицировать там, где этого делать нельзя.
Это как раз в процедурном подходе ты захотел что-то изменить, изменил, а потом не понимаешь, почему не работает (или хуже того - вылезают ИНОГДА непонятные ошибки). А в ООП подходе ты захотел это изменить - а у тебя нет никакого доступа к внутренностям класса. И раз доступа нет - значит, это сделано не просто так, что-то там хитрое есть, какие-то неявные условия применения. Соответственно, если хочешь что-то изменить - то берешь этот самый класс, наследуешь от него свой собственный класс, и изменяешь там то, что тебе надо, в наследнике-то ты уже к протектед-методам доступ имеешь.
Причем, даже пронаследовавшись - ты можешь нарваться на приватный метод или поле - недоступное даже в наследнике, и раз это сделано - опять же, неспроста, значит, это поле не предназначено для изменения даже в потомке.
Разговоры насчет "скрыть в ДЛЛку" - тут проблема, что ты в ДЛЛку можешь скрыть только сразу ВСЕ. А не часть объекта. А модификатор доступа как раз для того и нужен, чтобы скрыть только часть объекта. Для этого же и затевается все - чтобы программист в каждом месте программы имел доступ только к тому, что ему необходимо, и ни к чему "сверху" - это позволяет не опасаться, что он случайно изменит не то, что надо, но сможет изменить часть, которая допустима для модификации. И какой смысл тогда в ДЛЛ ? Открывать код ДЛЛ - тогда доступ открывается весь, а не части. Закрыть - опять же, закроется весь доступ.
Я не знаю, как можно ограничить доступ в процедурном стиле без применения private-protected-public секций. А это ограничение мне очень часто помогает.
Жорж, опять ты мечешь бисер ))) Это же бессмысленно
Жорж, опять ты мечешь бисер ))) Это же бессмысленно
Может быть, может быть.
Но это ж ты у нас по совместительству Казанова... А я по совместительству - репетитор. Вижу, что "клиент не потерян". Соответственно, продолжаю объяснения. Типа "профессиональная деформация".
Может быть, может быть.
Но это ж ты у нас по совместительству Казанова... А я по совместительству - репетитор. Вижу, что "клиент не потерян". Соответственно, продолжаю объяснения. Типа "профессиональная деформация".
Достал с казановами. Придумал сказку и сам в нее поверил ) как ребенок в Деда Мороза, ей богу )
Навязывать не надо, но очевидно что в процедурном виде уже просматривается логика кода без лишних телодвижений, а каждое телодвижение наемного программиста стоит работодателю денежку.
Количество телодвижение в приведенном процедурном коде понадобится больше, если потребуется внести изменения.
Можно код писать без функций (процедур). Но кодинг со временем перестал писаться через "заливку бетоном", а стал строить из "кирпичиков". Отсюда пошло процедурное программирование.
ООП - это еще одна ступень разбития общей работы на более простые составляющие.
Разделение труда и, как следствие, конвейеризация производства чего-либо создало промышленную революцию, повлекшую за собой индустриализацию человечества.
Hand-made - это "написание кода без процедур".
Конвейер - "процедурное написание кода", где много элементов конвейера находится в зависимости от остальных. Т.е. изменение одного элемента может потребовать изменения другого.
"ООП-программирование" - это конвейер с уменьшенной зависимостью между элементами. Т.е. один элемент можно заменить на другой и при этом конвейер имеет меньшую вероятность, что перестанет работать. Умение разбивать любое производство на независимые части, ввод стандартов и т.д. - это Объекто Ориентированное Производство (не программирование).
Само программирование - это частный случай производства. ООП-подход - это принципиальный подход к производству чего угодно. Поэтому говорить о программировании - очень узко. ООП был успешно применен ДО появления его в программировании.
Достал с казановами. Придумал сказку и сам в нее поверил ) как ребенок в Деда Мороза, ей богу )
Да я тебе завидую, Лёха !
Вполне серьезно. Ну и оставь мне право на небольшую художественную гиперболу...
Количество телодвижение в приведенном процедурном...
О ! Хорошо сказал.
Полностью поддерживаю.
Количество телодвижение в приведенном процедурном коде понадобится больше, если потребуется внести изменения.
Да не может быть количество телодвижений при ООП меньше в принципе, так как все эти интерфейсы - это добавочные накладные расходы, которые часто превышают расходы на написание самой логики. И это при том, что интерфейс уже и так имеется у любой функции, то есть предлагается городить еще один огород, который по сути бессмысленен.
При этом значительно усложняется любое изменение кода как в интерфейсе так и в функции, так как одно зацеплено на другое, то есть имеем как минимум квадратичное увеличение возможного количества багов и трудоемкости... Вроде ведь очевидно.