Вопрос знатокам ООП. - страница 15

 
Alexey Navoykov:
Поэтому противопоставлять ваше "кунг-фу" именно ООП не вижу смысла.

у него все серьезно!

Реter Konow:
Сейчас, как раз, собираюсь патентовать свою концепцию. Есть инвесторы. Так что, все серьезно.

вчера вечером почитал топик на сон грядущий.... почему то представил длинный длинный список разработчиков Windows - ну как в Звездных войнах титры! 

и в конце списка - крупными буквами Реter Konow !


@Реter Konow а такой спрайт текста можете ?  ;)
 
Alexey Navoykov:
Вы всё помните в том прокте, над которым работаете в данный момент. А как насчёт прошлых кодов? Вспомните ли вы столь же досконально то, что писали год назад? Где там что меняется и т.д.  Вот стоит задача чуть доработать или подправить свой старый код.

Да и всё это не имеет отношения к ООП. Если ваш код построен на публичном доступе к глобальным переменных, то это не допустимо ни в одной парадигме, ни в процедурной, ни в ООП, ни уж тем более в функциональной.  Поэтому противопоставлять ваше "кунг-фу" именно ООП не вижу смысла.

Все упирается в феноменальную память Петера.

И я согласен, если ты помнишь все переменные, которые используются у тебя во всем проекте, когда и где они модифицируются, легко находишь места ошибочной модификации - то, и в самом деле, теряется смысл в этом самом ООП.  Петер, фактически, работает на "ассемблерном уровне". Какие бы вы ООП-навороты и паттерны проектирования не придумывали - а в конечном итоге любые обращения к данным представляют из себя обычные адреса памяти, и в пределах адресного пространства, выделенного процессу все адреса памяти полностью доступны. Ни про какую инкапсуляцию собственно процессор ничего не знает.

Вот, и Петер действует именно так.  Было время, когда я сам увлекался ассемблером.

Вопрос лишь в одном - как он умудряется соперничать с процессором в возможности запоминания.

 
Georgiy Merts:

Все упирается в феноменальную память Петера

...

Вопрос лишь в одном - как он умудряется соперничать с процессором в возможности запоминания.

Так а в чём феномальность, если речь идёт об одном и том же проекте, над которым он работает всё время. Естественно у любого программиста будет всё это в голове постоянно.
Вот если бы он чётко мог вспомнить этот код спустя какое-то время, то другой разговор.
 
Alexey Navoykov:
Так а в чём феномальность, если речь идёт об одном и том же проекте, над которым он работает всё время. Естественно у любого программиста будет всё это в голове постоянно.
Вот если бы он чётко мог вспомнить этот код спустя какое-то время, то другой разговор.

Ну, значит, я не любой. Я тоже в основном работаю над одним проектом, однако, помню только основную суть. Такие тонкости, как что и из какой процедуры модифицируется - я вижу только в момент непосредственной разработки. И потом, если возвращаюсь к этому участку - довольно много времени трачу на то, чтобы понять, почему здесь именно так, а не иначе. В результате - я сторонник всемерного "обрезания прав", чтобы в идеале в любом месте программы тебе было доступно исключительно лишь то, что ты в этом месте и должен делать.

 
Alexey Navoykov:
Вы всё помните в том прокте, над которым работаете в данный момент. А как насчёт прошлых кодов? Вспомните ли вы столь же досконально то, что писали год назад? Где там что меняется и т.д.  Вот стоит задача чуть доработать или подправить свой старый код.

Да и всё это не имеет отношения к ООП. Если ваш код построен на публичном доступе к глобальным переменных, то это не допустимо ни в одной парадигме, ни в процедурной, ни в ООП, ни уж тем более в функциональной.  Поэтому противопоставлять ваше "кунг-фу" именно ООП не вижу смысла.
Да, вспоминаю и разбираюсь в старых кодах очень быстро. Проект настолько большой, что некоторые части не меняются месяцами и даже годами, а когда приходит время что то улучшить (например древ. список), я за короткий срок разбираюсь во всех деталях, освежая в памяти как это работает, без комментариев, коих почти нет в исходниках. Вспоминаю глядя на голый код. И мне почему то кажется, что каждый так может.
 

Alexey Navoykov:

...

Да и всё это не имеет отношения к ООП. Если ваш код построен на публичном доступе к глобальным переменных, то это не допустимо ни в одной парадигме, ни в процедурной, ни в ООП, ни уж тем более в функциональной.  Поэтому противопоставлять ваше "кунг-фу" именно ООП не вижу смысла.

Нет, кунг-фу здесь именно ООП. Куча движений и приемов, среди которых в драке 10% пригодиться. Зато какие красивые стили! И дракона, и обезьяны, и фламинго с жабой... У меня конкретное самбо. Рубанул и получил результат.

 
Реter Konow:

Нет, кунг-фу здесь именно ООП. Куча движений и приемов, среди которых в драке 10% пригодиться. Зато какие красивые стили! И дракона, и обезьяны, и фламинго с жабой... У меня конкретное самбо. Рубанул и получил результат.

Это не так.

Про полезность инкапсуляции и ограничении прав - я уже сто раз говорил.

Полезность наследования и полиморфизма хорошо видна там, где идет работа со списками элементов, в которых есть общий виртуальный интерфейс, а вот реализация - существенно отличается.

Вот, простейшая ситуация, с которой я столкнулся буквально на этой неделе - есть список структур, одно из поле которых представляет собой double-значение. Появилась мысль аппроксимировать эти значения с помощью МНК.

Без ООП мне необходимо либо писать полностью процедуры, которые будут создавать соответствующие СЛАУ и их решать. Либо, если у меня уже есть такая программа для работы с массивом значений - написать процедуры, которые бы создавали такой массив, и передавали бы его в библиотечную функцию.

С ООП - я наследуюсь от класса CLSMCore, и перегружаю виртуальные функции, возвращающие значения точек. Сразу же могу получать коэффицинты аппроксимационного полинома.

То есть, при равных условиях (когда у нас есть библиотечная функция или класс) - без ООП я теряю на том, что завожу лишний промежуточный массив. Не говоря уж о том, что необходимо разобраться в том, как именно его заполнять. (Функции получения значений - что с ООП, что без - нужно писать). Самый главный плюс, на мой взгляд, именно в несложности поддержки и модификации. С ООП - разбираться меньше. Причем, изначально, на написание класса CLSMCore - я затратил абсолютно столько же сил, сколько бы и затратил на библиотечную функцию аппроксимации без использования ООП.

 
Georgiy Merts:

Это не так.

Про полезность инкапсуляции и ограничении прав - я уже сто раз говорил.

Полезность наследования и полиморфизма хорошо видна там, где идет работа со списками элементов, в которых есть общий виртуальный интерфейс, а вот реализация - существенно отличается.

Вот, простейшая ситуация, с которой я столкнулся буквально на этой неделе - есть список структур, одно из поле которых представляет собой double-значение. Появилась мысль аппроксимировать эти значения с помощью МНК.

Без ООП мне необходимо либо писать полностью процедуры, которые будут создавать соответствующие СЛАУ и их решать. Либо, если у меня уже есть такая программа для работы с массивом значений - написать процедуры, которые бы создавали такой массив, и передавали бы его в библиотечную функцию.

С ООП - я наследуюсь от класса CLSMCore, и перегружаю виртуальные функции, возвращающие значения точек. Сразу же могу получать коэффицинты аппроксимационного полинома.

То есть, при равных условиях (когда у нас есть библиотечная функция или класс) - без ООП я теряю на том, что завожу лишний промежуточный массив. Не говоря уж о том, что необходимо разобраться в том, как именно его заполнять. (Функции получения значений - что с ООП, что без - нужно писать). Самый главный плюс, на мой взгляд, именно в несложности поддержки и модификации. С ООП - разбираться меньше. Причем, изначально, на написание класса CLSMCore - я затратил абсолютно столько же сил, сколько бы и затратил на библиотечную функцию аппроксимации без использования ООП.

Я например, никогда не понимал, зачем нужна перегрузка функций. Это ведь нелепость какая то... Делаем функцию без параметров, внутри пишем все вычисления перегруженных функций, делаем переменные глобальными и имеем доступ к результатам из любой другой функции. Ну, красота ведь!

Но нет! Разделим мы все вычисления на функции с одинаковым названием, но разными параметрами. А входных параметров каждый функции кучу сделаем. Нет. Этого мало. Давайте еще названия параметров нечитабельными сделаем. И чтобы в перемешку с ними, массивы всякие передавались. И наделаем с десяток таких функций, чтобы дольше думать над каждой. И чтобы доступ к ним зашифрован был. Чтобы синтаксис наворотистее красовался. Вот это профессионализм!

Извини, Джорж. Накипело.


ЗЫ. Просто один глобальный массив для результатов 10 перегруженных функций и одна функция без параметров, которая делает их работу. Чем хуже? В 10 раз меньше синтаксиса.

 
Реter Konow:

Я например, никогда не понимал, зачем нужна перегрузка функций. Это ведь нелепость какая то... Делаем функцию без параметров, внутри пишем все вычисления перегруженных функций, делаем переменные глобальными и имеем доступ к результатам из любой другой функции. Ну, красота ведь!

Но нет! Разделим мы все вычисления на функции с одинаковым названием, но разными параметрами. А входных параметров каждый функции кучу сделаем. Нет. Этого мало. Давайте еще названия параметров нечитабельными сделаем. И чтобы в перемешку с ними, массивы всякие передавались. И наделаем с десяток таких функций, чтобы дольше думать над каждой. И чтобы доступ к ним зашифрован был. Чтобы синтаксис наворотистее красовался. Вот это профессионализм!

Извини, Джорж. Накипело.


ЗЫ. Просто один глобальный массив для результатов 10 перегруженных функций и одна функция без параметров, которая делает их работу. Чем хуже? В 10 раз меньше синтаксиса.

Вот-вот, про эту функцию поподробнее. У тебя она одна имеет чудовищных размеров switch, который выбирает одну из десятка нужных функций. В таком переключателе - очень легко ошибиться, случайно написав код, относящийся к одной из ветви не там.

С перегрузкой - все куда проще. У нас есть десять разных наследников, и каждый момент времени времени мы работаем  с ОДНИМ классом, и в нем ОДНА перегружаемая функция. Мы не можем случайно написать ее в другом классе, поскольку для этого надо открывать совсем другой файл.

Плюс - само разбирательство в этом самом огромном switch'e - на мой взгляд, куда напряжнее, чем открытие одного нужного класса, и потом разбирательство только с одной функций.

На самом деле, в ассемблерном коде вся эта пергрузка в любом случае сводится к такому же swich'у, в зависимости от указателя this. Но в случае ООП - все это скрыто от программиста, и не мешает ему в работе. Без ООП - тебе придется с ним иметь дело.

Грубо говоря, когда ты идешь - ты ведь, в конечном итоге, посылаешь на свои мышцы в определенной последовательности сигналы, которые их двигают. Однако, на уровне сознания - ты просто помнишь, какое движение надо совершить. Вот, ООП - это именно такая "память, какое движение надо совершить".  Ты же "не понимаешь, зачем помнить движение, если у нас есть куча мускулов, и нервов, подведенных к ним".  Ну... я уже много раз говорил, для титанов запоминания, и правда, вполне достаточно помнить какие мышцы надо напрягать в какой последовательности, чтобы идти. Смысла помнить еще и это движение целиком - ну никакого. Для остальных же, кто не может так много помнить - куда разумнее помнить именно все движение целиком, а что там с мышцами, в какой последовательности они напрягаются и насколько - это разумнее скрыть от сознания.

 

Реter Konow:

Я например, никогда не понимал, зачем нужна перегрузка функций. Это ведь нелепость какая то... Делаем функцию без параметров, внутри пишем все вычисления перегруженных функций, делаем переменные глобальными и имеем доступ к результатам из любой другой функции. Ну, красота ведь!


Жесть, занимаетесь каким-то велосипедостроительством без должного изучения общепринятого подхода. Пётр, найдите каку-нибудь хорошую книгу, возможно Страуструпа, в какой-то книге он писал текстовый редактор, на реальной задаче чего-нибудь подчерпнёте, я содержание уже не помню, но вряд ли он плохому научит.