Re[2]: Путь к ООП
От: denisko http://sdeniskos.blogspot.com/
Дата: 22.09.09 10:55
Оценка: 16 (4) +7 :))) :))) :)))
Здравствуйте, vl690001x, Вы писали:

V>Вообще, изучить ООП нелегко, это большая работа, но легких путей не бывает. НЕ БЫВАЕТ, советую еще раз перечитать эти слова.

Советую перестать дрочить на ООП, ПЕРЕСТАТЬ ДРОЧИТЬ, запомните эти слова.
<Подпись удалена модератором>
Re[2]: ИМХО, главное ограничение ООП
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 24.09.09 11:10
Оценка: 47 (7) +1 -4
Здравствуйте, craft-brother, Вы писали:

CB>Здесь и зарыто главное ограничение ООП, которое делает наши программы сложнее, чем они могли бы быть. ... "The Liskov Substitution Principle"


Принцип Лискова — вообще бомба. Он говорит нам о том, что:
1. В программировании хвост, виляющий собакой — обычная ситуация. Здесь хвост — это дизайн подсистемы/сервиса, а собака — это дизайн системы.
2. Пока ты в совершенстве не освоил телепатию и не научился путешествовать туда-сюда по времени, ты не можешь считаться хорошим программистом-инструментальщиком. Попытка заменить эти базовые навыки банальной интуицией — всего лишь полумера.

CB>Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.


Это, конечно, позволит нам забороть стрёмный принцип Лискова. Но трудности на этом не кончаются. Поняв, что будет создан человек и выяснив, что он собирается делать с этими объектами (носить, поджигать, пилить, растворять в кислоте, грызть, прибивать, нюхать, складывать в штабеля, красить, поклоняться, выращивать, продавать и т.д.), мы начинаем медленно сходить с ума.

Базовая операция, на которой держится весь ООД — это операция обобщения. Если мы не можем нормально обобщить (выделить базовый класс), то большую половину всех вкусностей ООП мы не получаем. С одной стороны, живое дерево и мёртвый камень — принципиально разные объекты, но если судить по тому, что с ними можно делать (необходимый набор интерфейсов), то это почти одно и то же. Как выкручиваться? Известно как:
1. Создать оччччччччень толстый базовый класс CObject, в который напихать уйму свойств и виртуальных методов. А потом, понять, что жизнь наша от этого не облегчилась. И удивляться, почему всё так страшно тормозит и почему оперативка забилась таблицами виртуальных методов.
2. Применить какой-нибудь выверт типа множественного наследования или интерфейсного подхода. То есть вместо того, чтобы пройти по скользкой, опасной и длинной дороге обобщения один раз, мы будем ходить по множеству коротких, но от этого не менее скользких и опасных.

Кроме того, есть ещё одна тонкая проблема, которая мешает легко и радостно применять ООД. Это проблема выделения объектов из предметной области. Что считать объектом? Деревяшку? Камень? ОК. А деревяшку, приклеенную к другой деревяшке будем считать объектом? Куча камней — это объект? Куча мусора, в которой есть и камни, и деревяшки — это объект? Подгнивший краешек доски — это отдельный объект или как? Нарисованный камень, абстрактный камень, "что-то непонятное, торчащее из земли"???
Философская подоплёка этой проблемы заключается в том, что в реальном мире не существует объектов. То, что мы воспринимаем как "объекты", носим с места на место, поджигаем, пилим, растворяем в кислоте, грызём и т.п. никакой объектной сущностью не обладает. Деление мира на объекты — это особенности вычислительной модели, на которой основана работа устройства, расположенного у нас между ушами. Мы произвольно можем выделять объекты так, как нам это удобно. Логика — нечёткая. Сегодня я любуюсь камнем, а завтра — фотографией этого камня, и для меня это один и тот же объект. Компутер так не может. У него чёткая логика. У него однозначные интерпретации (а все неоднозначности — это либо ошибка программы, либо ошибка пользователя, но в любом случае мы с неоднозначностями предпочитаем бороться).

Вот и получается, что пока программа работает с простыми (желательно искусственными) сущностями типа элементов оконного интерфейса, ООП полезен и показывает себя с хорошей стороны. Как только сложность возрастает, ООП становится обузой.

Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем.
Re: ИМХО, главное ограничение ООП
От: craft-brother Россия  
Дата: 23.09.09 06:53
Оценка: 110 (6)
Здравствуйте, jeeist, Вы писали:

J>Почему-то мне кажется, что в реальной жизни

J>все устроено "не по ООП", а объекты могут быть
J>(или не быть) добавлены к этому.

История развития языков программирования в чем-то схожа с историей возникновения человеческой речи. Существует мнение, что содержание первых высказываний человека состояли исключительно из требований помощи, которую бы мог оказать ему другой индивид. «Если бы первые высказывания становящегося человека выразить с помощью нашего, развитого языка, они обязательно содержали бы глаголы в повелительном наклонении (“дай!”, “неси!”, “ломай!”, “режь!”, “бей!”, “поднимай!”, “тяни!” и т. п.)». Причем эти команды сопровождались жестами, которые точно указывали к чему конкретно это действие должно быть применено. Ну, очень похоже на команды императивных языков программирования! Например, команды ассемблеров с точным указанием адресов памяти или регистров.

Человек вначале научается отличать одну практическую ситуацию, взятую в целом, от другой ситуации. Выделение отдельных элементов этих ситуаций (предметов, над которыми совершаются действия, действий, которые совершаются над предметами) осуществляется позже – по мере того, как в практической деятельности человек все больше знакомился с окружающими его вещами, познавал их свойства и их отношения друг к другу и к самому человеку. Постепенно человек начинает выделять из конкретной ситуации объект действия (в программировании – данные) и само действие (в программировании — функции). Овладение способностью выделять объекты действия было настоящей революцией в умственном развитии первобытного чело века. А это уже не что иное, как всеми нами любимый объектно-ориентированный подход в программировании. По крайней мере, в его современной реализации в языках Java, .NET, C++.

Да, теперь мы уже научились говорить не просто «неси», а «неси дрова» или «неси камень». В своем развитии языки программирования остановились на том, что научились различать объекты (дрова и камень), но не научились выделять действия над ними. И с точки зрения языка программирования men.carry (firewood) и men.carry (stone) будут разными языковыми единицами, если только объекты firewood и stone не имеют общего предка! Просто реализация этими объектами интерфейса «то, что может носить человек» нас не выручит, поскольку это будет две реализации, а, следовательно, и единиц исходного кода тоже будет две.

Здесь и зарыто главное ограничение ООП, которое делает наши программы сложнее, чем они могли бы быть. «Таким образом, когда мы пытаемся определить, подходит ли нам конкретный дизайн (CB: программной системы) или нет, мы не можем рассматривать данное решение изолированно. Мы должны рассматривать его с точки зрения разумных предположений о том, как будет использоваться данный дизайн пользователями». (”The Liskov Substitution Principle”). Если перевести этот тезис на язык «дров» и «камней», то это будет звучать, примерно, так. Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.
Путь к ООП
От: jeeist  
Дата: 22.09.09 08:58
Оценка: :))) :)))
Извиняюсь, опять не смог ничего найти, хотя наверно
такая тема уже где-то была.

Заинтересовал вопрос: как лучше освоить ООП?
Точнее — что следует освоить перед этим.

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

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

22.09.09 15:29: Перенесено из 'О работе'
Re[2]: Путь к ООП
От: Кэр  
Дата: 28.09.09 11:46
Оценка: 82 (4) +1
Здравствуйте, vl690001x, Вы писали:

J>>Заинтересовал вопрос: как лучше освоить ООП?

J>>Точнее — что следует освоить перед этим.

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


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

Я, кстати, чем дальше тем больше сомневаюсь, что вопрос моделирования предметной области должен выражаться в терминах "а чтобы потом иметь естественный язык, который эту область описывали". Этого не получилось сделать на классах и объектах — решили вот теперь, что нужно с помощью макро-функциональщины моделировать языки, которые более гибкие и могут описать, как товары на склад/со склада уходят и транзакции между банками бегают. Язык, да еще и с уникальным синтаксисом, еще сложнее менять и отлаживать, чем набор классов. И если задача управления складов как всегда неожиданно потребовала, чтобы задача поддерживала три новых абстракции и радикально поменять пару существующих — то часто может оказаться, что лучше уж бы это был С-ный набор методов, который структуры передает, чем навороченная модель классов/собственная модель языка. Инструмент и инфраструктура для решения задачи опять может оказаться сложнее исходной задачи.
Re[2]: Путь к ООП
От: igna Россия  
Дата: 22.09.09 16:37
Оценка: 6 (1) :)))
Здравствуйте, michael_isu, Вы писали:

_>ООП во всей красе себя проявляет на больших проектах


О да! Во всей красе, это точно.
Re[5]: Путь к ООП
От: Silver_s Ниоткуда  
Дата: 23.09.09 15:08
Оценка: 2 (1) +1 :)
Здравствуйте, jeeist, Вы писали:

J>Меня интересует решение конкретных проблем.


J>Например, веб-серверы и страницы — если знаний хватает, чтобы построить модель классов и другие

J>модели УМЛ, написать сервлет или JSP, но непонятно, как все это работает.
Можно еще смешные комиксы нарисовать где веб сервисы сражаются с SQL серверами джедайскими мечами. Они будут одинаково полезны как УМЛ диаграммы. Но чтобы понять как все работает, прийдется и книжки конкретные почитать, без картинок. И руками поработать, поэкспериментировать, в коде поковыряться. И постепенно будет проясняться. А УМЛ картинки для того, чтоб не скучно изучать было.

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

Предлагаю написать алгоритм пузырьковой сортировки целочисленного массива в 3 вариантах:
1) По-обычному.
2) При помощи ООП.
3) При помощи кибернетики.
А и сравнить какой лучше. (только не надо спрашивать что означает 3 пункт)

ООП это набор трюков который может ингда упростить работу с большими объемами кода, а может и усложнить.
Вот пример полезного использования ООП. В винде есть dll с функциями CreateWindow, MoveWindow
Содание окна возвращает целочисленные циферки, так называемый хендел окна (HWND), что там на самом деле винда создает неизвестно и не нужно. Можно дальше просто передавать этот идентификатор в MoveWindow. Если это не ООП, то тогда совсем не нужно такое слово ООП.

А говорить что obj.Move(param) это ООП, а Move(obj,param) это уже не ООП было бы смешно.
Примеры где демонстрируется мощь полиморфизма: Есть абстрактный класс Фигура, с методом получения площади фигуры. Потом наследуют от Фигуры, Круг и Треуголник. И балдеют от того что фигура возвращает площадь определенную в Круге или Треугольнике.
То тут как минимум надо еще в реальности столкнуться со случаем когда это полезно будет.(таки случаи в принципе существуют)

J>Тогда вопрос — есть ли какая-то теория, которая описывает эту тему и которая может помочь понять?

J>Теория систем, например.
J>Или же человек не понимает чего-то элементарного и вопрос — как лучше освоить элементарные вещи.

Теория систем это философия (относительно программирования). В философии определенная польза есть. Но от конкретной работы философия не избавляет.
Re: Путь к ООП
От: vshabanov http://vshabanov-ru.blogspot.com
Дата: 22.09.09 13:46
Оценка: +3
Здравствуйте, jeeist, Вы писали:

J>Заинтересовал вопрос: как лучше освоить ООП?

J>Точнее — что следует освоить перед этим.

Встречный вопрос, а зачем осваивать ООП?

J>Почему-то мне кажется, что в реальной жизни

J>все устроено "не по ООП", а объекты могут быть
J>(или не быть) добавлены к этому.

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

J>И программист должен в первую очередь освоить

J>основы и только потом, если хочет, может добавить ООП.
J>А если начинать с ООП, ничего хорошего не получится.

Правильно. Почитай SICP -- основы программирования и TAOUP -- основы архитектуры. Потом можешь уже мельком посмотреть на ООП, наверняка придется работать с каким-нить ООП-кодом. И то, желательно посмотреть на SmallTalk (чистое ОО и сам язык получше) и только потом на костыли Буча и костыли-паттерны. Заодно сможешь оценить, насколько усложняет себе жизнь народ, использующий ООП, вместо того, чтобы использовать языки и подходы, в которых ОО не нужно.
Re: Путь к ООП - туда и обратно :)
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 22.09.09 16:31
Оценка: +3
Здравствуйте, jeeist, Вы писали:

J>Заинтересовал вопрос: как лучше освоить ООП?

J>Точнее — что следует освоить перед этим.

Если уже что-то достаточно плотно программировал, то Буч должен зайти с восторгом.

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

И ещё. За очень редким исключением (gamedev, имитационное моделирование) программа не должна моделировать реальный мир. Но она должна уметь встраиваться в реальный мир. Есть куча программ, которые замечательно что-то там моделируют, но для которых в реальном мире места не нашлось.
Re[5]: Путь к ООП - туда и обратно :)
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 24.09.09 15:18
Оценка: +3
Здравствуйте, jeeist, Вы писали:

J>Кстати — что было до этого? Помню, 15 лет назад читал учебники, но не помню,

J>что являлось тогда "серебряной пулей" — структурное или процедуральное программирование.

Копать нужно глубже. 15 лет назад народ (и я в том числе) уже вовсю фанател с ООП.
А лет 30 назад в мэйнстриме было именно структурное программирование. Ну и, естественно, применение ЯВУ было чрезвычайно модной фишкой.

J>А также — что является альтернативой для ООП — декларативное, в т.ч.

J>функциональное программирование?

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

Если интересно, что придёт на смену ООП, то правильный ответ — "ничего". Точно так же, как ООП не заменило структурное программирование, а лишь добавило инструментов и концепций, так и следующие модные фишки, думаю, будут добавлять, а не подменять.
Re[6]: Путь к ООП - туда и обратно :)
От: AndrewVK Россия http://blogs.rsdn.org/avk
Дата: 24.09.09 15:25
Оценка: +3
Здравствуйте, Voblin, Вы писали:

V>Копать нужно глубже. 15 лет назад народ (и я в том числе) уже вовсю фанател с ООП.


Точно. И многие пинали необъектное программирование. Теперь точно так же рассказывают про то, что ООП ни на что не годен, а серебряная пуля это уже что то другое. Например ФП.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
AVK Blog
Re[3]: Путь к ООП
От: denisko http://sdeniskos.blogspot.com/
Дата: 25.09.09 08:12
Оценка: :)))
Здравствуйте, IT, Вы писали:

IT>Это подобное мышление ущербно.

Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации. Т.е. тебе придется при разработке программы отвечать на вопрос "Что делать" (последовательность действий) и "Зачем делать" (логика). ООП и стиль "евоный" отвечает на вопрос "Как делать", как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...
<Подпись удалена модератором>
Re[4]: ИМХО, главное ограничение ООП
От: Voblin Россия http://maslyaew.narod.ru/
Дата: 05.10.09 10:48
Оценка: 4 (2)
Здравствуйте, craft-brother, Вы писали:

CB>Предостережение. Букв буде много, а мысли сумбурны. Автор не несет ответственность за возможное повреждение вашего мозга.


После того, как не далее как вчера дочитал "Структуру реальности" Дэвида Дойча, мой мозг уже ничто, наверное, повредить не может

CB>Программирование это способ отображения ментальных моделей в исполнимый код (без доказательства).

CB>...
CB>Есть еще много фундаментальных проблем, которые требуется решить на пути к новой более экономной парадигме программирования. Например, что есть время и как его моделировать в программных системах? А пространство? А физические поля?

А зря без доказательства.

Меня не оставляет смутное ощущение, что мировой теоретикал компутер сайнс неоправданно сильно заигрался моделированием. С одной стороны, это понятно. Компьютер — чрезвычайно эффективный вычислитель, а вычисление — это применение формулы, а формула — это математическая модель явления. Но кто из нас, айтишников, хотя бы 50% своего рабочего времени занимается научными расчётами? Ась? Есть здесь такие?
Когда-то, давным давно, когда компьютеры можно было пересчитать по пальцам, они действительно использовались исключительно для выполнения тяжёлых расчётов (в основном в чрезвычайно актуальных задачах ядерной физики и баллистики). Теперь же они используются в основном как средство общения и как развлекательные центры. Сейчас компьютер — это один из инструментов решения повседневных задач. Вернее сказать, это целый набор разнообразных инструментов (программ), удачно использующий заложенный в свою основу идею универсального вычислителя.

Т.е. программирование — это не способ отражения, и не способ преломления, а способ создания инструментов. Давайте теперь посмотрим, какие инструменты в истории материальной культуры были наиболее удачны и востребованы, и где там внутри них заложены модели:
  • Топор. Один из первых созданных человеком инструментов. Активно используется до сих пор. Модели дерева в себе не содержит, модели стройки — тоже. Только заострённый кусок твёрдого тяжёлого материала, прикреплённый к не очень длинной ручке. Молоток, нож — та же фигня. Никаких моделей.
  • Колесо (круглый предмет, закреплённый на оси). При желании можно найти прообраз, но никаких моделей не содержит. Да и вообще, очень всем нужные средства транспорта — автомобиль, паровоз, самолёт, ракета, не содержат в себе реализаций моделей предметной области.
  • Перо, чернила, бумага. Одна из самых первых, и до сих пор одна из самых распространённых и полезных информационных технологий. Никаких моделей в себе не содержит.

    Да, естественно, при создании инструмента мы должны весьма чётко представлять себе мир, в который попадёт создаваемый предмет. Учесть и законы физики, и законы химии, и психологию, и социологию, и эргономику. Пропустить макрокосм через свой личный микрокосм. Может быть, это и есть то самое моделирование? Вряд ли. В предмет закладывается только результат этого "моделирования", но сама модель в предмет не закладывается. "Модель" остаётся в голове создателя и, возможно, в набросках/технической документации/мемуарах.

    Отсюда вопрос. Почему всем "обычным" ремесленникам нужны средства производства, просто и эффективно решающие задачу, а программисту нужны исключительно такие, которые позволяют закладывать в продукт какую-то модель? Декларируемая как преимущество ООП его способность закладывать в программу модель мира — это на самом деле никакое не преимущество. Это увод мысли в сторону, бессмысленная трата времени и сил.

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

    CB>ИМХО, элементарным и неделимым атомом нашего знания является представление о структурах и взаимодействиях в них. Поэтому наиболее экономное представление наших ментальных моделей в программных системах мы получим, когда научимся изоморфно отражать элементы структур и их взаимодействия из наших ментальных моделей в программные компоненты.


    Не надо быть чересчур самонадеянными. В голове у нас (у всех) бардак полный. Абсолютно нечёткая логика, а иногда и вообще полное её отсутствие. Противоречие на противоречии. С точки зрения инженера-схемотехника наш мозг — это печальный результат взрыва на макаронной фабрике. Но во всём этом не только наша слабость, но и величайшая наша сила. Математика и компьютеры — наша палочка-выручалочка, позволяющая хоть как-то упорядочить это безобразие. Может быть, не стоит портить палочку-выручалочку?
    Поймите правильно. Это не призыв заморозить TCS и запретить кому-то над чем-то думать. Просто есть действительно важные, актуальные и совершенно никем не проработанные направления исследований, а есть соблазнительная, вкусная, но совершенно не питательная (может быть, пока не питательная) жвачка для ума типа прохождения теста Тьюринга или моделирования реального мира в программных реализациях текстового редактора.
  • Re: Путь к ООП
    От: sunsquirel США  
    Дата: 22.09.09 09:08
    Оценка: :))
    Здравствуйте, jeeist, Вы писали:

    J>Заинтересовал вопрос: как лучше освоить ООП?

    J>Точнее — что следует освоить перед этим.

    Любая книга по программированию на объектно-ориентированных языках, начинается с основ — типы, идентификаторы, функции и т.п., и только потом идет ООП. Так что надо начинать читать книжки с начала
    А насчет того, что в жизни "все не по ООП" — это какая-то странная теория... Мне кажется тот, кто понял ООП, думает как раз противоположным образом.
    Re[2]: Путь к ООП
    От: IT Россия linq2db.com
    Дата: 25.09.09 00:15
    Оценка: -1 :)
    Здравствуйте, rrsstio, Вы писали:

    R>ООП ущербно!


    Это подобное мышление ущербно.
    //rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
    Re[2]: Путь к ООП
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 28.09.09 10:46
    Оценка: 14 (1)
    Здравствуйте, SergeyT., Вы писали:

    [cut]

    ST>З.Ы. Нет "серебряной пули" и на горизонте ее тоже не видно. ООП — не панацея, это всего лишь один из множества способов решения задач разработчика. Многие идеи, присущие ООП, присущи и многим другим методам программирования, они не являются новыми, просто разное сочетание таких идей дает разный результат. Не нужно ни на чем зацикливаться, не нужно быть фанатом инструмента, технологии или методологии, это ограничивает сознание и дает однобокий взгляд на проблему.


    Думаю, в рамках выше сказанного будет интересна вот эта статья.
    Re[3]: Путь к ООП
    От: thesz Россия http://thesz.livejournal.com
    Дата: 22.09.09 13:38
    Оценка: 4 (1)
    Здравствуйте, jeeist, Вы писали:

    J>Здравствуйте, Baudolino, Вы писали:


    B>>В жизни всё по ООП. Этим ещё Дарвин пользовался, когда изучал происхождение видов.

    J>В жизни, да. Но в компьютерах — нет, там только единицы и нолики,
    J>которые процессор переключает

    J>Конечно, ООП — это красиво, объекты, функции, вызовы функций.


    J>Но, по-моему, пока человек не представляет, как объекты

    J>расположены в памяти и как процессор "шагает" по этим объектам,
    J>ему трудно будет написать что-то эффективное.

    J>Я это называю "не-ООП".


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

    ООП, который объекты, методы и всякие наследования, это, во-первых, область видимости (что называется системой модулей в других языках, например, Ада, Паскаль, Си) и, во-вторых, определённая логика для построения моделей мира (у Карделли она называется F:<, по-моему). Эти два понятия, обычно, перемешаны и редко делается различие между ними.

    Логика для построения моделей ложится не на все вычислительные парадигмы. Как пример, ООП практически не применяется в функциональном и логическом мире, хотя попытки натянуть её на какие-либо языки были в обоих мирах (OCaml и некоторые коммерческие прологи). Логика ООП была хоть как-то математически выражена примерно через 25 лет после появления ООП (Simula-67).

    В общем, вот.

    И ты прав. Логика ООП не совсем логика обычного мира. Для моделирования обычного мира лучше подходит теория множеств.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[8]: Путь к ООП - туда и обратно :)
    От: metaprogrammer  
    Дата: 02.11.09 19:10
    Оценка: 2 (1)
    Здравствуйте, VGn, Вы писали:

    M>> Это как "пчёлы против мёда"?


    VGn>Придумай другой механизм, позволяющий легко оперировать разными уровнями абстракции в программном коде.


    Я всю жизнь пользуюсь этими другими механизмами, коих очень, очень много. ООП — частный случай, пригодившийся только для задач агентного моделирования. Других применений ООП я не видел — для всех прочих задач эта модель неадекватна.
    Re[2]: ИМХО, главное ограничение ООП
    От: jeeist  
    Дата: 23.09.09 09:19
    Оценка: 1 (1)
    У меня такой вопрос: если речь идет о конкретном человеке.

    Должен ли он тоже пройти весь этот путь эволюции, т.е.
    изобрести (для себя) сначала функции, потом объекты/ООП?
    Или точнее — полезно ли это?

    Мне лично такой подход кажется разумным.
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 22.09.09 09:49
    Оценка: :)
    Здравствуйте, sunsquirel, Вы писали:

    S>Любая книга по программированию на объектно-ориентированных языках, начинается с основ — типы, идентификаторы, функции и т.п., и только потом идет ООП. Так что надо начинать читать книжки с начала

    S>А насчет того, что в жизни "все не по ООП" — это какая-то странная теория... Мне кажется тот, кто понял ООП, думает как раз противоположным образом.

    Мне кажется, что понимать ООП — это означает понимать,
    что под ООП стоит основа, которая не является "ОО"

    Просто я пытаюсь сделать веб-сайт с использованием ООП,
    но так чтобы я понимал, как этот сайт работает.

    Не сразу получается.
    Re[2]: Путь к ООП
    От: white_znake  
    Дата: 22.09.09 09:54
    Оценка: +1
    Здравствуйте, Baudolino, Вы писали:

    B>В жизни всё по ООП. Этим ещё Дарвин пользовался, когда изучал происхождение видов.


    Да ну? Дарвин точно не думал, что пользуется ООП
    А вообще есть хороший фильм — "23" — там главный герой начинает верить в магию цифр и начинает видеть в своей жизни только цифры 2 и 3.
    Думаю не стоит уподобляться этому герою и видеть в мире только ООП — ведь есть и другие парадигмы, которые когда надо применять при необходимости
    Re: Путь к ООП
    От: vl690001x Россия  
    Дата: 22.09.09 10:02
    Оценка: :)
    Здравствуйте, jeeist, Вы писали:

    J>Заинтересовал вопрос: как лучше освоить ООП?

    J>Точнее — что следует освоить перед этим.

    Прочитай книгу Гради Буча "Объектно-ориентированный анализ и проектирование". Она есть в электронном виде, но такие книги лучше иметь в бумажном варианте. Собственно, даже не знаю, что нужно знать перед ООП, но однозначно, для этого надо быть в какой-то степени личностью, организованной по принципам ООП). Вообще, изучить ООП нелегко, это большая работа, но легких путей не бывает. НЕ БЫВАЕТ, советую еще раз перечитать эти слова.
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 22.09.09 11:10
    Оценка: :)
    Здравствуйте, Vladek, Вы писали:

    V>В ООП объекты выполняют операции после запроса субъекта, который должен сам справляться об их состоянии, в жизни субъект напрямую оперирует объектами и испытывает их воздействие на него.


    Да, но ООП — это про объекты, а не субъекты Это слово там
    не упоминается

    А если серьезно, то к объектам предметной области
    надо добавить объекты ГУИ, веб-сервера, итд. Иначе будут
    красивые картинки и ужасные программы.
    Re: Путь к ООП
    От: rlabs Россия  
    Дата: 22.09.09 17:57
    Оценка: :)
    Здравствуйте, jeeist, Вы писали:

    J>Почему-то мне кажется, что в реальной жизни

    J>все устроено "не по ООП", а объекты могут быть
    J>(или не быть) добавлены к этому.

    Как раз в жизни все очень даже объектно-ориентировано.

    Жора.Подержи( МоиВещи.Макинтош )

    Классически для освоения ООП применяли Smalltalk, теперь вроде бы не всегда.
    Alex Nikulin
    Yota Lab
    Re[2]: Путь к ООП
    От: Буравчик Россия  
    Дата: 22.09.09 18:17
    Оценка: :)
    Здравствуйте, rlabs, Вы писали:

    R>Жора.Подержи( МоиВещи.Макинтош )


    Прекрасный пример несоответствия ООП реальной жизни.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1218>>
    Best regards, Буравчик
    Re[4]: ИМХО, главное ограничение ООП
    От: igna Россия  
    Дата: 23.09.09 12:46
    Оценка: +1
    Здравствуйте, craft-brother, Вы писали:

    CB>Если ты считаешь, что в классическом COBOLе были какие-то объекты до начала 90-х прошлого века, твое право.


    Твои "объекты действия" были. Это записи.

    CB>Курить И. Кант, "Критика чистого разума". Ключевые слова "вещь в себе".


    Ну ты демагог, прошу прощения.

    CB>No comments.


    И правильно. Притянута — так притянута, что тут комментировать.
    Re: Путь к ООП
    От: rrsstio  
    Дата: 25.09.09 00:01
    Оценка: -1
    Здравствуйте, jeeist, Вы писали:

    ООП ущербно!
    Re[4]: Путь к ООП
    От: IT Россия linq2db.com
    Дата: 25.09.09 13:22
    Оценка: +1
    Здравствуйте, denisko, Вы писали:

    D>Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации.


    Об этом разного рода мечтатели мечтают с того момента, когда я начал программировать. А это больше двадцати лет. И будут мечтать как минимум до тех пор, пока я не перестану программировать. А это ещё минимум двадцать лет.

    D>Т.е. тебе придется при разработке программы отвечать на вопрос "Что делать" (последовательность действий) и "Зачем делать" (логика). ООП и стиль "евоный" отвечает на вопрос "Как делать", как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...


    Ты путаешь императив и ООП.
    //rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
    Re[6]: Путь к ООП
    От: IT Россия linq2db.com
    Дата: 25.09.09 13:43
    Оценка: +1
    Здравствуйте, Курилка, Вы писали:

    D>>>Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации.


    IT>>Об этом разного рода мечтатели мечтают с того момента, когда я начал программировать. А это больше двадцати лет. И будут мечтать как минимум до тех пор, пока я не перестану программировать. А это ещё минимум двадцать лет.


    К>Думаю это было ещё до того момента


    Того момента я ещё не застал.

    К>Имхо как раз из подобных соображений придумывались в том числе SQL, а до него COBOL. Ну а последнему полвека на днях исполняется


    Кстати, SQL по логике denisko тоже должен умереть. В нём же при дизайне БД надо отвечать на вопросы 'как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...'
    //rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
    Re[7]: ИМХО, главное ограничение ООП
    От: FR  
    Дата: 05.10.09 14:23
    Оценка: +1
    Здравствуйте, Voblin, Вы писали:

    FR>>Может потому-что программист в виде продукта и создает эти самые модели и больше ничего?


    V>Может быть, в этом и проблема? Если бы кораблестроители вместо кораблей стали строить модели кораблей, а землекопы вместо копания ямок копали бы в песочнице модели ямок, никто бы их по головке не погладил...


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


    V>У кого как. По своему опыту скажу, что процентов 80 работы по изготовлению продукта — это созидание (т.е. синтез). Исследовательская работа (т.е. анализ) обычно бывает в начале процесса при постановке задачи и выборе метода решения и в конце, когда нужно понять, почему оно не работает


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

    V>Анализ и синтез — это принципиально разные навыки. Оба они, конечно, нужны, но способность к синтезу в нашем ремесле важна принципиально.


    Угу вот только оба навыка необходимы.
    Re[5]: Путь к ООП
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 08.10.09 09:33
    Оценка: +1
    Здравствуйте, jeeist, Вы писали:

    J>Здравствуйте, SergeyT., Вы писали:


    J>Спасибо за совет! Учту, но на данный момент меня интересуют книги, в которых описано, что такое программирование,

    J>например, цикл. Что такое императивное, функциональное программирование.

    J>Имеется ввиду не книги типа Java за полчаса для идиотов, а книги, которые используются

    J>в курсах связанных с информатикой/computer science.

    J>Ахо+Ульман?


    SICP, HTDP + PLAI.
    Re[2]: Путь к ООП - туда и обратно :)
    От: rfq  
    Дата: 01.11.09 06:13
    Оценка: :)
    Здравствуйте, Voblin, Вы писали:

    V>Путь к ООП обязательно нужно пройти. Но нужно иметь в виду, что, в общем-то, оно имеет под собой довольно слабенькую философскую основу. И поэтому нужно быть готовым не только пройти путь к ООП, но и путь от ООП. Т.е. в какой-то момент понять, что это не серебряная пуля, отбросить шоры, и только тогда научиться применять ООП действительно грамотно — там и только там, где оно применимо.


    V>И ещё. За очень редким исключением (gamedev, имитационное моделирование) программа не должна моделировать реальный мир. Но она должна уметь встраиваться в реальный мир. Есть куча программ, которые замечательно что-то там моделируют, но для которых в реальном мире места не нашлось.


    Как раз в большинстве случаев программа если не моделирует, то отображает реальный мир. Вот я набираю текст: в голове моей фраза, я по буковкам переношу ее в программу и программа моделирует мой мозг. Частично, конечно, но больше мне и не надо.
    Отображение фразы в программе — типичный объект, и философия его проста но никак не слаба: из реального мира поступают сообщения, по ним поддерживать актуальное состояние отображаемого объекта.
    Re: Путь к ООП
    От: Baudolino  
    Дата: 22.09.09 09:18
    Оценка:
    В жизни всё по ООП. Этим ещё Дарвин пользовался, когда изучал происхождение видов.
    Re: Путь к ООП
    От: Хвост  
    Дата: 22.09.09 09:22
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Заинтересовал вопрос: как лучше освоить ООП?

    J>Точнее — что следует освоить перед этим.

    всё зависит от того, что ты уже освоил.
    Что знаешь/умеешь?
    People write code, programming languages don't.
    Re: Путь к ООП
    От: michael_isu Беларусь  
    Дата: 22.09.09 09:27
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Извиняюсь, опять не смог ничего найти, хотя наверно

    J>такая тема уже где-то была.

    J>Заинтересовал вопрос: как лучше освоить ООП?

    J>Точнее — что следует освоить перед этим.

    J>Почему-то мне кажется, что в реальной жизни

    J>все устроено "не по ООП", а объекты могут быть
    J>(или не быть) добавлены к этому.

    J>И программист должен в первую очередь освоить

    J>основы и только потом, если хочет, может добавить ООП.
    J>А если начинать с ООП, ничего хорошего не получится.

    Набор заблуждений. ООП во всей красе себя проявляет на больших проектах, поэтому путь только один — начать их разрабатывать. Либо юниором устроиться в большую контору, либо в опен-сорсе к какому-то проекту присоединиться.
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 22.09.09 09:32
    Оценка:
    Здравствуйте, Baudolino, Вы писали:

    B>В жизни всё по ООП. Этим ещё Дарвин пользовался, когда изучал происхождение видов.

    В жизни, да. Но в компьютерах — нет, там только единицы и нолики,
    которые процессор переключает

    Конечно, ООП — это красиво, объекты, функции, вызовы функций.

    Но, по-моему, пока человек не представляет, как объекты
    расположены в памяти и как процессор "шагает" по этим объектам,
    ему трудно будет написать что-то эффективное.

    Я это называю "не-ООП".
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 22.09.09 09:59
    Оценка:
    Здравствуйте, Хвост, Вы писали:

    Х>всё зависит от того, что ты уже освоил.

    Х>Что знаешь/умеешь?

    Сначала я научился решить простую проблему,
    написав через ж запутанную программу с использованием ООП.

    Потом научился решить простую проблему,
    написав простую программу без ООП.

    Теперь пытаюсь научиться использовать ООП по назначению.
    Re[2]: Путь к ООП
    От: TimurSPB Интернет  
    Дата: 22.09.09 10:05
    Оценка:
    Я на первом курсе читал Гради Буча, тогда воспринималось как китайская грамота. Но прочитать надо.
    Make flame.politics Great Again!
    Re: Путь к ООП
    От: Vladek Россия Github
    Дата: 22.09.09 10:25
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Извиняюсь, опять не смог ничего найти, хотя наверно

    J>такая тема уже где-то была.

    J>Заинтересовал вопрос: как лучше освоить ООП?

    J>Точнее — что следует освоить перед этим.

    Гради Буч, "Объектно-ориентированный анализ и проектирование".

    J>Почему-то мне кажется, что в реальной жизни

    J>все устроено "не по ООП", а объекты могут быть
    J>(или не быть) добавлены к этому.

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

    J>И программист должен в первую очередь освоить

    J>основы и только потом, если хочет, может добавить ООП.
    J>А если начинать с ООП, ничего хорошего не получится.

    Да. Математики и философии будет достаточно.
    Everything is an object.
    http://files.rsdn.org/43395/hr-kyle-theisen-04.png
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 22.09.09 10:35
    Оценка:
    Здравствуйте, vl690001x, Вы писали:

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


    Я тоже прочел, понял, книга понравилась, наверно являлся ООП-личностью. И стал вовсю использовать.
    Только получилось что-то ужасное.

    Т.е. личностью, написать что-то простое, не являлся Чего-то не хватало...
    Re[3]: Путь к ООП
    От: Хвост  
    Дата: 22.09.09 10:52
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    Буч ето жестоко, прочитай лучше вот это:
    http://www.intuit.ru/department/se/oopbases/
    People write code, programming languages don't.
    Re: Путь к ООП
    От: eaa Украина  
    Дата: 22.09.09 11:12
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Заинтересовал вопрос: как лучше освоить ООП?


    Взять нормальный объектный (это не С++ подобный и тем более не язык поддерживающий несколько парадигм) язык и попрограмировать на нём. Рекомендую SmallTalk.

    J>Точнее — что следует освоить перед этим.


    Ничего это независимая парадигма и не требует спец знаний для использования.


    J>Почему-то мне кажется, что в реальной жизни

    J>все устроено "не по ООП", а объекты могут быть
    J>(или не быть) добавлены к этому.

    Ну иерархии не в ту сторону
    В програмировании иерархия расширяет функциоанльность в реальном мире уточняет.

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

    J>И программист должен в первую очередь освоить

    J>основы и только потом, если хочет, может добавить ООП.

    Основы это ассемблер? да это основа сех процедурных языков програмирования.
    Но к объектоному это не имеет ниикакого отношения. Тут скорее нужно забыть что внутри, что бы писать красивые программы в объектом стиле.


    J>А если начинать с ООП, ничего хорошего не получится.


    Если считать что человек думающий иначе чем ты заведомо думает хуже, то да.
    ... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
    Re[3]: Путь к ООП
    От: Vladek Россия Github
    Дата: 22.09.09 11:26
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Здравствуйте, Vladek, Вы писали:


    V>>В ООП объекты выполняют операции после запроса субъекта, который должен сам справляться об их состоянии, в жизни субъект напрямую оперирует объектами и испытывает их воздействие на него.


    J>Да, но ООП — это про объекты, а не субъекты Это слово там

    J>не упоминается

    Субъектом является сама программа. Или один объект по отношению к другому.

    J>А если серьезно, то к объектам предметной области

    J>надо добавить объекты ГУИ, веб-сервера, итд. Иначе будут
    J>красивые картинки и ужасные программы.

    Чего? Предметная область моделируется в программе ровно до той степени, в которой это необходимо для решения задачи. В чём вообще проблема? КУод не так элегантен как хотелось? Рефакторьте. Грамотно спроектированная система сама подсказывает где что надо исправить. Пишите тесты, формируйте удобный API к коду, затем пишите сам код, что API стал проходить тесты.

    Вот вам тест на ООП: сколько программистов требуется, чтобы ввернуть лампочку?
    I see dead pixels...
    http://files.rsdn.org/43395/hr-kyle-theisen-04.png
    Re: Путь к ООП
    От: jeeist  
    Дата: 22.09.09 11:27
    Оценка:
    J>Почему-то мне кажется, что в реальной жизни
    J>все устроено "не по ООП", а объекты могут быть
    J>(или не быть) добавлены к этому.

    "В реальной жизни" — имелось ввиду то, что _реально_
    происходит на уровне аппаратуры или ОС, в отличии от
    уровня языка программирования, среды разработки.
    Re[4]: Путь к ООП
    От: FR  
    Дата: 22.09.09 12:35
    Оценка:
    Здравствуйте, Хвост, Вы писали:

    Х>Буч ето жестоко, прочитай лучше вот это:

    Х>http://www.intuit.ru/department/se/oopbases/

    Или это http://www.ozon.ru/context/detail/id/136821/
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 22.09.09 13:16
    Оценка:
    Здравствуйте, eaa, Вы писали:

    eaa>Здравствуйте, jeeist, Вы писали:

    J>>И программист должен в первую очередь освоить
    J>>основы и только потом, если хочет, может добавить ООП.

    eaa>Основы это ассемблер? да это основа сех процедурных языков програмирования.

    eaa>Но к объектоному это не имеет ниикакого отношения. Тут скорее нужно забыть что внутри, что бы писать красивые программы в объектом стиле.

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

    J>>А если начинать с ООП, ничего хорошего не получится.


    eaa>Если считать что человек думающий иначе чем ты заведомо думает хуже, то да.


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

    Хотя это скорее практический, а не философический вопрос
    Re[3]: Путь к ООП
    От: Baudolino  
    Дата: 22.09.09 13:39
    Оценка:
    J>Я это называю "не-ООП".
    Это экстремизм. Так можно договориться до того, что эффективный код получается только если знаешь особенности работы конвейера или L2 кэша у каждого процессора поименно. Вас это не должно волновать — разделение труда на то и существует, чтобы вы не беспокоились о тонкостях чужой работы. Что касается изучения ООП, то, если вы поняли основную идею, почитайте "Паттерны" (Гамма, Хелм, Джонсон, Влиссидес) и "Архитектуру корп. приложений" Фаулера.
    Re[3]: Путь к ООП
    От: Baudolino  
    Дата: 22.09.09 13:41
    Оценка:
    _>Да ну? Дарвин точно не думал, что пользуется ООП
    Это была шутка, если вы не поняли
    Re[3]: Путь к ООП
    От: igna Россия  
    Дата: 22.09.09 16:36
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Сначала я научился решить простую проблему,

    J>написав через ж запутанную программу с использованием ООП.

    J>Потом научился решить простую проблему,

    J>написав простую программу без ООП.

    Ты на верном пути, в конце которого откроется, что ООП это бред. Хотя окончательный ответ зависит от твоего определения ООП. Например, для меня ООП начинается там, где начинается наследование от конкретных классов, соответственно для меня ООП это бред.
    Re[2]: Путь к ООП
    От: igna Россия  
    Дата: 22.09.09 16:44
    Оценка:
    Здравствуйте, vl690001x, Вы писали:

    V>однозначно, для этого надо быть в какой-то степени личностью, организованной по принципам ООП


    Блин. ООПисты когда-нибудь свою религию придумают.
    Re[2]: Путь к ООП
    От: igna Россия  
    Дата: 23.09.09 05:52
    Оценка:
    Здравствуйте, rlabs, Вы писали:

    R>Как раз в жизни все очень даже объектно-ориентировано.


    R>Жора.Подержи( МоиВещи.Макинтош )


    Рассуждения на уровне "космонавты летали в космос и видели, что никакого бога нет", а также "если бога нет, то кто же создал мир" и.т.п.
    Re[2]: Путь к ООП - туда и обратно :)
    От: jeeist  
    Дата: 23.09.09 08:00
    Оценка:
    Здравствуйте, Voblin, Вы писали:

    V>Путь к ООП обязательно нужно пройти. Но нужно иметь в виду, что, в общем-то, оно имеет под собой довольно слабенькую философскую основу. И поэтому нужно быть готовым не только пройти путь к ООП, но и путь от ООП. Т.е. в какой-то момент понять, что это не серебряная пуля, отбросить шоры, и только тогда научиться применять ООП действительно грамотно — там и только там, где оно применимо.


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

    Вопрос только, насколько радикально.

    Самый радикальный подход — это отобрать все, кроме Нотепада и компилятора
    и заставлять писать простые программы без ООП, пока дурь не вылетит из головы

    Или есть другие варианты, менее радикальные? Интересует в основном опыт практического
    применения.
    Re[2]: ИМХО, главное ограничение ООП
    От: igna Россия  
    Дата: 23.09.09 08:52
    Оценка:
    Здравствуйте, craft-brother, Вы писали:

    CB>Постепенно человек начинает выделять из конкретной ситуации объект действия (в программировании – данные) и само действие (в программировании — функции). Овладение способностью выделять объекты действия было настоящей революцией в умственном развитии первобытного чело века. А это уже не что иное, как всеми нами любимый объектно-ориентированный подход в программировании. По крайней мере, в его современной реализации в языках Java, .NET, C++.


    Способностью "выделять объекты действия" программисты обладали по крайней мере со времени появления записей в COBOL'е, который вовсе не считался ООЯ в то время. А чего-то подобного инкапсуляции в естественных языках нет. Аналогия притянута за уши.
    Re[4]: Путь к ООП
    От: jeeist  
    Дата: 23.09.09 09:07
    Оценка:
    Здравствуйте, thesz, Вы писали:
    T>"Не-ООП" называется вычислительной парадигмой. Их несколько: императивная, функциональная, логическая, поток данных...

    Меня интересует решение конкретных проблем.

    Например, веб-серверы и страницы — если знаний хватает, чтобы построить модель классов и другие
    модели УМЛ, написать сервлет или JSP, но непонятно, как все это работает.

    Тогда вопрос — есть ли какая-то теория, которая описывает эту тему и которая может помочь понять?
    Теория систем, например.

    Или же человек не понимает чего-то элементарного и вопрос — как лучше освоить элементарные вещи.
    Re[3]: ИМХО, главное ограничение ООП
    От: craft-brother Россия  
    Дата: 23.09.09 10:30
    Оценка:
    Здравствуйте, igna, Вы писали:

    I>Способностью "выделять объекты действия" программисты обладали по крайней мере со времени появления записей в COBOL'е, который вовсе не считался ООЯ в то время.


    Если ты считаешь, что в классическом COBOLе были какие-то объекты до начала 90-х прошлого века, твое право.

    I>А чего-то подобного инкапсуляции в естественных языках нет.


    Курить И. Кант, "Критика чистого разума". Ключевые слова "вещь в себе".

    I>Аналогия притянута за уши.


    No comments.
    Re[5]: Путь к ООП
    От: thesz Россия http://thesz.livejournal.com
    Дата: 23.09.09 10:49
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Здравствуйте, thesz, Вы писали:

    T>>"Не-ООП" называется вычислительной парадигмой. Их несколько: императивная, функциональная, логическая, поток данных...
    J>Меня интересует решение конкретных проблем.
    J>Например, веб-серверы и страницы — если знаний хватает, чтобы построить модель классов и другие
    J>модели УМЛ, написать сервлет или JSP, но непонятно, как все это работает.

    J>Тогда вопрос — есть ли какая-то теория, которая описывает эту тему и которая может помочь понять?


    пи-исчисление, например. join calculus.

    J>Теория систем, например.


    J>Или же человек не понимает чего-то элементарного и вопрос — как лучше освоить элементарные вещи.


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

    Время на его изучение лучше потратить на изучение других вещей, более полезных.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[6]: Путь к ООП
    От: jeeist  
    Дата: 23.09.09 11:21
    Оценка:
    Здравствуйте, thesz, Вы писали:

    T>Я повторюсь, что. с моей точки зрения, ООП предлагает неестественную логику для описания предметной области. Поэтому если ты до сих пор обходился без него, попытайся и дальше обходиться без него.


    T>Время на его изучение лучше потратить на изучение других вещей, более полезных.


    Я бы с удовольствием, но создается впечатление, что во всех серьезных проектах
    используют ООП и что скоро понятие программирование будет включать ООП (источник —
    Спольский или Макконнелл)
    Re[7]: Путь к ООП
    От: thesz Россия http://thesz.livejournal.com
    Дата: 23.09.09 12:09
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Здравствуйте, thesz, Вы писали:


    T>>Я повторюсь, что. с моей точки зрения, ООП предлагает неестественную логику для описания предметной области. Поэтому если ты до сих пор обходился без него, попытайся и дальше обходиться без него.


    T>>Время на его изучение лучше потратить на изучение других вещей, более полезных.


    J>Я бы с удовольствием, но создается впечатление, что во всех серьезных проектах

    J>используют ООП и что скоро понятие программирование будет включать ООП (источник —
    J>Спольский или Макконнелл)

    Не стоит так думать.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[6]: Путь к ООП
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 23.09.09 15:30
    Оценка:
    Здравствуйте, Silver_s, Вы писали:

    S_>Здравствуйте, jeeist, Вы писали:

    J>>Тогда вопрос — есть ли какая-то теория, которая описывает эту тему и которая может помочь понять?
    J>>Теория систем, например.
    J>>Или же человек не понимает чего-то элементарного и вопрос — как лучше освоить элементарные вещи.

    S_> Теория систем это философия (относительно программирования). В философии определенная польза есть. Но от конкретной работы философия не избавляет.


    Теория систем — часть кибернетики, кибернетика != философия.
    Re[7]: Путь к ООП
    От: Silver_s Ниоткуда  
    Дата: 23.09.09 15:52
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    К>Теория систем — часть кибернетики, кибернетика != философия.

    И кибернетика тоже философия.
    По поводу кибернетики есть даже такое высказывание (профессор какой-то сказал)

    в США вы не можете употреблять слово "кибернетика", потому что большое число пустопорожних работ создало впечатление о несерьезности этой теории


    Слазил в Wiki, узнать что считают философией, и ожидания оправдались:

    Филосо́фия — наиболее общая теория[1], одна из форм мировоззрения, одна из наук[2] одна из форм человеческой деятельности, особый способ познания. Общепринятого определения философии, равно как общепринятого представления о предмете философии, не существует.


    Будем считать что у философии есть прикладное ответвление называющееся "Философия программирования" (а не просто написания кода), и оно довольно сильно пересекается и с кибернетикой и с теорией систем.
    Re: Путь к ООП
    От: EvilChild Ниоткуда  
    Дата: 23.09.09 16:10
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    В этой Foundations of Object-Oriented Languages Types and Semantics книге есть неплохое систематическое изложене возможностей ОО языков.
    Есть ещё A Theory of Objects с виду ещё более основательная, но она весьма брутальна судя по содержанию и не удалось найти её в цифре.
    now playing: Massive Attack — Psyche (feat. Martina Topley-Bird) (Van Rivers & the Subliminal Kid Remix)
    Re[3]: Путь к ООП - туда и обратно :)
    От: Voblin Россия http://maslyaew.narod.ru/
    Дата: 23.09.09 16:59
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Как раз это меня интересует. Мне кажется, что если взгляды на программирование

    J>основаны исключительно на ООП, то рано или поздно придется все перестраивать.

    Если человек умеет пользоваться только молотком, и ни о чём другом слышать не желает, то он никогда нормально не закрутит шуруп.
    ООП — это всего лишь одна из техник программирования. Нужно ли ею владеть? Желательно. Можно ли владеть только ООП? Честно говоря, я себе это вообще представить не могу.

    J>Самый радикальный подход — это отобрать все, кроме Нотепада и компилятора

    J>и заставлять писать простые программы без ООП, пока дурь не вылетит из головы
    J>Или есть другие варианты, менее радикальные? Интересует в основном опыт практического
    J>применения.

    Менее радикальный — это "сходить налево" туда, где ООП вообще не применяется. Это не обязательно Нотепад. Это может быть что-то из ФП, это может быть SQL, это может быть VBA или 1С.
    Re: Путь к ООП
    От: MasterZiv СССР  
    Дата: 24.09.09 08:48
    Оценка:
    jeeist wrote:

    > Заинтересовал вопрос: как лучше освоить ООП?

    > Точнее — что следует освоить перед этим.

    Просто программирование. Обычное. Чтобы понять,
    что можно жить и без объектов. Тогда лучше
    поймёшь, зачем нужны объекты.

    > Почему-то мне кажется, что в реальной жизни

    > все устроено "не по ООП", а объекты могут быть
    > (или не быть) добавлены к этому.

    Вообще, в начале ООП как раз применялось для
    моделирования объектов реального мира.

    > И программист должен в первую очередь освоить

    > основы и только потом, если хочет, может добавить ООП.
    > А если начинать с ООП, ничего хорошего не получится.

    Я думаю, что именно так.
    Posted via RSDN NNTP Server 2.1 beta
    Re[4]: Путь к ООП - туда и обратно :)
    От: jeeist  
    Дата: 24.09.09 14:26
    Оценка:
    Здравствуйте, Voblin, Вы писали:

    V>Здравствуйте, jeeist, Вы писали:


    J>>Самый радикальный подход — это отобрать все, кроме Нотепада и компилятора

    J>>и заставлять писать простые программы без ООП, пока дурь не вылетит из головы
    J>>Или есть другие варианты, менее радикальные? Интересует в основном опыт практического
    J>>применения.

    V>Менее радикальный — это "сходить налево" туда, где ООП вообще не применяется. Это не обязательно Нотепад. Это может быть что-то из ФП, это может быть SQL, это может быть VBA или 1С.


    Но хотелось бы делать то же самое, но по другому

    Кстати — что было до этого? Помню, 15 лет назад читал учебники, но не помню,
    что являлось тогда "серебряной пулей" — структурное или процедуральное программирование.

    А также — что является альтернативой для ООП — декларативное, в т.ч.
    функциональное программирование?

    Т.е. Microsoft vs Apple, PepsiCola vs CocaCola, ООП vs что?
    Re[7]: Путь к ООП - туда и обратно :)
    От: Voblin Россия http://maslyaew.narod.ru/
    Дата: 24.09.09 16:35
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    V>>Копать нужно глубже. 15 лет назад народ (и я в том числе) уже вовсю фанател с ООП.

    AVK>Точно. И многие пинали необъектное программирование.

    Эх, славные были времена. Где те TurboVision-ы и DBVist-ы, с которых все пёрлись?

    AVK>Теперь точно так же рассказывают про то, что ООП ни на что не годен, а серебряная пуля это уже что то другое. Например ФП.


    Страстные натуры всегда так — сначала приходят в дикий восторг, а потом... http://rsdn.org/forum/images/anvaka/barf.gif горькое разочарование в обманутых надеждах. Но можно и по-другому: по-прежнему приходить в дикий восторг и прыгать от радости, но где-нибудь в глубине сознания заранее зацепить, что новый объект страсти тоже не идеален т.к. "серебряных пуль" не бывает. А те, которые бывают, как правило для употребления вообще не пригодны.
    Re[7]: Путь к ООП - туда и обратно :)
    От: IT Россия linq2db.com
    Дата: 25.09.09 00:14
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Точно. И многие пинали необъектное программирование. Теперь точно так же рассказывают про то, что ООП ни на что не годен, а серебряная пуля это уже что то другое. Например ФП.


    А некоторые считают, что если пепельница забилась, то нужно менять машину.
    //rsdn.org/forum/images/bis.gif Если нам не помогут, то мы тоже никого не пощадим.
    Re[5]: Путь к ООП
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 25.09.09 13:36
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Здравствуйте, denisko, Вы писали:


    D>>Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации.


    IT>Об этом разного рода мечтатели мечтают с того момента, когда я начал программировать. А это больше двадцати лет. И будут мечтать как минимум до тех пор, пока я не перестану программировать. А это ещё минимум двадцать лет.


    Думаю это было ещё до того момента
    Имхо как раз из подобных соображений придумывались в том числе SQL, а до него COBOL. Ну а последнему полвека на днях исполняется
    Re: Путь к ООП
    От: runtime2  
    Дата: 25.09.09 14:48
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Извиняюсь, опять не смог ничего найти, хотя наверно

    J>такая тема уже где-то была.

    J>Заинтересовал вопрос: как лучше освоить ООП?

    J>Точнее — что следует освоить перед этим.

    Делаешь следующее

    1. Читаешь "Рефакторинг" Фаулера.
    2. Читаешь "Рефакторинг с использованием шаблонов" Джошуа Кериевски
    3. По ходу чтения делаешь рефакторинги в проекте, который разрабатывается год-полтора в условиях меняющихся требований (часто противоположных).
    4. Пользуешься советом Voblin (http://www.rsdn.ru/forum/philosophy/3547140.1.aspx
    Автор: Voblin
    Дата: 24.09.09
    )

    "Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."

    Поэтому, Буча лучше потом почитать.
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 28.09.09 08:02
    Оценка:
    R>"Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."

    Очень правильно. Только вот как искать работу С#-исту или Джависту, который
    не использует ООП? Поймет ли его потенциальный работодатель?
    Re[3]: Путь к ООП
    От: Курилка Россия http://kirya.narod.ru/
    Дата: 28.09.09 08:08
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    R>>"Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."


    J>Очень правильно. Только вот как искать работу С#-исту или Джависту, который

    J>не использует ООП? Поймет ли его потенциальный работодатель?

    Т.е. ты даже стандартные либы использовать не будешь?
    А в целом есть поговорка "в чужой монастырь с своим уставом не ходят", а ООП является основным подходом хотябы в яве (но это не мешает местами использовать другие методы)
    Re[4]: Путь к ООП
    От: jeeist  
    Дата: 28.09.09 09:31
    Оценка:
    Здравствуйте, Курилка, Вы писали:

    К>Здравствуйте, jeeist, Вы писали:


    R>>>"Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем."


    J>>Очень правильно. Только вот как искать работу С#-исту или Джависту, который

    J>>не использует ООП? Поймет ли его потенциальный работодатель?

    К>Т.е. ты даже стандартные либы использовать не будешь?

    К>А в целом есть поговорка "в чужой монастырь с своим уставом не ходят", а ООП является основным подходом хотябы в яве (но это не мешает местами использовать другие методы)

    Задал вопрос, а потом сам (вроде бы) нашел ответ. На самом деле даже файл PHP
    наверно можно рассматривать как объект+паттерн Фасад(?).

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

    Только между слоями системы можно передавать бизнес-объекты,
    а можно — XML, например.
    Re: Путь к ООП
    От: SergeyT. США http://sergeyteplyakov.blogspot.com/
    Дата: 28.09.09 10:14
    Оценка:
    Здравствуйте, jeeist, Вы писали:

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

    Сложность

    Звезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующие вирус, — это только некоторые из потрясающе сложных объектов физического мира. Компьютерные программы тоже бывают сложными, однако их сложность совершенно другого рода. Брукс пишет: "Эйнштейн утверждал, что должны существовать простые объяснения природных процессов, так как Бог не действует из каприза или по произволу. У программиста нет такого утешения: сложность, с которой он должен справиться, лежит в самой природе системы" [1].

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

    Существенная черта промышленной программы — уровень сложности: один разработчик практически не в состоянии охватить все аспекты такой системы. Грубо говоря, сложность промышленных программ превышает возможности человеческого интеллекта. Увы, но сложность, о которой мы говорим, по-видимому, присуща всем большим программных системам. Говоря "присуща", мы имеем в виду, что эта сложность здесь неизбежна: с ней можно справиться, но избавиться от нее нельзя.


    и далее

    Как говорит Брукс, "сложность программного обеспечения — отнюдь не случайное его свойство" [3]. Сложность вызывается четырьмя основными причинами:

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



    Структура сложных систем

    Существует мнение (в частности, прекрасно описанное в работе Буча), что существует ряд характеристик, присущих каждой сложной системе.

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

    2. Выбор, какие компоненты в данной системе считаются элементарными, относительно произволен и в большой степени оставляется на усмотрение исследователя.

    3. "Внутрикомпонентная связь обычно сильнее, чем связь между компонентами. Это обстоятельство позволяет отделять "высокочастотные" взаимодействия внутри компонентов от "низкочастотной" динамики взаимодействия между компонентами"

    4. "Иерархические системы обычно состоят из немногих типов подсистем, по-разному скомбинированных и организованных"

    5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".


    Роль абстракции

    Выше мы ссылались на эксперименты Миллера, в которых было установлено, что обычно человек может одновременно воспринять лишь 7±2 единицы информации. Это число, по-видимому, не зависит от содержания информации. Как замечает сам Миллер: "Размер нашей памяти накладывает жесткие ограничения на количество информации, которое мы можем воспринять, обработать и запомнить. Организуя поступление входной информации одновременно по нескольким различным каналам и в виде последовательности отдельных порций, мы можем прорвать... этот информационный затор" [35]. В современной терминологии это называют разбиением или выделением абстракций.


    Смысл абстрагирования. Абстрагирование является одним из основных методов, используемых для решения сложных задач. Хоар считает, что "абстрагирование проявляется в нахождении сходств между определенными объектами, ситуациями или процессами реального мира, и в принятии решений на основе этих сходств, отвлекаясь на время от имеющихся различий" [42]. Шоу определила это понятие так: "Упрощенное описание или изложение системы, при котором одни свойства и детали выделяются, а другие опускаются. Хорошей является такая абстракция, которая подчеркивает детали, существенные для рассмотрения и использования, и опускает те, которые на данный момент несущественны" [43]. Берзинс, Грей и Науман рекомендовали, чтобы "идея квалифицировалась как абстракция только, если она может быть изложена, понята и проанализирована независимо от механизма, который будет в дальнейшем принят для ее реализации" [44]. Суммируя эти разные точки зрения, получим следующее определение абстракции:

    Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.

    Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности поведения от несущественных. Абельсон и Суссман назвали такое разделение смысла и реализации барьером абстракции [45], который основывается на принципе минимизации связей, когда интерфейс объекта содержит только существенные аспекты поведения и ничего больше [46]. Мы считаем полезным еще один дополнительный принцип, называемый принципом наименьшего удивления, согласно которому абстракция должна охватывать все поведение объекта, но не больше и не меньше, и не привносить сюрпризов или побочных эффектов, лежащих вне ее сферы применимости.


    Роль декомпозиции

    Как отмечает Дейкстра, "Способ управления сложными системами был известен еще в древности — divide et impera (разделяй и властвуй)" [16]. При проектировании сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо. В этом случае мы не превысим пропускной способности человеческого мозга: для понимания любого уровня системы нам необходимо одновременно держать в уме информацию лишь о немногих ее частях (отнюдь не о всех). В самом деле, как заметил Парнас, декомпозиция вызвана сложностью программирования системы, поскольку именно эта сложность вынуждает делить пространство состояний системы .


    Еще в 1979 году в своей книге “Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design” Эда Йордона (Ed Yourdon) и Ларри Константайна (Larry L. Constantine) одни из первых определили фундаментальные понятия модульности ПО, такие как связанность (cohesion) и связность (coupling), основываясь на понятиях, приведенных в книге Алексендера “Notes On The Synthesis Of Form”.
    По мнению Александера основной задачей при декомпозиции системы является осуществление следующих двух условий:
    — максимизация связей внутри компонентов (высокое сцепление (high cohesion)) и
    — минимизация связей между компонентами (низкая связность(low coupling)).
    Эти проблемы широко известна в программной индустрии и описана в любой книге по проектированию и построению программных систем, но, если верить Александеру, они присущи проектированию любых сложных систем.


    ООП

    Объектно-ориентированная технология основывается на так называемой объектной модели. Основными ее принципами являются: абстрагирование, инкапсуляция, модульность, иерархичность, типизация, параллелизм и сохраняемость. Каждый из этих принципов сам по себе не нов, но в объектной модели они впервые применены в совокупности.


    Термин объектно-ориентированный, по мнению Бхаскара, "затаскан до потери смысла, как "материнство", "яблочный пирог" и "структурное программирование"" [7]. Можно согласиться, что понятие объекта является центральным во всем, что относится к объектно-ориентированной методологии. В главе 1 мы определили объект как осязаемую сущность, которая четко проявляет свое поведение. Стефик и Бобров определяют объекты как "сущности, объединяющие процедуры и данные, так как они производят вычисления и сохраняют свое локальное состояние" [8]. Определение объекта как сущности в какой-то мере отвечает на вопрос, но все же главным в понятии объекта является объединение идей абстракции данных и алгоритмов. Джонс уточняет это понятие следующим образом: "В объектном подходе акцент переносится на конкретные характеристики физической или абстрактной системы, являющейся предметом программного моделирования... Объекты обладают целостностью, которая не должна — а, в действительности, не может — быть нарушена. Объект может только менять состояние, вести себя, управляться или становиться в определенное отношение к другим объектам. Иначе говоря, свойства, которые характеризуют объект и его поведение, остаются неизменными.


    Стоит отметить, что наследование — не является ключевой характеристикой ООП (как писали некоторые на этом форуме).
    Более того, все авторы (включая Буча и Мейера — наиболее авторитетных авторов в этой области) всячески остерегают разработчиков от чрезмерного использования наследования. Ведь наследование увеличивает связность (coupling), что негативно сказывается на понимании и последующем развитии системы. Этим инструментом (наследованием) нужно пользоваться весьма осторожно и всегда отдавать предпочтение агрегации, а применять наследования только для моделирования отношения является (IS A relationship).

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

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

    З.Ы. Нет "серебряной пули" и на горизонте ее тоже не видно. ООП — не панацея, это всего лишь один из множества способов решения задач разработчика. Многие идеи, присущие ООП, присущи и многим другим методам программирования, они не являются новыми, просто разное сочетание таких идей дает разный результат. Не нужно ни на чем зацикливаться, не нужно быть фанатом инструмента, технологии или методологии, это ограничивает сознание и дает однобокий взгляд на проблему.
    Re[2]: Путь к ООП
    От: jeeist  
    Дата: 28.09.09 11:13
    Оценка:
    К сожалению, не понял формат Вашего сообщения — является ли весь выделенный Вами текст цитатой(-ами)
    или это задумалось как статья?

    Материал очень ценный, просто я не дорос еще до этого уровня.

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

    ...
    ST>5. "Любая работающая сложная система является результатом развития работавшей более простой системы... Сложная система, спроектированная "с нуля", никогда не заработает. Следует начинать с работающей простой системы".

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

    Но все же с первого взгляда не видно, чем объясняется отличие между простой
    системой 1 разработчика и простой системой разработанной коллективом.
    Re[3]: Путь к ООП
    От: SergeyT. США http://sergeyteplyakov.blogspot.com/
    Дата: 28.09.09 11:22
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>К сожалению, не понял формат Вашего сообщения — является ли весь выделенный Вами текст цитатой(-ами)

    J>или это задумалось как статья?

    J>Материал очень ценный, просто я не дорос еще до этого уровня.


    Большая часть — это цитаты книги Гради Буча "Объектно-ориентированный анализ и проектирование", в частности первой ее части. Я приводил цитаты кусками, поэтому вполне мог "потерять" что-то ценное и изложение могло стать не совсем понятным.
    2-е издание Буча доступно в электронном виде на русском языке. Первая часть книги (как по мне, наиболее ценная) практически не поменялась в третьем издании по сравнению со вторым.
    Поэтому, если цитаты заинтересовали — почитайте хотя бы первую часть этой книги, должно быть как минимум интересно.
    Re[7]: Путь к ООП
    От: denisko http://sdeniskos.blogspot.com/
    Дата: 29.09.09 13:37
    Оценка:
    Здравствуйте, IT, Вы писали:

    IT>Кстати, SQL по логике denisko тоже должен умереть. В нём же при дизайне БД надо отвечать на вопросы 'как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...'

    Вот SQL как раз пофиг как...Например ему пофиг как объект наблюдатель и объект инквизитор придут в гости к объекту поле данных и будут уныло тупить,
    поскольку архитектор "на этапе проектирования" не заложил в них способность поддерживать светскую беседу. Он просто говорит сделай мне то-то и то-то. Понимаешь надо уходить от того, что тебе приходится утирать сопли объектам и разбираться что и как в них от рождения было заложено. И какие у них там семеные и иерархические проблемы. Надо так -- дал поручение объекту, если выполнил то сказал спасибо, нет -- дал песты. И не дай бог заботится о том, чтобы у это шибздрика было реализован интерфейс пестополучатель. Возможна такая картинка? Да вполне. Возможна ли скоро? Да, имхо препятствий кроме лени нет. Какая парадигма удобнее для нее альтруистичная (когда ты объектам и папа и мама и на дудец игрец и вообще в курсе их проблем) или функциональная ( когда есть что тебе надо сделать, а как и кем -- пофиг. Ты платишь за результат) ответь сам.
    <Подпись удалена модератором>
    Re[3]: ИМХО, главное ограничение ООП
    От: craft-brother Россия  
    Дата: 01.10.09 09:06
    Оценка:
    Здравствуйте, Voblin, Вы писали:

    +1024. Ты очень даже прав. Просто не могу не поделиться своими терзаниями по этому поводу.

    Предостережение. Букв буде много, а мысли сумбурны. Автор не несет ответственность за возможное повреждение вашего мозга.

    По мне уже 20 лет гуляет идея. Родилась она, когда я проектировал имитационные модели сложных космических систем. Как-то меня осенило, что объектов и их свойств в реальном мире как таковых нет. Это лишь способ отражения объективной реальности в нашей голове. А что же есть? Есть структуры и их взаимодействия.

    Пример 1.

    Не существует свойство «синий», например, у автомобиля. Это лишь один из возможных результатов трехстороннего взаимодействия некоторых элементов:
    1) поток фотонов из источника света;
    2) отражение и излучение (незабываем про инфракрасный диапазон) фотонов кузовом автомобиля;
    3) наблюдатели, которые увидят совершенно разные цвета, в зависимости от того, какого цвета очки у них на глазах.

    Пример 2.

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

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

    Вывод. Свойств и объектов нет. Есть структуры и их взаимодействия.

    Что же из этого следует?

    Программирование это способ отображения ментальных моделей в исполнимый код (без доказательства).
    ИМХО, элементарным и неделимым атомом нашего знания является представление о структурах и взаимодействиях в них. Поэтому наиболее экономное представление наших ментальных моделей в программных системах мы получим, когда научимся изоморфно отражать элементы структур и их взаимодействия из наших ментальных моделей в программные компоненты.

    Возвращаясь к перетаскиванию камней и дров (см. мой начальный пост
    Автор: craft-brother
    Дата: 23.09.09
    ), предлагаю попытаться представить, как это может выглядеть.

    Мы должны разработать библиотечный метод carry (Еcarrier, Еthing). Элемент Еcarrier должен реализовывать интерфейсы: "Брать" и "Перемещаться в пространстве". А элемент Еthing должен реализовывать интерфейсы: "Вес" и "Форма".

    В этом случае наша модель действия нести получится достаточно универсальной. Метод не будет меняться от того, что человек реализует интерфейс Брать руками, собака — зубами, а подъемный кран — крюком. Поэтому мы сможем легко пополнять нашу программную систему любыми элементами, которые реализуют необходимые для Еcarrier, Еthing интерфейсы и нам не понадобится менять нашу универсальную функцию.

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

    Я размышляю хоть и много, но не очень продуктивно

    Мой коллега по ЦУПу, человек с необычайной энергией, развивая некоторые мои идеи, разработал некоторый универсальный решатель научно-технических задач. Если кого заинтересовало, смотреть здесь и около. Однако, это лишь инструмент инженера, а не новая парадигма программирования, которую бы хотелось получить.

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

    Успехов,
    Re[5]: ИМХО, главное ограничение ООП
    От: FR  
    Дата: 05.10.09 11:08
    Оценка:
    Здравствуйте, Voblin, Вы писали:

    V>Отсюда вопрос. Почему всем "обычным" ремесленникам нужны средства производства, просто и эффективно решающие задачу, а программисту нужны исключительно такие, которые позволяют закладывать в продукт какую-то модель? Декларируемая как преимущество ООП его способность закладывать в программу модель мира — это на самом деле никакое не преимущество. Это увод мысли в сторону, бессмысленная трата времени и сил.


    Может потому-что программист в виде продукта и создает эти самые модели и больше ничего?

    V>Ничего не имею против моделирования как такового. Моделирование — хорошая и мощная исследовательская технология.


    Так очень большая часть работы любого программиста исследовательская, или как минимум требующая очень похожих навыков.
    Re[6]: ИМХО, главное ограничение ООП
    От: Voblin Россия http://maslyaew.narod.ru/
    Дата: 05.10.09 13:31
    Оценка:
    Здравствуйте, FR, Вы писали:

    V>>Декларируемая как преимущество ООП его способность закладывать в программу модель мира — это на самом деле никакое не преимущество. Это увод мысли в сторону, бессмысленная трата времени и сил.

    FR>Может потому-что программист в виде продукта и создает эти самые модели и больше ничего?

    Может быть, в этом и проблема? Если бы кораблестроители вместо кораблей стали строить модели кораблей, а землекопы вместо копания ямок копали бы в песочнице модели ямок, никто бы их по головке не погладил...

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


    У кого как. По своему опыту скажу, что процентов 80 работы по изготовлению продукта — это созидание (т.е. синтез). Исследовательская работа (т.е. анализ) обычно бывает в начале процесса при постановке задачи и выборе метода решения и в конце, когда нужно понять, почему оно не работает
    Анализ и синтез — это принципиально разные навыки. Оба они, конечно, нужны, но способность к синтезу в нашем ремесле важна принципиально.
    Re[8]: Путь к ООП - туда и обратно :)
    От: dr.Chaos Россия Украшения HandMade
    Дата: 05.10.09 14:37
    Оценка:
    Здравствуйте, Voblin, Вы писали:

    V>Эх, славные были времена. Где те TurboVision-ы и DBVist-ы, с которых все пёрлись?


    Некоторые от неё до сих пор плюются.
    Побеждающий других — силен,
    Побеждающий себя — Могущественен.
    Лао Цзы
    Re[8]: ИМХО, главное ограничение ООП
    От: Voblin Россия http://maslyaew.narod.ru/
    Дата: 06.10.09 09:41
    Оценка:
    Здравствуйте, FR, Вы писали:

    V>>Может быть, в этом и проблема? Если бы кораблестроители вместо кораблей стали строить модели кораблей, а землекопы вместо копания ямок копали бы в песочнице модели ямок, никто бы их по головке не погладил...

    FR>Если бы у кораблестроителей была возможность с помощью чистого описания и моделирования строить реальный корабль, они с радостью бы это делали.

    Здесь я, конечно, перегнул маленько Естественно, те кораблестроители, которые сидят в проектных институтах, строят именно модели кораблей. У них эти модели называются "чертёж", "спецификация", "технологическая карта", "рабочий проект". В отличие от материального производства в программировании, как правило, результат проектирования и является готовым изделием (ничто так хорошо и однозначно не документирует программу как её исходник).
    Речь о другом. В конструкцию корабля не закладывается имитационная модель моря, порта, матросов и перевозимого груза. Знания о море, конструкции портовых сооружений, о людях и т.п. используются при проектировании (а как же ещё?), но непосредственно в конструкцию не закладываются.
    Если при проектировании гипотетической программы-корабля применить ООП, сразу же возникнет соблазн создать классы CSea, CSalor, CCargo и пр., и попытаться нарисовать всё сложное взаимодействие между ними. Зачем — ХЗ Просто потому, что считается модным моделировать реальный мир и того требует методология ООД.

    V>>У кого как. По своему опыту скажу, что процентов 80 работы по изготовлению продукта — это созидание (т.е. синтез). Исследовательская работа (т.е. анализ) обычно бывает в начале процесса при постановке задачи и выборе метода решения и в конце, когда нужно понять, почему оно не работает

    FR>Не только, этап конструирования и мелкого проектирования длится до окончания разработки, и исследование там тоже нередко применяется.

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

    V>>Анализ и синтез — это принципиально разные навыки. Оба они, конечно, нужны, но способность к синтезу в нашем ремесле важна принципиально.

    FR>Угу вот только оба навыка необходимы.

    Конечно. И ещё важен навык написания пользовательской документации без применения ненормативной лексики.
    Re[4]: Путь к ООП
    От: jeeist  
    Дата: 08.10.09 09:00
    Оценка:
    Здравствуйте, SergeyT., Вы писали:

    ST>Здравствуйте, jeeist, Вы писали:


    J>>К сожалению, не понял формат Вашего сообщения — является ли весь выделенный Вами текст цитатой(-ами)

    J>>или это задумалось как статья?

    J>>Материал очень ценный, просто я не дорос еще до этого уровня.


    ST>Большая часть — это цитаты книги Гради Буча "Объектно-ориентированный анализ и проектирование", в частности первой ее части. Я приводил цитаты кусками, поэтому вполне мог "потерять" что-то ценное и изложение могло стать не совсем понятным.

    ST>2-е издание Буча доступно в электронном виде на русском языке. Первая часть книги (как по мне, наиболее ценная) практически не поменялась в третьем издании по сравнению со вторым.
    ST>Поэтому, если цитаты заинтересовали — почитайте хотя бы первую часть этой книги, должно быть как минимум интересно.

    Читал 10 лет назад, несколько раз читал, было интересно, но не связывалось с реальной жизнью.
    Но значит, выбор все же был правильный.

    Спасибо за совет! Учту, но на данный момент меня интересуют книги, в которых описано, что такое программирование,
    например, цикл. Что такое императивное, функциональное программирование.

    Имеется ввиду не книги типа Java за полчаса для идиотов, а книги, которые используются
    в курсах связанных с информатикой/computer science.

    Ахо+Ульман?
    Re[5]: Путь к ООП - туда и обратно :)
    От: VGn Россия http://vassilsanych.livejournal.com
    Дата: 23.10.09 09:52
    Оценка:
    J>ООП vs что?

    ООП vs Глупость.
    Имхо лучше:
    ООП feat SQL
    SOA feat ООП
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
    Re[6]: Путь к ООП - туда и обратно :)
    От: metaprogrammer  
    Дата: 24.10.09 11:55
    Оценка:
    Здравствуйте, VGn, Вы писали:

    VGn>ООП vs Глупость.


    Это как "пчёлы против мёда"?
    Re: Путь к ООП
    От: g_i  
    Дата: 26.10.09 14:18
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    "Изучай формулу, но ищи отсутствие формул, слушай беззвучие, изучи всё, затем забудь всё,
    изучи путь, затем ищи свой путь." (c)
    Re[7]: Путь к ООП - туда и обратно :)
    От: VGn Россия http://vassilsanych.livejournal.com
    Дата: 27.10.09 09:16
    Оценка:
    M> Это как "пчёлы против мёда"?

    Придумай другой механизм, позволяющий легко оперировать разными уровнями абстракции в программном коде.
    А то это похоже на "демократия — это плохо, потому что не совершенно".
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1233>>
    Re[4]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 01.11.09 06:33
    Оценка:
    Здравствуйте, Voblin, Вы писали:

    V>Менее радикальный — это "сходить налево" туда, где ООП вообще не применяется. Это не обязательно Нотепад. Это может быть что-то из ФП, это может быть SQL, это может быть VBA или 1С.

    Не надо ля ля. В VBA ООП применяется и еще как, это вполне себе ООП язык . В 1С тоже можно некоторые практики из ООП перенести, хоть и сложнее это будет. SQL — сам язык конечно не ООП даже близко, но базу можно проектировать по ООП принципам. Плюс применять ООП (а также другие подходы) можно для генерации SQL запроса.
    Re[5]: Путь к ООП - туда и обратно :)
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 01.11.09 09:47
    Оценка:
    Здравствуйте, elmal, Вы писали:

    E>Не надо ля ля. В VBA ООП применяется и еще как, это вполне себе ООП язык .


    Оно там конечно применяется, но возможности конструирования объектов там нет, значит говорить об объектной декомпозиции не приходится.

    E> SQL — сам язык конечно не ООП даже близко, но базу можно проектировать по ООП принципам.


    Отличный способ прострелить себе ногу.

    E> Плюс применять ООП (а также другие подходы) можно для генерации SQL запроса.


    Я тебе больше скажу — в ООП стиле можно писать на голом С. Вот только объектно ориентированным С от этого не становится.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1260 on Windows 7 6.1.7600.0>>
    AVK Blog
    Re[8]: Путь к ООП - туда и обратно :)
    От: thesz Россия http://thesz.livejournal.com
    Дата: 02.11.09 03:20
    Оценка:
    Здравствуйте, VGn, Вы писали:

    M>> Это как "пчёлы против мёда"?

    VGn>Придумай другой механизм, позволяющий легко оперировать разными уровнями абстракции в программном коде.

    Теория множеств Цермело-Френкеля.

    Теория типов Мартина-Лёфа.

    VGn>А то это похоже на "демократия — это плохо, потому что не совершенно".


    Демократия — ещё один способ манипулирования. Как и ООП.

    Поэтому они оба плохи.
    Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
    Re[3]: Путь к ООП - туда и обратно :)
    От: Voblin Россия http://maslyaew.narod.ru/
    Дата: 02.11.09 12:00
    Оценка:
    Здравствуйте, rfq, Вы писали:

    rfq>Как раз в большинстве случаев программа если не моделирует, то отображает реальный мир. Вот я набираю текст: в голове моей фраза, я по буковкам переношу ее в программу и программа моделирует мой мозг. Частично, конечно, но больше мне и не надо.

    rfq>Отображение фразы в программе — типичный объект, и философия его проста но никак не слаба: из реального мира поступают сообщения, по ним поддерживать актуальное состояние отображаемого объекта.

    Ага. Зеркало если не моделирует, то отражает мою морду лица.
    Вот я варю борщ. В голове моей желание покушать. Я переношу в кастрюлю свеклу, картошку, морковку, и кастрюля моделирует мой желудок. Частично, конечно, но больше мне и не надо.
    Варка борща в кастрюле — типичный объект, и философия его проста но никак не слаба: из реального мира поступают вода, мясо и овощи, по ним поддерживать актуальное состояние отображаемого объекта (желудка? надеюсь, что не содержимого прямой кишки...). Какая-то тень от листьев хрена необыкновенно хреномутного получается.
    Re[6]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 02.11.09 18:21
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Оно там конечно применяется, но возможности конструирования объектов там нет, значит говорить об объектной декомпозиции не приходится.

    Как это нет? Оператор new есть. Инкапсуляция есть в полном объеме, полиморфизм тоже достаточно неплох. С наследованием хуже дела обстоят, но без него вполне можно обойтись, а где надо — эмулировать.

    E>> SQL — сам язык конечно не ООП даже близко, но базу можно проектировать по ООП принципам.

    AVK>Отличный способ прострелить себе ногу.
    Во всех крупных проектах, где я учавствовал и учавствую, база и была спроектирована по ООП принципам. Нареканий никаких, одна выгода.

    AVK>Я тебе больше скажу — в ООП стиле можно писать на голом С. Вот только объектно ориентированным С от этого не становится.

    Ну это да. Я в свое время читал книгу — ООП на ассемблере, очень много интересного подчерпнул .
    Re[7]: Путь к ООП - туда и обратно :)
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 02.11.09 19:50
    Оценка:
    Здравствуйте, elmal, Вы писали:

    AVK>>Оно там конечно применяется, но возможности конструирования объектов там нет, значит говорить об объектной декомпозиции не приходится.

    E>Как это нет? Оператор new есть.

    Речь о конструировании типов. Если его нет (а его нет), то нет и ОО декомпозиции, а значит и говорить об ООП не приходится.

    AVK>>Отличный способ прострелить себе ногу.

    E>Во всех крупных проектах, где я учавствовал и учавствую, база и была спроектирована по ООП принципам.

    Угу, я знаю что 70% проектов неуспешны, а те что успешны на 2/3 хромают на обе ноги. Но миллионы леммингов не могут ошибаться.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1260 on Windows 7 6.1.7600.0>>
    AVK Blog
    Re[8]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 03.11.09 04:34
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Речь о конструировании типов. Если его нет (а его нет), то нет и ОО декомпозиции, а значит и говорить об ООП не приходится.

    Немного не понял, а что ж тогда конструируется оператором new, как не экземпляр определенного типа (класса)? И что тогда описывает Class, как не тип? Если я разбиваю свою предметную область на типы (классы), в них инкапсулирую данные и операции над этими данными — почему это не ОО декомпозиция? То, что среда уродская, и достоточно большим числом классов неудобно оперировать — это мелочи, в конце концов можно на модули еще разбить.
    Re[9]: Путь к ООП - туда и обратно :)
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 03.11.09 05:32
    Оценка:
    Здравствуйте, elmal, Вы писали:
    E>Немного не понял, а что ж тогда конструируется оператором new, как не экземпляр определенного типа (класса)?
    Андрей намекает, что есть существенная разница между конструированием типов и конструированием экземпляров.

    E>И что тогда описывает Class, как не тип?

    А что, в VBA уже можно описать свой Class?

    E>Если я разбиваю свою предметную область на типы (классы), в них инкапсулирую данные и операции над этими данными — почему это не ОО декомпозиция? То, что среда уродская, и достоточно большим числом классов неудобно оперировать — это мелочи, в конце концов можно на модули еще разбить.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re: Путь к ООП
    От: PostGet  
    Дата: 03.11.09 07:13
    Оценка:
    Здравствуйте, jeeist, Вы писали:

    J>Извиняюсь, опять не смог ничего найти, хотя наверно

    J>такая тема уже где-то была.

    J>Заинтересовал вопрос: как лучше освоить ООП?

    J>Точнее — что следует освоить перед этим.

    J>Почему-то мне кажется, что в реальной жизни

    J>все устроено "не по ООП", а объекты могут быть
    J>(или не быть) добавлены к этому.

    J>И программист должен в первую очередь освоить

    J>основы и только потом, если хочет, может добавить ООП.
    J>А если начинать с ООП, ничего хорошего не получится.

    Я прошёл путь от восхищения от ООП до его полного неприятия. Сей-час нахожусь по середине. ООП иногда предлагает красивые и понятные решения проблем дизайна программы. Я так и думаю что правда всегда где-то по середине. Ни одна пародигма только сама по себе не ведёт к успеху.
    Re[10]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 03.11.09 08:37
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Здравствуйте, elmal, Вы писали:

    E>>Немного не понял, а что ж тогда конструируется оператором new, как не экземпляр определенного типа (класса)?
    S>Андрей намекает, что есть существенная разница между конструированием типов и конструированием экземпляров.
    под коструированием экземпляров понимается MyClass object = new MyClass? Такой синтаксис есть, и всегда был. Или проблема в том, что конструктор без параметров? Так делается это через фабричный метод, например так:

    Public Static Function createInstance(param1 As Integer, param2 As Integer) As Class1
        Class1 myclass = New Class1
        ...
        createInstance = myclass
    End Function

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

    E>>И что тогда описывает Class, как не тип?

    S>А что, в VBA уже можно описать свой Class?
    Всегда было можно. Называется это правда Class Module, ключевого слова Class да, в VBA нет. Но по сути Class Module это и есть класс. Да, один Class Module на файл получается, очень неудобно. Но тоже самое, можно конструктор, деструктор задать, можно органичение видимости сделать, и можно new сделать.

    Практически все то, что можно на VB6, можно и на VBA. Код в обе стороны переносится на ура.
    Re[11]: Путь к ООП - туда и обратно :)
    От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
    Дата: 03.11.09 09:00
    Оценка:
    Здравствуйте, elmal, Вы писали:
    E>под коструированием экземпляров понимается MyClass object = new MyClass? Такой синтаксис есть, и всегда был.
    Да.

    E>Всегда было можно. Называется это правда Class Module, ключевого слова Class да, в VBA нет. Но по сути Class Module это и есть класс. Да, один Class Module на файл получается, очень неудобно. Но тоже самое, можно конструктор, деструктор задать, можно органичение видимости сделать, и можно new сделать.

    Хм. Что-то не получается у меня это сделать. Как создать экземпляр этого "Class Module"? Точнее, у меня это валится прямо на строчке c = New Class1.

    E>Практически все то, что можно на VB6, можно и на VBA. Код в обе стороны переносится на ура.
    ... << RSDN@Home 1.2.0 alpha rev. 677>>
    Уйдемте отсюда, Румата! У вас слишком богатые погреба.
    http://rsdn.org/File/5743/rsdnaddict.GIF
    Re[12]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 03.11.09 09:16
    Оценка:
    Здравствуйте, Sinclair, Вы писали:

    S>Хм. Что-то не получается у меня это сделать. Как создать экземпляр этого "Class Module"? Точнее, у меня это валится прямо на строчке c = New Class1.

    Так я ж написал — MyClass object = new MyClass. Конструктор только как public надо объявить
    Re[13]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 03.11.09 09:46
    Оценка:
    Здравствуйте, elmal, Вы писали:

    E>Так я ж написал — MyClass object = new MyClass. Конструктор только как public надо объявить

    Только что прогнал, у меня работало. По умолчанию да, валилось на этой строчке так как конструктор приватный генерился по умолчанию. Я аж удивился, думал что правдо нельзя стало, и я наврал
    Re[9]: Путь к ООП - туда и обратно :)
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 04.11.09 12:53
    Оценка:
    Здравствуйте, elmal, Вы писали:

    E>Немного не понял, а что ж тогда конструируется оператором new, как не экземпляр определенного типа (класса)?


    Я жирным ключевое слово пометил.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1260 on Windows 7 6.1.7600.0>>
    AVK Blog
    Re[10]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 04.11.09 13:05
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    E>>Немного не понял, а что ж тогда конструируется оператором new, как не экземпляр определенного типа (класса)?

    AVK>Я жирным ключевое слово пометил.
    Что-то я не понимаю. Объект всегда был экземпляром класса, нет?
    Myclass instance1 = New Myclass
    Myclass instance2 = New Myclass

    Myclass в данном случае — мой сконструированный тип. instance1, instance2 — экземпляры моего собственного сконструированного типа.

    Речь шла изначально про конструирование типов, якобы в VBA этого нет. А что тогда Class Module, как не собственный тип?
    Re[11]: Путь к ООП - туда и обратно :)
    От: AndrewVK Россия http://blogs.rsdn.org/avk
    Дата: 04.11.09 13:08
    Оценка:
    Здравствуйте, elmal, Вы писали:

    E>Myclass в данном случае — мой сконструированный тип. instance1, instance2 — экземпляры моего собственного сконструированного типа.


    Class module все таки немножко не класс.
    ... << RSDN@Home 1.2.0 alpha 4 rev. 1260 on Windows 7 6.1.7600.0>>
    AVK Blog
    Re[12]: Путь к ООП - туда и обратно :)
    От: elmal  
    Дата: 04.11.09 13:17
    Оценка:
    Здравствуйте, AndrewVK, Вы писали:

    AVK>Class module все таки немножко не класс.

    А какие отличия? Я в свое время без проблем конвертил VBA проекты в VB6 проекты и наоборот. Работало. Единственные отличия заметил, что VBA работает шустрее, я очень удивился . Class в VB6 классом надеюсь является? А класс в VBScript?
     
    Подождите ...
    Wait...
    Пока на собственное сообщение не было ответов, его можно удалить.