Вопрос знатокам ООП. - страница 10
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Ну и я так же - понемногу... а полное понимание только через 4-5 лет приходит (и это для обычного человека нормально)
На мой взгляд, "полное понимание" - и не надо. Главное - "уцепить суть". Я, когда познакомился с меодологией ООП - это был 1995 год.
У меня уже был некоторый опыт работы на "обычном С" в духе K&R (олдфаги должны помнить), кроме того, я довольно часто использовал ассемблерные функции. Я сперва довольно скептически отнесся к идеям ООП, даже не столько из-за того, что программисту надо совершать какие-то дополнительные действия, а из-за чисто процессорного "оверхеда". Но весьма быстро убедился в пользе этой технологии. Главным "переключателем" моего мнения стал класс CString.
Мало того, что работа со строками сильно упрощалась. В то время мы писали упаковщик данных, моей частью был анализатор входного текста. Соответственно, на базе класса CString оказалось очень удобно создать иерархию различных строк, имеющих важные отличия для нашего упаковщика.
Особенно мне понравилось как раз то, что уже после того, как упаковщик данных был написан - появилась задача использовать его для строк, в которых было много цифровой информации, на которую изначально упаковщик не был расчитан. Он, безусловно, упаковывал и такие данные, однако, делал это, считая входной алфавит просто символами, но знание, что строка состоит из нескольких слов и цифр - существенно улучшало упаковку без потери скорости работы. Так вот, класс, представляющий собой такие вот строки с цифрами (а также специфический компрессор для цифр) - был написан, все было добавлено к уже существующим классам, и упаковщик стал работать с новыми данными, хотя изначально такой функциональности не предполагалось.
Вот тогда я и заценил возможности ООП по модификации и поддержке кода. Безусловно, процессорный оверхед при этом существует, но это с лихвой компенсируется уменьшением работы программистов.
Поэтому и всем, кто начинает изучать ООП, я рекомендую начать работу с таких задач, где бы преимущество ООП было бы хорошо и наглядно видно. То есть с задач по обработке разных объектов в списках, которые бы представляли экземпляры классов с общим предком.вот смотрите, есть у меня в подписках этот канал, в целом я позитивного мнения об авторе, есть и даже повтор темы Вашего видео из за которого спор начался:
Практически полностью согласен со всеми мыслями в видео. Есть пара мелких даже не возражений, а уточнений (скажем, я считаю, NULL - очень даже полезным указателем, который говорит об ошибке, просто надо иметь ввиду, что функция может вернуть этот нулевой указатель, и, ясное дело, в видео правильно говорится - с ним нельзя работать, как с объектом).
А все остальное, и про неточности, и про порядок разработки, и про геттеры-сеттеры, да и про тот же NULL - все верно.
Респект автору.
Странно, что будучи человеком философски мыслящим и неплохо владеющим абстракцией, я так отчаянно не приемлю любимый профессионалами подход в программировании. При задуманной практичности, ООП оброс сущностями и стал избыточен к своим задачам. "Избыточность" инструментария мешает решению, также как и нехватка. И избыточность эта, несомненно, следствие маркетинга. Подумайте над этим. Минимального ООП достаточно для решения всего в области компьютерных задач. Также, как все можно создать простыми функциями и правильной работой с пямятью. На начальном уровне я сразу принял ООП. Потом заметил, что некоторые сущности не могут оправдать необходимость своего существования и живут своей, отвлеченной от задач жизнью, внутри растущей концепции. Да, они встраиваются в решения, но паразитируют на интеллекте разработчика. Тормозят рабочий процесс, снижая его эффективность. Мешают запутанностью, синтаксисом, правилами... Вот эта необязательность внутри решения мне и не понравилась.
Так что, буду использовать самый минимальный ООП. Тот, что был создан до начала его маркетинга.
Странно, что будучи человеком философски мыслящим и неплохо владеющим абстракцией, я так отчаянно не приемлю любимый профессионалами подход в программировании. При задуманной практичности, ООП оброс сущностями и стал избыточен к своим задачам. "Избыточность" инструментария мешает решению, также как и нехватка. И избыточность эта, несомненно, следствие маркетинга. Подумайте над этим. Минимального ООП достаточно для решения всего в области компьютерных задач. Также, как все можно создать простыми функциями и правильной работой с пямятью. На начальном уровне я сразу принял ООП. Потом заметил, что некоторые сущности не могут оправдать необходимость своего существования и живут своей, отвлеченной от задач жизнью, внутри растущей концепции. Да, они встраиваются в решения, но паразитируют на интеллекте разработчика. Тормозят рабочий процесс, снижая его эффективность. Мешают запутанностью, синтаксисом, правилами... Вот эта необязательность внутри решения мне и не понравилась.
Так что, буду использовать самый минимальный ООП. Тот, что был создан до начала его маркетинга.
Ага. Вот создали Вы класс, ну, например, работы с файлом. Начинаете юзать, и посыпались баги. В одной части кода handle закрыли, а в другой по нему пытаетесь что-то сделать. Подхода два. Первый попробовать всегда помнить где, что сделано, а это даже при одном разработчике слабо получается. Второй - перед действием проверочные операции делать. Ок, следующий баг: в проверочных операциях, которые раскиданы по коду, то тут, то там опечатки, знак не тот, в одном месте поправил, в другом забыл и т.п. И в результате от такой Вами любимой эффективности кода, приходим к банальному и простому, в каждый метод Read/Write и иже с ними включается вызов проверочного метода, да с возможностью его отмены при вызове, котрым практически никогда не будете пользоваться. И тут Вы понимаете, что это хорошо, потому что современное железо позволяет не считать затрачиваемые такты и потребляемую память в 98% решаемых задач.
Ага. Вот создали Вы класс, ну, например, работы с файлом. Начинаете юзать, и посыпались баги. В одной части кода handle закрыли, а в другой по нему пытаетесь что-то сделать. Подхода два. Первый попробовать всегда помнить где, что сделано, а это даже при одном разработчике слабо получается.
У Петера получается.
В том-то и проблема - Петеру удобно использовать громадную таблицу всех переменных, которая всегда доступна из всей программы, и из которой он в любой момент берет то, что ему необходимо. Для титана запоминания - это вполне себе удобно.
В ООП инкапсуляция - это архинужная фича, которая как раз и используется для того, чтобы пользователь в любом месте кода имел доступ лишь только к тем переменным, которые ему нужны, и ни к одной переменной больше. А для Петера это - минус, он и так помнит, где, что и как использовал. Он хочет, чтобы в любой момент времени он мог обратиться к любой переменной любой части программы. Ему не нравится мой подход, когда для того, чтобы получить доступ к переменной - ты сперва должен получить указатель на интерфейс, из интерфейса взять нужную функцию, и только потом она тебе возвратит тебе необходимое значение. И на любом из этих шагов ты можешь встретиться с ограничением доступа. Я считаю это благом, поскольку раз есть ограничение - оно введено не просто так, значит, какие-то важные детали я не учел. А для Петера это помеха, поскольку он все всегда учитывает.
Ага. Вот создали Вы класс, ну, например, работы с файлом. Начинаете юзать, и посыпались баги. В одной части кода handle закрыли, а в другой по нему пытаетесь что-то сделать. Подхода два. Первый попробовать всегда помнить где, что сделано, а это даже при одном разработчике слабо получается. Второй - перед действием проверочные операции делать. Ок, следующий баг: в проверочных операциях, которые раскиданы по коду, то тут, то там опечатки, знак не тот, в одном месте поправил, в другом забыл и т.п. И в результате от такой Вами любимой эффективности кода, приходим к банальному и простому, в каждый метод Read/Write и иже с ними включается вызов проверочного метода, да с возможностью его отмены при вызове, котрым практически никогда не будете пользоваться. И тут Вы понимаете, что это хорошо, потому что современное железо позволяет не считать затрачиваемые такты и потребляемую память в 98% решаемых задач.
Давайте представим обратную ситуацию. Ну, нет у Вас багов. Нет совсем и почти никогда не бывает, потому что ВСЕ помните и ВСЕ учитываете! Станете ли Вы использовать ООП, просто из за "профессионального долга"? Думаю нет. Что же тогда Вас будет волновать? - Только эффективность Ваших кодов. Вы постараетесь убрать весь оверхед, чтобы код работал максимально быстро. Вы также, постараетесь создавать код таким образом, что он быстро развивался.
Когда мне говорят о багах которые возникают тут и там, я понимаю, но когда их связывают с использованием или не использованием ООП,- я не соглашаюсь. Количество багов зависит от знания и понимания своего кода. Лучше всего код знает тот, кто его пишет, а не подключает. У того всегда меньше багов. Как понимаете, ООП пропагандирует переносимость кодов, обратной стороной которой является его слабое понимание другими программистами. Вот источник багов.
Я все пишу сам, и баги в блоках по 2000 строк нахожу без профилировщика и проверочных функций. Просто, я знаю свой код. Лучшее лекарство от багов.))
У Петера получается.
В том-то и проблема - Петеру удобно использовать громадную таблицу всех переменных, которая всегда доступна из всей программы, и из которой он в любой момент берет то, что ему необходимо. Для титана запоминания - это вполне себе удобно.
В ООП инкапсуляция - это архинужная фича, которая как раз и используется для того, чтобы пользователь в любом месте кода имел доступ лишь только к тем переменным, которые ему нужны, и ни к одной переменной больше. А для Петера это - минус, он и так помнит, где, что и как использовал. Он хочет, чтобы в любой момент времени он мог обратиться к любой переменной любой части программы. Ему не нравится мой подход, когда для того, чтобы получить доступ к переменной - ты сперва должен получить указатель на интерфейс, из интерфейса взять нужную функцию, и только потом она тебе возвратит тебе необходимое значение. И на любом из этих шагов ты можешь встретиться с ограничением доступа. Я считаю это благом, поскольку раз есть ограничение - оно введено не просто так, значит, какие-то важные детали я не учел. А для Петера это помеха, поскольку он все всегда учитывает.
Джорж, тут дело не только в памяти. Я создал себе удобную среду разработки, используя родной язык и еще английский. Двуязычный код запоминается НАМНОГО лучше моноязычного. Особенно, когда не зациклен на стандартных словах и называешь переменные как хочешь. Проверено. Просто наплевал на профессионализм в программировании и стал писать как удобно. В результате стал быстро ориентироваться в своем коде и легко его читать, вспоминать и развивать. Дальше ты знаешь...
ЗЫ. Пусть не думают, что я призываю наплевать на профессионализм. Ни в коем случае. Я наплевал из за своего сверх-раздутого Эго. Оказалось, что это бывает не только плохо, но и хорошо. :)
Peter, ваше мышление говорит о том, что вы никогда не работали в команде. Не видели как каждый делает свой кусок огромной задачи, и как в конце присоединяют все вместе.
Вот например без ООП, невозможно было создавать и развивать Windows.
Если нет необходимости, то я тоже постараюсь не применить классы. Но когда я решил превратить мой робот в мультивалютного робота, сразу применил классы, поскольку уже было ясно, что будет без ООП.
Применяя классы, очевидно, что используемые пары объекты одного класса и одновременная работа с ними уже очень легко.
Peter, ваше мышление говорит о том, что вы никогда не работали в команде. Не видели как каждый делает свой кусок огромной задачи, и как в конце присоединяют все вместе.
Вот например без ООП, невозможно было создавать и развивать Windows.
Если нет необходимости, то я тоже постараюсь не применить классы. Но когда я решил превратить мой робот в мультивалютного робота, сразу применил классы, поскольку уже было ясно, что будет без ООП.
Применяя классы, очевидно, что используемые пары объекты одного класса и одновременная работа с ними уже очень легко.
Да, в комманде не работал. Мой подход нужно рассматривать как эксперимент одного разработчика. Я не убеждаю ему следовать. В моем подходе слишком много дерзости.))
Если программист входит в мир форекса, то тут не надо быть профессионалом и знать ООП.
Лучше изучить тонкости рынка и заниматься разработкой прибыльной торговой стратегии. И не важно применяешь ООП или нет. От этого прибыльность советника не пострадает.
Не надо тратить свою энергию впустую.