Вопрос знатокам ООП. - страница 15
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
у него все серьезно!
Сейчас, как раз, собираюсь патентовать свою концепцию. Есть инвесторы. Так что, все серьезно.
вчера вечером почитал топик на сон грядущий.... почему то представил длинный длинный список разработчиков Windows - ну как в Звездных войнах титры!
и в конце списка - крупными буквами Реter Konow !
@Реter Konow а такой спрайт текста можете ? ;)Вы всё помните в том прокте, над которым работаете в данный момент. А как насчёт прошлых кодов? Вспомните ли вы столь же досконально то, что писали год назад? Где там что меняется и т.д. Вот стоит задача чуть доработать или подправить свой старый код.
Все упирается в феноменальную память Петера.
И я согласен, если ты помнишь все переменные, которые используются у тебя во всем проекте, когда и где они модифицируются, легко находишь места ошибочной модификации - то, и в самом деле, теряется смысл в этом самом ООП. Петер, фактически, работает на "ассемблерном уровне". Какие бы вы ООП-навороты и паттерны проектирования не придумывали - а в конечном итоге любые обращения к данным представляют из себя обычные адреса памяти, и в пределах адресного пространства, выделенного процессу все адреса памяти полностью доступны. Ни про какую инкапсуляцию собственно процессор ничего не знает.
Вот, и Петер действует именно так. Было время, когда я сам увлекался ассемблером.
Вопрос лишь в одном - как он умудряется соперничать с процессором в возможности запоминания.
Все упирается в феноменальную память Петера
...
Вопрос лишь в одном - как он умудряется соперничать с процессором в возможности запоминания.
Так а в чём феномальность, если речь идёт об одном и том же проекте, над которым он работает всё время. Естественно у любого программиста будет всё это в голове постоянно.
Ну, значит, я не любой. Я тоже в основном работаю над одним проектом, однако, помню только основную суть. Такие тонкости, как что и из какой процедуры модифицируется - я вижу только в момент непосредственной разработки. И потом, если возвращаюсь к этому участку - довольно много времени трачу на то, чтобы понять, почему здесь именно так, а не иначе. В результате - я сторонник всемерного "обрезания прав", чтобы в идеале в любом месте программы тебе было доступно исключительно лишь то, что ты в этом месте и должен делать.
Вы всё помните в том прокте, над которым работаете в данный момент. А как насчёт прошлых кодов? Вспомните ли вы столь же досконально то, что писали год назад? Где там что меняется и т.д. Вот стоит задача чуть доработать или подправить свой старый код.
Alexey Navoykov:
...
Нет, кунг-фу здесь именно ООП. Куча движений и приемов, среди которых в драке 10% пригодиться. Зато какие красивые стили! И дракона, и обезьяны, и фламинго с жабой... У меня конкретное самбо. Рубанул и получил результат.
Нет, кунг-фу здесь именно ООП. Куча движений и приемов, среди которых в драке 10% пригодиться. Зато какие красивые стили! И дракона, и обезьяны, и фламинго с жабой... У меня конкретное самбо. Рубанул и получил результат.
Это не так.
Про полезность инкапсуляции и ограничении прав - я уже сто раз говорил.
Полезность наследования и полиморфизма хорошо видна там, где идет работа со списками элементов, в которых есть общий виртуальный интерфейс, а вот реализация - существенно отличается.
Вот, простейшая ситуация, с которой я столкнулся буквально на этой неделе - есть список структур, одно из поле которых представляет собой double-значение. Появилась мысль аппроксимировать эти значения с помощью МНК.
Без ООП мне необходимо либо писать полностью процедуры, которые будут создавать соответствующие СЛАУ и их решать. Либо, если у меня уже есть такая программа для работы с массивом значений - написать процедуры, которые бы создавали такой массив, и передавали бы его в библиотечную функцию.
С ООП - я наследуюсь от класса CLSMCore, и перегружаю виртуальные функции, возвращающие значения точек. Сразу же могу получать коэффицинты аппроксимационного полинома.
То есть, при равных условиях (когда у нас есть библиотечная функция или класс) - без ООП я теряю на том, что завожу лишний промежуточный массив. Не говоря уж о том, что необходимо разобраться в том, как именно его заполнять. (Функции получения значений - что с ООП, что без - нужно писать). Самый главный плюс, на мой взгляд, именно в несложности поддержки и модификации. С ООП - разбираться меньше. Причем, изначально, на написание класса CLSMCore - я затратил абсолютно столько же сил, сколько бы и затратил на библиотечную функцию аппроксимации без использования ООП.
Это не так.
Про полезность инкапсуляции и ограничении прав - я уже сто раз говорил.
Полезность наследования и полиморфизма хорошо видна там, где идет работа со списками элементов, в которых есть общий виртуальный интерфейс, а вот реализация - существенно отличается.
Вот, простейшая ситуация, с которой я столкнулся буквально на этой неделе - есть список структур, одно из поле которых представляет собой double-значение. Появилась мысль аппроксимировать эти значения с помощью МНК.
Без ООП мне необходимо либо писать полностью процедуры, которые будут создавать соответствующие СЛАУ и их решать. Либо, если у меня уже есть такая программа для работы с массивом значений - написать процедуры, которые бы создавали такой массив, и передавали бы его в библиотечную функцию.
С ООП - я наследуюсь от класса CLSMCore, и перегружаю виртуальные функции, возвращающие значения точек. Сразу же могу получать коэффицинты аппроксимационного полинома.
То есть, при равных условиях (когда у нас есть библиотечная функция или класс) - без ООП я теряю на том, что завожу лишний промежуточный массив. Не говоря уж о том, что необходимо разобраться в том, как именно его заполнять. (Функции получения значений - что с ООП, что без - нужно писать). Самый главный плюс, на мой взгляд, именно в несложности поддержки и модификации. С ООП - разбираться меньше. Причем, изначально, на написание класса CLSMCore - я затратил абсолютно столько же сил, сколько бы и затратил на библиотечную функцию аппроксимации без использования ООП.
Я например, никогда не понимал, зачем нужна перегрузка функций. Это ведь нелепость какая то... Делаем функцию без параметров, внутри пишем все вычисления перегруженных функций, делаем переменные глобальными и имеем доступ к результатам из любой другой функции. Ну, красота ведь!
Но нет! Разделим мы все вычисления на функции с одинаковым названием, но разными параметрами. А входных параметров каждый функции кучу сделаем. Нет. Этого мало. Давайте еще названия параметров нечитабельными сделаем. И чтобы в перемешку с ними, массивы всякие передавались. И наделаем с десяток таких функций, чтобы дольше думать над каждой. И чтобы доступ к ним зашифрован был. Чтобы синтаксис наворотистее красовался. Вот это профессионализм!
Извини, Джорж. Накипело.
ЗЫ. Просто один глобальный массив для результатов 10 перегруженных функций и одна функция без параметров, которая делает их работу. Чем хуже? В 10 раз меньше синтаксиса.
Я например, никогда не понимал, зачем нужна перегрузка функций. Это ведь нелепость какая то... Делаем функцию без параметров, внутри пишем все вычисления перегруженных функций, делаем переменные глобальными и имеем доступ к результатам из любой другой функции. Ну, красота ведь!
Но нет! Разделим мы все вычисления на функции с одинаковым названием, но разными параметрами. А входных параметров каждый функции кучу сделаем. Нет. Этого мало. Давайте еще названия параметров нечитабельными сделаем. И чтобы в перемешку с ними, массивы всякие передавались. И наделаем с десяток таких функций, чтобы дольше думать над каждой. И чтобы доступ к ним зашифрован был. Чтобы синтаксис наворотистее красовался. Вот это профессионализм!
Извини, Джорж. Накипело.
ЗЫ. Просто один глобальный массив для результатов 10 перегруженных функций и одна функция без параметров, которая делает их работу. Чем хуже? В 10 раз меньше синтаксиса.
Вот-вот, про эту функцию поподробнее. У тебя она одна имеет чудовищных размеров switch, который выбирает одну из десятка нужных функций. В таком переключателе - очень легко ошибиться, случайно написав код, относящийся к одной из ветви не там.
С перегрузкой - все куда проще. У нас есть десять разных наследников, и каждый момент времени времени мы работаем с ОДНИМ классом, и в нем ОДНА перегружаемая функция. Мы не можем случайно написать ее в другом классе, поскольку для этого надо открывать совсем другой файл.
Плюс - само разбирательство в этом самом огромном switch'e - на мой взгляд, куда напряжнее, чем открытие одного нужного класса, и потом разбирательство только с одной функций.
На самом деле, в ассемблерном коде вся эта пергрузка в любом случае сводится к такому же swich'у, в зависимости от указателя this. Но в случае ООП - все это скрыто от программиста, и не мешает ему в работе. Без ООП - тебе придется с ним иметь дело.
Грубо говоря, когда ты идешь - ты ведь, в конечном итоге, посылаешь на свои мышцы в определенной последовательности сигналы, которые их двигают. Однако, на уровне сознания - ты просто помнишь, какое движение надо совершить. Вот, ООП - это именно такая "память, какое движение надо совершить". Ты же "не понимаешь, зачем помнить движение, если у нас есть куча мускулов, и нервов, подведенных к ним". Ну... я уже много раз говорил, для титанов запоминания, и правда, вполне достаточно помнить какие мышцы надо напрягать в какой последовательности, чтобы идти. Смысла помнить еще и это движение целиком - ну никакого. Для остальных же, кто не может так много помнить - куда разумнее помнить именно все движение целиком, а что там с мышцами, в какой последовательности они напрягаются и насколько - это разумнее скрыть от сознания.
Реter Konow:
Я например, никогда не понимал, зачем нужна перегрузка функций. Это ведь нелепость какая то... Делаем функцию без параметров, внутри пишем все вычисления перегруженных функций, делаем переменные глобальными и имеем доступ к результатам из любой другой функции. Ну, красота ведь!
Жесть, занимаетесь каким-то велосипедостроительством без должного изучения общепринятого подхода. Пётр, найдите каку-нибудь хорошую книгу, возможно Страуструпа, в какой-то книге он писал текстовый редактор, на реальной задаче чего-нибудь подчерпнёте, я содержание уже не помню, но вряд ли он плохому научит.