Судя, что у меня сейчас цифра 3 в репутации, люди все же тянутся к ООП. Пока у меня отпуск, а завершается он на след. неделе в Пн. (, я хотел бы сделать то, что людям может помочь. Сейчас возникли мысли по поводу написания мануала касательно ООП, но нужен ли он? Может проще каждый раз на нужную книгу посылать?

Какие требования я выставляю к мануалу:
1. Практическая ценность
2. Структурированность, чтобы человек затратил минимум времени на прочтение мануала
3. Нагладность на жизненных ситуациях, тут могу только касательно АСУТП систем :(

Что понадобится, мое имхо?
1. Мне может быть понятным, а вот какому нить Пете нет. Нужны будут люди, которые будут вычитывать и отлавливать ошибки, как речевые, так и в формулировке мысли ;)
2. Нужны будут рисунки поясняющие суть
3. Нужны будут программеры, которые могут привести ситуации из других отличных от АСУТП областей

Вобщем, нужна ли эта работа и кто готов помочь?

Если есть желание почему и нет навернека обезательно пригодится  

ivan219, Т.е. вы проголосовали нет? Возможно у меня зрение ухудшилось ?! ;)

конечно нужен. любой мануал нужен. ведь кому то точно пригодится...
особенно если он будет содержать все то что ты предложил.

Мне наверное уже поздно такое читать  Но всё-равно проголосовал "Да", если получится подробный и понятный, то на него и будем отсылать  

Эээээ. Не вижу связи.
У меня сейчас 353. Какой мне вывод из этого сделать?

Если создаётся реализация сущности, аналоги которой имеются, то начать следует с вопроса: "Что может дать, чего не могут дать другие".
Взвесив плюсы и минусы, придёт решение.

Я когда-то объяснял концепции ООП на зелёных бегемотах.
Работает очень доходчиво.
Все принципы объясняются на ура. Особенно наследование.
Да и зелёный бегемот доходчивее врезается в память, чем реальные вещи.
Мои ученики уже через 2 дня кодили на дельфях на базовом уровне.
Спустя годы они вспоминают зелёных бегемотов 

Цифра 3 характеризующая мою репутацию подналась только, потому что я написал свои мысле в теме "Объектно-ориентированный анализ и проектирование", т.е говорит о том что люди нуждаются в ООП.Они его применяют, причем проголосавили люди не с  количеством постов а выше 200. Возможно, мои слова помогли не только новичкам. Вот и подумалось, о мануале.


Snowy, Чем вредны бегемоты? Они вредны, как никрути. Я когда-то читал книгу "Освой самостоятельно С++ за 21 день." Дж. Либерти. Это автор сиронизировал дав такое название ))). Книга сильная, с ней разве что талмуды Таненбаума выигрывают по изложению сложных вещей. Так вот там как раз таки было пояснено на "Бегемотах"(ну там были млекопитающие, если быть точнее), т.е. простейшая ситуация и что в итоге? Я научился писать слово class. Но! Понимание пришло только потом!!!
В реальной ситуации, в реальной задаче. Когда я начал решать задачи, которые требовали изобретение велосипеда вновь и вновь. Вот тогда то я и понял, что программист, современный программист это прежде всего практик! Мы все сидим не дома и праздно пишем очередную бегемото-стрелялку, а довольно серьезные проекты. Всем нам надо укладываться в сроки, поддерживать код! Искать баги! У нас столько задач, что хоть убавляй.
Так вот сейчас, я все чаще и чаще задумываюсь, как организовать себя, как научиться писать так, чтобы код писать только один раз или минимально править, при этом так чтобы вносить меньше багов.

Бегемоты вредят, т.к. это не развивает инженера, это всего лишь показывает что это как-то можно использовать. Беда современных программистов, в том что мы они и я в том числе отучились думать в нужном русле. В русле креатива. Все больше и больше слышим: "Я вот кинул компонент на форму и что дальше то?", не надоело?

Это сугубо мое личное мнение.

Это сообщение отредактировал(а) EvilsInterrupt - 7.8.2007, 00:08

Бегемоты помогают объяснить концепции.
Согласно психологии, они лучше врезаются в память.
Разумеется, дальше должны быть практические примеры.
Но сам концепт воспринимается на бегемотах лучше.
Да и общение с живым человеком, а не с куском бумаги, эффективнее.

И что? Это персоналии.
Я учился ООП на учебнике 1986-го года.
Там ООП объяснялось на геометрических фигурах.
Лучше? Хуже? Я скажу одно - понимание ООП сразу не придёт.
И на треугольниках и на бегемотах требуется время на осознание.
С точки зрения психологии, бегемоты лучше.
Но, если человек не знаком с ООП, то с первого раза он всё равно не поймёт.
Мои ученики были структурными програмерами. Им потребовалось 2 дня на ломку сознания.
Что касается девственного мозга, то тут вообще никакие прогнозы нереальны.
Логика тут бессильна. А психология указывает в сторону зелёных бегемотов.
Именно зелёных бегемотов, а не млекопитающих.
Ибо абсурд запоминается сильнее.
Страус, прячущий голову в песок не вызывает такой памяти и логики, как трёхногий страус с квадратными синими ушами, трескающий шаурму на красной площади.
Программерский подход здесь одинаков.
А вот психология работает по разному.

Лично мне надоело. Но я сильно соневаюсь, что люди привыкшие только кидать компоненты и не жалеющие вникать в теорию станen читать статьи. Материала о ООП в сети полным полно, самоучителей однако многое из этого игнорируется. Т.е. те уто хотят учиться - находят материал и учат, а тех кто не хочет - силком не заставишь. 


Snowy, при всём моём уважении, хочу спросить, а где же эта статья про бегемотов?   Ссылку пожалуйста! 

Я проголосовал Да вы като неправильно расценили мой топик  

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

Какая ссылка? Я ж говорю - я так объяснял на пальцах основные принципы ООП.
Сам объяснял. Живым людям. Лично. Без статей.

EvilsInterrupt, я думаю, что перед тем как проводить опрос, нужно было сделать следующее:

1) составить перечень доступной документации по ООП

2) прикинуть структуру и содержание того, что хочешь предложить ты

3) проведёный анализ представить на суд участников форума

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

Если материалы, которые ты предлагаешь, будут носить качественно новый и более доступный подход, то я категорически за.

P.S. Что может быть доступнее бегемотиков!

former, Читал Гради Буча? Я да. Это на мой взгляд самая лучшая книга про ООП! Но не смотря на то что автор действительно старался прояснить понимаются только концеции. Я же хочу совместно с теми кто согласится мне помогать написать руководство о том, как применять эти дела на практике. Почитайте еще раз мой первый пост!

Это сообщение отредактировал(а) EvilsInterrupt - 7.8.2007, 09:41

EvilsInterrupt, а я думаю так: 
Если ты считаешь, что сможешь написать такую статью и хочешь её написать - то пиши и никого не спрашивай. А желающие покритиковать всегда найдутся. Как и желающие похвалить. Психология, блин =)

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

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'ы картинками с диска, добавляет системное меню к форме и что-то там ещё делает... =)

Проверь 

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

1Andrey1, если нужно напишем, но вот вопрос чем не устраивают текущие книги? Что в них не так, ведь если написать еще один такой же то какой смысл?

Alexeis,  хочеться реальное объектное небольшое приложение на дельфи. С его разбором. 
С самими принципами, думаю, понятно, либо можно почитать у других авторов 

1Andrey1, 
статья могла бы появиться, но переехав в Москву я начал общаться с большим количеством толковых программистов. Я понял, что то что я знаю про ОО анализ\проектирование\программирование это чересчур малый запас знаний. Сейчас собираю те теоретические и практические навыки, которые действительно помогают в раде случаев. Мне бы очень не хотелось написать статью, для того чтобы просто написать : "вот мол я! Крут, статью написал, я шарю".

Для тех кто желает, чтобы она не просто быстрее вышла, но и содержала анализ задач и также пути,как пришли к тому или иному решению(создание класса, метода, иерархии классов и т.д.) то буду рад, если такие люди опишут задачи, с которыми они сталкиваются довольно часто, но решают их так как могут, а хотят решить более элегантно. Т.е. те практические задачи, над которыми действительно стоит подумать и разобрав и решив которые, можно получить навык и описать этот навык для других.

Сорри, что сумбурно, но старался выразить мысль ;)

Ооо... ООП.. выкладывай! ООП это хорошо... я связывался с обьектно ориентированным программированием в PHP и если в дельфи ООП дает такие-же возможности, то это круто=)

Без комментариев.



Полностью согласен с Alexeis. Еще неизвестно получится ли написать лучше чем уже имеющиеся.

THandle,
Есть Книга Рихтера, не спорю, талмуд офигенный!!! В нем очень много всего, очень правильные мысли. Но как много программистов этот талмуд прочли? Однако те кто прочитали статью-перевод от Петровича в соседней ветке этого форума, они стали лучше программить многотрэдные приложения! Да, эта статья хуже чем Рихтер, хотя очень сомневаюсь, но то что в ней в более сжатом виде довольно много толковых мыслей и решений - это я скажу, очень хороший выход, когда читать классиков времени нет, а написать и написать прилично надо!

Вот потому, мне бы хотелось, чтобы такая статья по ОО появилась, это не цель лучше написать, это цель преподнести в сжатом и доступном виде, что описано в трудах классиков!

Что сейчас и чего хочу ?:
Начал писать, но сталкиваюсь с примерами только своего программерского опыта, а у меня опыт связан с предметной областью АСУТП. Очень бы хотелось задачи из разных предметных областей, потому многих прошу выразить задачи, которые действительно стоит про анализировать.
Я бы написал,кто-то увидел подумал и покритиковал, я бы поправил, кто-то еще бы чтото увидел дал замечания и т.д. в итоге можно получить довольно серьезный мануал, основанный на практическом опыте и трудностях, которые возникали не у одного программиста.