Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 71
Даже не буду пытаться. Хорошо, когда всё работает.
Для себя «открыл» ООП, когда мне потребовалось работать одновременно в одном коде с разными объектами. Полиморфизм называется :).
Очень удобно и практично.
Для себя «открыл» ООП, когда мне потребовалось работать одновременно в одном коде с разными объектами. Полиморфизм называется :).
Очень удобно и практично.
а зачем? пишите как нравиться. до тех пор, пока Ваш стиль остается остается «нормальным» (читай код вменяем, понятен и легко сопровождаем) то все в порядке. Просто без ООП тяжело реализовывать некоторые паттерны (которые опять же не всегда и не везде нужны). everything should be made as simple as possible, but no simpler ©
До вас просто пока «не дошло» то зачем вообще было придумано ООП.
ООП нужно не для программистов одиночек работающих над простыми сайтами (до 50 000 строчек кода), а для группы программистов работающих в команде. Когда некогда бегать и обьяснять каждому что это за команда, что она делает и как ей можно или нельзя пользоваться.
Вот и все. ООП всего лишь модный стиль программирования. Хотите быть в струе — учите. Нет — есть много других прекрасных стилей программирования…
ООП нужно не для программистов одиночек работающих над простыми сайтами (до 50 000 строчек кода), а для группы программистов работающих в команде. Когда некогда бегать и обьяснять каждому что это за команда, что она делает и как ей можно или нельзя пользоваться.
Вот и все. ООП всего лишь модный стиль программирования. Хотите быть в струе — учите. Нет — есть много других прекрасных стилей программирования…
Вот как раз разглядывание двух коллег «в струе» заставило задуматься :) Слишком долго ищут (учитывая, что проект изначально не они делали, а достался по наследству).
А что вы хотите? Поиск нужного места зависит не только и не столько от того, ООП там или процедуры, сколько от понимания Вашими коллегами проекта. И то — если проект написан по-человечески. И то и другое — не зависит от используемой технологии.
Правда, с ООП есть еще один поганых фактор — правильная объектная модель. Я знаком с человеком (программит на perl), половина объектов которого в одном действующем проекте унаследована от объекта CGI (который занимается разбором входных параметров скрипта, работой с хедерами и т.д.). В сочетании с отсутствием логики в наименовании и местоположении методов это превращается в большую проблему. Но согласитесь, отсутствие головы у отдельных личностей — это не проблема концепции разработки.
Правда, с ООП есть еще один поганых фактор — правильная объектная модель. Я знаком с человеком (программит на perl), половина объектов которого в одном действующем проекте унаследована от объекта CGI (который занимается разбором входных параметров скрипта, работой с хедерами и т.д.). В сочетании с отсутствием логики в наименовании и местоположении методов это превращается в большую проблему. Но согласитесь, отсутствие головы у отдельных личностей — это не проблема концепции разработки.
>ООП нужно не для программистов одиночек работающих над простыми сайтами (до 50 000 строчек кода), а для группы программистов работающих в команде.
Вот это да… только что придумали?
Вот это да… только что придумали?
Какие глупости вы пишете )
Ну и где я соврал? :)
ООП это эволюция процедурного программирования, а не какой то стиль. Если вы программист я бы вам советовал больше времени уделить изучению вещей (в данном случае ООП) о которых вы высказываетесь как специалист.
Стиль, парадигма… Не придерайтесь к словам.
ООП — это «эволюция процедурного программирования»? Вот дочего доводит слепая вера в Википедию. о_О
Вы вообще знакомы со Smalltalk? Python? Lisp? Писали на них программы? Если нет то рекомендую сначала чтонибудь написать в перечисленных мною языках а потом говорить о том что все ООП пришло из «процедурного программирования»…
ООП — это «эволюция процедурного программирования»? Вот дочего доводит слепая вера в Википедию. о_О
Вы вообще знакомы со Smalltalk? Python? Lisp? Писали на них программы? Если нет то рекомендую сначала чтонибудь написать в перечисленных мною языках а потом говорить о том что все ООП пришло из «процедурного программирования»…
>> Разубедите?
Вот заняться больше нечем в 2 часа ночи!
Используйте, что вам нравится, главное, чтобы мы с вами по работе не пересеклись. Но это думаю маловероятно.
Вот заняться больше нечем в 2 часа ночи!
Используйте, что вам нравится, главное, чтобы мы с вами по работе не пересеклись. Но это думаю маловероятно.
Напомню, что Cи, например, используется для написания большенства СЛОЖНЕЙШИХ приложений для Linux. Не стоит не любить человека, который не использует ООП.
ООП можно реализовать и на C, это всего лишь ещё одна парадигма программирования. Насколько я знаю, система XFree86, оригинальная X Window, Motif, Gnome — все реализованы в объектно-ориентированном стиле. Да взять хотя бы API работы с файлами/потоками/сокетами в POSIX/UNIX/Linux — он объектно-ориентированный, вполне себе полиморфный.
Одна лишь проблема в C — не так-то просто там наследование реализовать.
Одна лишь проблема в C — не так-то просто там наследование реализовать.
Линукс и почти 100% «базисных» программ под него пишеться на С не потому что С++ и ОПП это не крута, а потому что Линукс и 100% «базисных» программ под него пишеться на С.
Прочитайте еще раз и вдумайтесь :)
С — единственный реально портируемый язык :)
Два года я был разработчиком решений на uCLinux под процессор BlackFin,
под эту платформу НЕТ стабильного компилятора С++
ПРОСТО НЕТ
Как и на очень многие другие платформы, а линуксу надо работать.
Имхо консольный линукс последний оплот С :)
Прочитайте еще раз и вдумайтесь :)
С — единственный реально портируемый язык :)
Два года я был разработчиком решений на uCLinux под процессор BlackFin,
под эту платформу НЕТ стабильного компилятора С++
ПРОСТО НЕТ
Как и на очень многие другие платформы, а линуксу надо работать.
Имхо консольный линукс последний оплот С :)
>> Процедуральное vs. объектно ориентированное программирование
Процедуральное? А чего тогда не объектарно-ориентировочное?
Процедуральное? А чего тогда не объектарно-ориентировочное?
Объектно-ориентированное программирование хорошо тем, что гораздо более очевидно.
Есть объект, есть его внутреннее состояние, есть поведение, которое меняет внутреннее состояние как самого объекта, так и других.
В случае процедурного программирования, состояние объекта становится отделено от его поведения.
Хорошо это или плохо? Однозначного ответа дать нельзя. Однако, в случае сложной и запутанной логики (а это почти любая бизнес-логика) применение ООП сильно облегчает жизнь.
Кроме того, процедурное программирование провоцирует плохой стиль написания кода — всегда есть соблазн работать с состоянием напрямую, минуя специализированные функции. В результате получается спагетти-код, когда уже нельзя найти, где кончается бизнес-логика и начинается вывод информации. Посмотрите любой исходник быдлопроекта на дельфи, где код логики формы нередко пишется в обработчиках событий.
Есть объект, есть его внутреннее состояние, есть поведение, которое меняет внутреннее состояние как самого объекта, так и других.
В случае процедурного программирования, состояние объекта становится отделено от его поведения.
Хорошо это или плохо? Однозначного ответа дать нельзя. Однако, в случае сложной и запутанной логики (а это почти любая бизнес-логика) применение ООП сильно облегчает жизнь.
Кроме того, процедурное программирование провоцирует плохой стиль написания кода — всегда есть соблазн работать с состоянием напрямую, минуя специализированные функции. В результате получается спагетти-код, когда уже нельзя найти, где кончается бизнес-логика и начинается вывод информации. Посмотрите любой исходник быдлопроекта на дельфи, где код логики формы нередко пишется в обработчиках событий.
А вообще, меня всегда умиляло. ООП как парадигме уже около 20 лет, она является общепринятым стандартом промышленного программирования, успешно используется для разных задач, и, кстати, пришла на смену процедурному программированию, которое чем-то людей не устраивало. И тут (20 лет спустя) приходит человек и говорит, что это все неправильный фен-шуй, и вообще вы тут все фигней страдаете, а процедурное программирование рулит. Не знаешь, что и делать — то ли лесом слать, то ли отправлять книжки читать.
Я не говорю, что ООП неправильно. Я пытаюсь разобраться что верно, а что — нет.
Посмотрел бы я, как бы вы отправили Дейкстру, Вирта, Брукса и многих других читать книжки :)
ООП подход не пришел на смену процедурному подходу, а дополнил его. Как и любая другая парадигма, ООП имеет и достоинства, и недостатки, поэтому в его критике нет ничего странного.
ООП подход не пришел на смену процедурному подходу, а дополнил его. Как и любая другая парадигма, ООП имеет и достоинства, и недостатки, поэтому в его критике нет ничего странного.
Скорее всего вы просто «не доросли» до ООПа. В объектно ориентированном программировании как ни странно главное объект. Если вы смоете абстрагироваться от задачи и выделять архитектурные объекты вот тогда вы в полной мере смоете оценить ООП. Даже не знаю как вам все это на пальцах разложить, это слишком обширная тема. Вот вам небольшой пример: шаблон DAO. Если вы не в курсе DAO шаблон помогает нам добираться до нужных нам данных. Мы реализуем базовый класс(или интерфейс) commonDAO, создаем в нем общие методы create, read, update, delete. Дальше реализуем логику, допустим данные наши хранятся в БД. Наследумся от commonDAO реализуем заранее определенные методы для доступа к таблице. Вот вобщем и все ) А тут вдруг приходит заказчик и говорит — «Чето не хочу я БД давайте лучше данные будем хранить в XML». Как вы бы решили эту задачу без ООПа? Я просто создам DAO объект позволяющий работать с XML и просто подменить создание класса. Т.к. наша программа умеет работать с commonDAO то и с его наследниками будет работать. Еще один плюс эти commonDAO, SQLDAO и XMLDAO я могу использовать в следующих проектах.
Надеюсь я доступно объяснил. Пример который я вам привел это самый простой и неинтересный.
Надеюсь я доступно объяснил. Пример который я вам привел это самый простой и неинтересный.
Возможен и другой вариант развития событий:
Приходит заказчик и говорит — «А чё ваша прога так тормозит?».
А вы ему — «Зато мы можем хранить данные не в базе, а в XML, CSV, и еще миллионе форматов! И мы можем использовать это в следующих проектах!11».
Заказчик: «Ну и нафига оно мне нужно? Делайте чтоб быстро работало, а то «следующих проектов» у вас не будет».
Приходит заказчик и говорит — «А чё ваша прога так тормозит?».
А вы ему — «Зато мы можем хранить данные не в базе, а в XML, CSV, и еще миллионе форматов! И мы можем использовать это в следующих проектах!11».
Заказчик: «Ну и нафига оно мне нужно? Делайте чтоб быстро работало, а то «следующих проектов» у вас не будет».
Т.е. ООП по дефолту медленне процедурного подхода? )) Без привязки к языку, платформе, задаче — тупо медленнее?
Практически всегда — медленнее. ООП даёт дополнительную абстракцию, которую невозможно получить без дополнительных расходов.
эм… пруф?
Очень хочется услышать почему?
Ну скажем так… Качественно написанный код при объектном подходе если и будет работать медленнее, чем при процедурном — то на несколько процентов, явно не в разы. Зато эффективность разработки возрастет несоизмеримо.
А вообще, мейнстрим — языки редко смешивают два подхода (вспомню, пожалуй, только Питон) — так что выбор подхода чаще определяется выбором языка.
А вообще, мейнстрим — языки редко смешивают два подхода (вспомню, пожалуй, только Питон) — так что выбор подхода чаще определяется выбором языка.
Запустите на своей проге профайлер, и вам придется долго искать в выдаче методы, которые (почти) ничего не делают, даже если они будут дергаться достаточно часто. Даже если Вы переведете эти методы в функции — картинка не изменится. Зато в топе Вы найдете десяток методов, которые слопают 99% времени выполнения скрипта. Если быстродействие критично, гораздо логичнее что-то сделать именно с ними.
Вот опровержение — metamatix.org/~ocaml/price-of-abstraction.html
Спасибо за пример, но это скорее подтверждение моих слов, чем опровержение :)
Во-первых потеря 4% на примитивном классе это не так уж и мало, во-вторых не cpp/gcc единым, в-третьих хотелось бы увидеть как оно себя поведет без флагов оптимизации.
Да и здесь в комментариях автор сам пишет, что видел случаи значительных потерь производительности из-за абстракции: www.arachnism.blogspot.com/2009/05/price-of-abstraction.html
Во-первых потеря 4% на примитивном классе это не так уж и мало, во-вторых не cpp/gcc единым, в-третьих хотелось бы увидеть как оно себя поведет без флагов оптимизации.
Да и здесь в комментариях автор сам пишет, что видел случаи значительных потерь производительности из-за абстракции: www.arachnism.blogspot.com/2009/05/price-of-abstraction.html
Нет, с ооп ваш код становится более «правильным», логичным. Я даже думаю что он ускорит как работу так и разработку. Я имею ввиду большие проекты.
Заказчики очень любят когда им показывают результат. Применение парадигмы ООП позволит, например, сначала выводить список юзеров из xml (когда база будет ещё не готова), в дальнейшем безболезненно перейти на *sql.
Такого заказчика надо посылать сразу. Вы знаете хоть один реальный пример смены хранилища данных? Тем более во время программирования проекта. Лучше уж выбрать базу данных под свои нужды, и использовать все возможности по управлению данными, чем загонять код в ОО обертки и пользоваться лишь общими для всех баз данных возможностями.
Когда заказчик платит хорошие деньги, такие «капризы» ему можно простить)
Вы ничего не поняли. Это же «абстрактная» задача. Резкой сменой хранилища я хотел показать гибкость ооп подхода, возможности…
На вскидку другой пример: наша программа должна сама решать откуда брать данные (если нет коннекта к БД лезем в кэш пусть он будет в XML формате). Мне ненужно будет ломать архитектуру, есть же общий предок commonDAO.
На вскидку другой пример: наша программа должна сама решать откуда брать данные (если нет коннекта к БД лезем в кэш пусть он будет в XML формате). Мне ненужно будет ломать архитектуру, есть же общий предок commonDAO.
Зато Вам никто не мешает держать набор оберток для разных хранилищ в рамках одного движка, и менять их в разных проектах в зависимости от задачи. «Снаружи» объекта этого никто не заметит.
В чем-то BarsLV прав, иногда без объектов и классов проще. В django вон тоже процедурный стиль используется часто. Вид там (контроллер в обычной терминологии MVC) — обычная функция, например. Но это возможно из-за удачной архитектуры (построенной, конечно, на ООП) — код контроллеров обычно выходит довольно простой — будь они объектами, содержали бы в среднем чуть больше 1 метода. Кроме этого, помогает приличная примесь всяких штук из ФП в питоне (функции-декораторы, лямбды всякие и т.д.)
А большинство задач с использованием ООП все ж решаются проще и красивее, чем процедурным подходом. Думаю, раз автор задался уж вопросом, ему будет интересно почитать «Паттерны проектирования» by GOF, книжки Мартина Фаулера про паттерны и про рефакторинг, чтоб взглянуть на мир со стороны сугубо объектно-ориентированной.
А большинство задач с использованием ООП все ж решаются проще и красивее, чем процедурным подходом. Думаю, раз автор задался уж вопросом, ему будет интересно почитать «Паттерны проектирования» by GOF, книжки Мартина Фаулера про паттерны и про рефакторинг, чтоб взглянуть на мир со стороны сугубо объектно-ориентированной.
А там сложно понять где вообще объект в привычном понимании, а где функция (да да я знаю, что функция тоже объект). В конечном итоге views.py в котором определены вьющки я для себя воспринимаю как класс с кучей статических методов.
Ну справедливости ради надо сказать, что все модели наследуются от общего предка, а любое расширение функционала будь то ввод своих тегов в шаблонизатор или создание полей для моделей делается через наследование, т.е. вполне себе оопшным подходом.
Гляньте синтаксис для определения тех же тегов в шаблонизатор, из оф. документации:
Когда можно — никакого синтаксического оверхеда в виде определения класса, обычная функция + декоратор к ней.
Архитектура — на ООП всегда, тут Вы правы.
@register.simple_tag
def current_time(format_string):
return datetime.datetime.now().strftime(format_string)
Когда можно — никакого синтаксического оверхеда в виде определения класса, обычная функция + декоратор к ней.
Архитектура — на ООП всегда, тут Вы правы.
Как хорошо называется топик «Процедурное vs. объектно ориентированное программирование»
А вы что больше любите — яблоки или груши?
Я почти уверен что в 99% программ с ООП подходом есть много обычный функций(int main?), а во многих ПП программ есть структуры данных и функции работы с ними.
Только почему то, по чьему то недочету, эти структуры данных и функции работы с ними разнесены.
Не прав тот что говорит что ООП\ПП это хорошо а ПП\ООП это для лохов- Непредубежденность
Прав тот что говорит что оба подхода имеют место.
выбери свое, а лучше немного подумай и придумай свое, хабрачитатель, и обоснуй себе свой выбор
А вы что больше любите — яблоки или груши?
Я почти уверен что в 99% программ с ООП подходом есть много обычный функций(int main?), а во многих ПП программ есть структуры данных и функции работы с ними.
Только почему то, по чьему то недочету, эти структуры данных и функции работы с ними разнесены.
Не прав тот что говорит что ООП\ПП это хорошо а ПП\ООП это для лохов- Непредубежденность
Прав тот что говорит что оба подхода имеют место.
string user=user_getById(id);
string user=Users::getById(id);
CUser user=new CUser(id); user->getName();
выбери свое, а лучше немного подумай и придумай свое, хабрачитатель, и обоснуй себе свой выбор
Все нужно применять к месту. не буду утверждать что лучше а что хуже. просто приведу пример реальной задачи:
Приложение работает с БД. Для получения данных используются разные функции:
-getRow()
-getRows()
-getColumn()
-getColumns()
-query()
-inset()
-…
Понятно что внутри функций выполняется какойто SQL.
Нужно сохранять все sql-запросы и замерять время работы каждого. для статистики.
1) ООП: я просто создам у объекта БД несколько private свойств-массивов и внутри каждой из перечисленных функций буду вычислять и сохранять sql-запросы в свойство-массив.
2) ПП:
-мне придется создать единую базовую функцию с статическим массивом для хранения sql -запросов и переписать существующие функции, чтобы они стали обертками к базовой
-хранить sql-запросы в глобальной переменной (но тогда доступ к этим запросам смогут получить даже те кому нельзя)
-писать отдельно функцию для сохранения sql-запросов (необоснованное размазывание логики сохранения этих запросов)
уверен — есть еще куча решений данной задачки, как в ООП так и в ПП.
МНЕ, именно эту задачу, проще, понятнее и логичнее реализовать в ООП )
Приложение работает с БД. Для получения данных используются разные функции:
-getRow()
-getRows()
-getColumn()
-getColumns()
-query()
-inset()
-…
Понятно что внутри функций выполняется какойто SQL.
Нужно сохранять все sql-запросы и замерять время работы каждого. для статистики.
1) ООП: я просто создам у объекта БД несколько private свойств-массивов и внутри каждой из перечисленных функций буду вычислять и сохранять sql-запросы в свойство-массив.
2) ПП:
-мне придется создать единую базовую функцию с статическим массивом для хранения sql -запросов и переписать существующие функции, чтобы они стали обертками к базовой
-хранить sql-запросы в глобальной переменной (но тогда доступ к этим запросам смогут получить даже те кому нельзя)
-писать отдельно функцию для сохранения sql-запросов (необоснованное размазывание логики сохранения этих запросов)
уверен — есть еще куча решений данной задачки, как в ООП так и в ПП.
МНЕ, именно эту задачу, проще, понятнее и логичнее реализовать в ООП )
OOP — это один из способов борьбы с complexity problem. Если у вас нет complexity problem — то зачем Вам средство для борьбы с этой тварью? :).
А если вам придется описать поведение нового элемента. Точно такого же, как старый, только «побольше, но другого»? Будете переписывать функции? А если надо будет 5 примерно похожих элементов — это сколько же функций надо? Вот тут начинается каша.
Узнайте про наследование, вы будете в шоке.
Сам пишу настолько в ООП, что просто отдельных процедур нет. Все только внутри классов, не поверите, насколько это удобно.
Узнайте про наследование, вы будете в шоке.
Сам пишу настолько в ООП, что просто отдельных процедур нет. Все только внутри классов, не поверите, насколько это удобно.
CMS занимающая чуть более 5кб вряд ли представляет ценность.
невозможно вместить много хорошего функционала в такой объём.
изучение 5кб-ной CMS за неделю? о_О
невозможно вместить много хорошего функционала в такой объём.
изучение 5кб-ной CMS за неделю? о_О
приходилось пересаживаться на крупные самописные кемто или популярные фреймворки.
если там все по уму и с ООП, то можно через 15 минут начинать писать модули даже БЕЗ чьих-то пояснений. потому что сразу видно что там и где, где лежат одни объекты а где другие, что к чему относится. Все разложено по полочкам и иерархиям наследования.
если бы был просто набор функций то действительно надо сначала вникать и упорядочивать все это у себя в голове.
а с ООП уже все упорядочено и локализовано, использую API класса и пиши…
так что плохого в ООП очень мало
если там все по уму и с ООП, то можно через 15 минут начинать писать модули даже БЕЗ чьих-то пояснений. потому что сразу видно что там и где, где лежат одни объекты а где другие, что к чему относится. Все разложено по полочкам и иерархиям наследования.
если бы был просто набор функций то действительно надо сначала вникать и упорядочивать все это у себя в голове.
а с ООП уже все упорядочено и локализовано, использую API класса и пиши…
так что плохого в ООП очень мало
В программах, написанных в процедурном стиле часто встречаются недостатки, которых в ООП нет. Например, длинные списки параметров. Возьмем, например прототип одной из самых известных функций из GD:
Я бы не сказал что это удобно. Было бы намного удобней поьзоваться такими объектами как Изображение, Точка, Ресурс и т. д.
bool imagecopyresized ( resource $dst_image , resource $src_image , int $dst_x , int $dst_y , int $src_x , int $src_y , int $dst_w , int $dst_h , int $src_w , int $src_h );Я бы не сказал что это удобно. Было бы намного удобней поьзоваться такими объектами как Изображение, Точка, Ресурс и т. д.
покажите, пожалуйста, ваш код.
Для решения конкретных небольших сильно частных задач «в жало» — процедурный подход только даст плюсы, но ООП даст большее поле для маневра при создании библиотек решающий большей спектр задач до конца не сформулированных сейчас.
Насколько легко тебе сменить БД на своих сайтах с MySQL на sqllite?
Насколько легко тебе сменить БД на своих сайтах с MySQL на sqllite?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Процедурное vs. объектно ориентированное программирование