Re[2]: Путь к ООП
От: jeeist  
Дата: 22.09.09 13:16
Оценка:
Здравствуйте, eaa, Вы писали:

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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


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

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[2]: Путь к ООП
От: igna Россия  
Дата: 23.09.09 05:52
Оценка:
Здравствуйте, rlabs, Вы писали:

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


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


Рассуждения на уровне "космонавты летали в космос и видели, что никакого бога нет", а также "если бога нет, то кто же создал мир" и.т.п.
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”). Если перевести этот тезис на язык «дров» и «камней», то это будет звучать, примерно, так. Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.
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[2]: ИМХО, главное ограничение ООП
От: jeeist  
Дата: 23.09.09 09:19
Оценка: 1 (1)
У меня такой вопрос: если речь идет о конкретном человеке.

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

Мне лично такой подход кажется разумным.
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>Время на его изучение лучше потратить на изучение других вещей, более полезных.


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