Создал Аналогичную тему, чтобы узнать мнение противников: почему же они ненавидят ООП? ))

EvilsInterrupt, согласен одна из лучших книг. Слушай, а может провести опрос в разделе "Для новичков" и узнать, какие разделы им даются тяжело и что остаётся непонятным?





Bose, Я не сколько не пытался критиковать предложение EvilsInterrupt-а. Проголосовал за. Согласись, что прежде чем усовершенствовать что-то или делать более доступным, то необходимо провести оценку созданного и выявить слабые места.

Вот вам пример. Многие в университетах на технических специальностях изучают теорию автоматического управления(ТАУ или ТАР). На протяжении нескольких десятков лет по этой дисциплине издают литературу. Как только не пытаются донести авторы до своих читателей основы. И постепенно это начинает переростать в извращённую форму. А бестселлером по-прежнему остаётся Бесекерский (60-е года прошлого века).

Отправная точка - сам ученик. Повторюсь ещё раз, надо у них и спросить, что им не понятно. Тут не психология, а педагогика.

Не соглашусь. Я не могу согласится с тем, что это обязательное условие. Если бы ты, former, писал такую статью, то ты бы наверняка именно так и сделал. Но предъявлять такие же требования к другим желающим что-то написать - по-моему уже крайность. 

Сколько хороших идей появлялось на форуме, и сколько из них угасали даже не дойдя до стадии реализации. Зато с каким воодушевлением все давали советы на тему того как это надо делать.   


А педагогику - давайте оставим педагогам. К слову, я в жизни видел всего несколько действительно талантливых педагогов.



Мне кажется, что многие новички просто не понимают зачем им учить теорию ООП, если для того чтобы "сделать программу" в Дельфи достаточно набросать компонентов на форму и установить нужные свойства.  

Bose, это не я предъявляю требования. Это классический подход. А по-поводу моих статей, то у меня их больше 100 в отечественных и иностранных изданиях и на очереди книга, хоть и не посвященных программированию. Так что опыту хватает.



Это значит только одно, что люди не умеют отстаивать свои идеи и легко ведутся на чужую критику.





Видеть талантливых педагогов одно, а учиться у них - другое А психологию - психологам.  

И последнее. 

Bose, на протяжении всего обсуждении ты постоянно пытаешься подловить меня на критике и предъявлении требований. Выставляешь меня противником подготовки этого материала. Это ведь не так. Я с самого начала поддержал и поддерживаю желание 
EvilsInterrupt-а. Так что давай прекратим эту перепалку.

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


Впрочем, по-моему мы углубились в оффтоп   


Да, так и было. Мне так показалось


С удовольствием. 

В общем, мне нужно от тех кто, кому то хоть раз помог ООП, описание того чем помог.
В таком виде:

0. Пояснение существовшей ситуации
1. К каким пришли выводам и почему
2. Как подошли к реализации
3. Краткие шаги реализации(написание такого то класса, его задача такая то)
4. что в итоге получили
5. Выигрышь
6. Недостатки
7. Итог

Желательно в каком нить текстовике, а не в вордовском или еще каком нить чудо-формате. Если не сложно,
то напишите ваши мыла мне в приват.

На основании ваших, я буду четко знать. Как действовали разные люди в разных ситуаций, отсюдова будет
плюс в изложении, что ученик будет видеть разносторонний подход

  ООП это невероятно удобная вещь, но рассказывать об основах нет смысла, гораздо полезнее было бы почитать о глубинах ООП. О том как это работает изнутри в Delphi. VCL - это вообще кладезь знаний, в нем можно найти столько интересных с практической точки зрения вещей! Почему оно работает так, а не иначе. Незнание этих механизмов как правило приводят к тупиковым ситуациям при проектировании систем типа - "потоки - VCL" или "Dll и VCL". 100 раз уже сказано на форуме, но и в 101 раз наступят на те же грабли. 
  Также интересная тема - потоки данных и т.е. наследники TStream. Многие до сих пор читают из файла при помощи AssignFile и мучаются с массивами. Объектная обработка данных - это целый шаг вперед.
  Объектная обработка ошибок и классы-исключения. Практические примеры.
  Сериализация объектов.

Например, о механизме вызова виртуальных функций, VMT и VPTR.


По сериализации объектов есть неплохая статья в RSDN. Советую ознакомиться.

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

Гради Буча читал но далеко не все понял слишком много воды, да и потом С++ я не особо понимаю, нам кроме основ на уровне A = B + C ничего не давали. А вот почитать про зеленых бегемотиков и с примерами на Делфи думаю было бы интересно. Статью в студию!  

Это сообщение отредактировал(а) SkillHunter - 9.8.2007, 12:29

  Которыми кстати этот класс НЕ пользуется, и не может использовать, иначе имел бы те же ограничения что и AssignFile и т.д. TFileStream использует средства ОС под которой работает. 

Это сообщение отредактировал(а) Alexeis - 9.8.2007, 12:58

Поддерживаю Alexeis. Нет смысла описывать основы, нужно копать вглубь.
Мне бы например были очень интересны конкретные тонкости реализаии на Delphi паттернов проектирования.

Ch0bits, Полностью не согласен с тобой! Потому что ты даже не прочитал, о чем речь! Тема не про основы дорогой!!! А про практическую сторону применения ООП! Покажи мне действительно знающих и эффектино применяющих ООП? Таких я тебе скажу
единицы!

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

Еще раз подчеркну: Я практик, хочу иметь знания позволяющие применять мне теорию на практике
Точнее скажет В.Цой"Что будет стоить тысячи слов? Когда важна будет крепость руки." (с) гр. Кино

Можно сколь угодно много читать умных слов, но конечная цель прочтения этих слов - Практика!

По делу:
Пока найдет человек, который готов написать о том как он применя ООП при разработке компьютерных игр и чем ему помог ООП!

О кстати о примерах. Я наконец вспонмил один случай, который можно коротко описать. Случай довольно банальный, но всё же:

Текущий проект мне достался в уже "готовом" виде. Там было около 40 форм(все наследовались от Tform), и нужно было вылизать доставшиеся в наследство глюки  и добавить кое-какую функциональность. 
В частности, нужно было убедится, что все DBLookupComboBox'ы в ракрывающемся списке показывают не меньше 8 записей, а также гарантировать что у всех у них включены определённые свойства. 

Вручную проверив форм 5 я понял что это не дело, и подумал, а не сделать ли так, чтобы эти свойства проставлялись автоматом при создании формы? Подумав ещё немного я постучал в свой программерский бубен чтобы заручиться благоволением духа ООП. И дух ООП посоветовал воспользоваться наследованием. 
Я создал юнит MyBaseForm.pas и в нём новый класс TmyBaseForm унаследованный от Tform


Дальше я последовательно обошёл все формы и в секции interface заменил строку вида 
 на 

и добавил в uses секцию юнит MyBaseForm.

Теперь все формы наследуются не от стандартной Tform а от моей формы TMyBaseForm и для того, чтобы поменять какое-то поведение во всех формах, мне достаточно было написать нужный код в TMyBaseForm.

После замены я проверил, нормально ли собирается проект. Вроде всё нормально, ошибок нет.   


Теперь возник вопрос, а где же писать код для автоматического выставления нужных свойств у DBLookupComboBox'ов? 

Для выставления свойств, я добавил метод PrepareLookupComboBoxes который проходит по всем DbLookupComboBox'ам формы и выставляет им нужные свойства. Я объявил этот метод в секции protected и добавил директиву virtual, чтобы оставить себе возможность изменить это поведение в конкретных формах.

Чтобы убедится что этот метод работает я добавил туда код заменяющий цвет комбо-бокса на ядовито-зелёный. 


Дальше у меня возник вопрос, а когда лучше всего вызывать этот код? 

Свойства, которые мне нужно было установить лучше всего устанавливать после того как будут открыты присоединённые к ним Datasetы. В большинстве форм, Datasetы открываются либо в событии формы OnCreate либо в OnShow. Значит, идеальный вариант - это вызывать PrepareLookupComboBoxes после того как сработает событие OnShow. 

Исследовав исходные код класса Tform я решил переопределить метод DoShow, который и отвечает за вызов события OnShow.




В дальнейшем в класс TmyBaseForm было добавлено ещё много разных процедур, и он разросся настолько что пришлось вставлять ещё одного наследника, но это уже совсем другая сказка   

Этод метод работает, но он не идеален, ибо наследует только кодовую часть, и игнорирует ресурсы.

Сорри, если где-то в тексте натупил... Я это не специально.   

Bose
А нельзя было просто переопределить класс TDBLookupComboBox-а в отдельном модуле и прописать модуль первым?

Не знаю, я не пробовал. Но не думаю, что это повлияет на ComboBox'ы у куоторых свойство DropDownRows было изменено в design-time. Впрочем, спасибо за идею. 

Yanis, проблема предыдущего поста была придумана. На деле задача была более обширна. Сейчас, вышеупомянутый TmyBaseForm помимо установки свойств отвечает за загрузку и сохранение положения сплиттеров, ширин столбцов в DBGrid'ах, положение Toolbarов, заполняет ImageList'ы картинками с диска, добавляет системное меню к форме и что-то там ещё делает... =)