Здравствуйте, jeeist, Вы писали:
J>Здравствуйте, thesz, Вы писали:
T>>Я повторюсь, что. с моей точки зрения, ООП предлагает неестественную логику для описания предметной области. Поэтому если ты до сих пор обходился без него, попытайся и дальше обходиться без него.
T>>Время на его изучение лучше потратить на изучение других вещей, более полезных.
J>Я бы с удовольствием, но создается впечатление, что во всех серьезных проектах J>используют ООП и что скоро понятие программирование будет включать ООП (источник — J>Спольский или Макконнелл)
Не стоит так думать.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, 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>Или же человек не понимает чего-то элементарного и вопрос — как лучше освоить элементарные вещи.
Теория систем это философия (относительно программирования). В философии определенная польза есть. Но от конкретной работы философия не избавляет.
Здравствуйте, Silver_s, Вы писали:
S_>Здравствуйте, jeeist, Вы писали: J>>Тогда вопрос — есть ли какая-то теория, которая описывает эту тему и которая может помочь понять? J>>Теория систем, например. J>>Или же человек не понимает чего-то элементарного и вопрос — как лучше освоить элементарные вещи.
S_> Теория систем это философия (относительно программирования). В философии определенная польза есть. Но от конкретной работы философия не избавляет.
Теория систем — часть кибернетики, кибернетика != философия.
Здравствуйте, Курилка, Вы писали:
К>Теория систем — часть кибернетики, кибернетика != философия.
И кибернетика тоже философия.
По поводу кибернетики есть даже такое высказывание (профессор какой-то сказал)
в США вы не можете употреблять слово "кибернетика", потому что большое число пустопорожних работ создало впечатление о несерьезности этой теории
Слазил в Wiki, узнать что считают философией, и ожидания оправдались:
Филосо́фия — наиболее общая теория[1], одна из форм мировоззрения, одна из наук[2] одна из форм человеческой деятельности, особый способ познания. Общепринятого определения философии, равно как общепринятого представления о предмете философии, не существует.
Будем считать что у философии есть прикладное ответвление называющееся "Философия программирования" (а не просто написания кода), и оно довольно сильно пересекается и с кибернетикой и с теорией систем.
Здравствуйте, jeeist, Вы писали:
J>Как раз это меня интересует. Мне кажется, что если взгляды на программирование J>основаны исключительно на ООП, то рано или поздно придется все перестраивать.
Если человек умеет пользоваться только молотком, и ни о чём другом слышать не желает, то он никогда нормально не закрутит шуруп.
ООП — это всего лишь одна из техник программирования. Нужно ли ею владеть? Желательно. Можно ли владеть только ООП? Честно говоря, я себе это вообще представить не могу.
J>Самый радикальный подход — это отобрать все, кроме Нотепада и компилятора J>и заставлять писать простые программы без ООП, пока дурь не вылетит из головы J>Или есть другие варианты, менее радикальные? Интересует в основном опыт практического J>применения.
Менее радикальный — это "сходить налево" туда, где ООП вообще не применяется. Это не обязательно Нотепад. Это может быть что-то из ФП, это может быть SQL, это может быть VBA или 1С.
jeeist wrote:
> Заинтересовал вопрос: как лучше освоить ООП? > Точнее — что следует освоить перед этим.
Просто программирование. Обычное. Чтобы понять,
что можно жить и без объектов. Тогда лучше
поймёшь, зачем нужны объекты.
> Почему-то мне кажется, что в реальной жизни > все устроено "не по ООП", а объекты могут быть > (или не быть) добавлены к этому.
Вообще, в начале ООП как раз применялось для
моделирования объектов реального мира.
> И программист должен в первую очередь освоить > основы и только потом, если хочет, может добавить ООП. > А если начинать с ООП, ничего хорошего не получится.
Здравствуйте, craft-brother, Вы писали:
CB>Здесь и зарыто главное ограничение ООП, которое делает наши программы сложнее, чем они могли бы быть. ... "The Liskov Substitution Principle"
Принцип Лискова — вообще бомба. Он говорит нам о том, что:
1. В программировании хвост, виляющий собакой — обычная ситуация. Здесь хвост — это дизайн подсистемы/сервиса, а собака — это дизайн системы.
2. Пока ты в совершенстве не освоил телепатию и не научился путешествовать туда-сюда по времени, ты не можешь считаться хорошим программистом-инструментальщиком. Попытка заменить эти базовые навыки банальной интуицией — всего лишь полумера.
CB>Проектируя программные объекты «дрова» и «камень», мы должны быть в курсе планов Господа, по совершенствованию программной системы. А именно, мы должны предполагать, что Он не ограничится созданием дров и камней, а на шестой день сотворения мира создаст человека, который их будет перетаскивать.
Это, конечно, позволит нам забороть стрёмный принцип Лискова. Но трудности на этом не кончаются. Поняв, что будет создан человек и выяснив, что он собирается делать с этими объектами (носить, поджигать, пилить, растворять в кислоте, грызть, прибивать, нюхать, складывать в штабеля, красить, поклоняться, выращивать, продавать и т.д.), мы начинаем медленно сходить с ума.
Базовая операция, на которой держится весь ООД — это операция обобщения. Если мы не можем нормально обобщить (выделить базовый класс), то большую половину всех вкусностей ООП мы не получаем. С одной стороны, живое дерево и мёртвый камень — принципиально разные объекты, но если судить по тому, что с ними можно делать (необходимый набор интерфейсов), то это почти одно и то же. Как выкручиваться? Известно как:
1. Создать оччччччччень толстый базовый класс CObject, в который напихать уйму свойств и виртуальных методов. А потом, понять, что жизнь наша от этого не облегчилась. И удивляться, почему всё так страшно тормозит и почему оперативка забилась таблицами виртуальных методов.
2. Применить какой-нибудь выверт типа множественного наследования или интерфейсного подхода. То есть вместо того, чтобы пройти по скользкой, опасной и длинной дороге обобщения один раз, мы будем ходить по множеству коротких, но от этого не менее скользких и опасных.
Кроме того, есть ещё одна тонкая проблема, которая мешает легко и радостно применять ООД. Это проблема выделения объектов из предметной области. Что считать объектом? Деревяшку? Камень? ОК. А деревяшку, приклеенную к другой деревяшке будем считать объектом? Куча камней — это объект? Куча мусора, в которой есть и камни, и деревяшки — это объект? Подгнивший краешек доски — это отдельный объект или как? Нарисованный камень, абстрактный камень, "что-то непонятное, торчащее из земли"???
Философская подоплёка этой проблемы заключается в том, что в реальном мире не существует объектов. То, что мы воспринимаем как "объекты", носим с места на место, поджигаем, пилим, растворяем в кислоте, грызём и т.п. никакой объектной сущностью не обладает. Деление мира на объекты — это особенности вычислительной модели, на которой основана работа устройства, расположенного у нас между ушами. Мы произвольно можем выделять объекты так, как нам это удобно. Логика — нечёткая. Сегодня я любуюсь камнем, а завтра — фотографией этого камня, и для меня это один и тот же объект. Компутер так не может. У него чёткая логика. У него однозначные интерпретации (а все неоднозначности — это либо ошибка программы, либо ошибка пользователя, но в любом случае мы с неоднозначностями предпочитаем бороться).
Вот и получается, что пока программа работает с простыми (желательно искусственными) сущностями типа элементов оконного интерфейса, ООП полезен и показывает себя с хорошей стороны. Как только сложность возрастает, ООП становится обузой.
Мораль? Простая. Объекты, классы, шаблоны, фабрики, интерфейсы и прочее зверьё — это инструменты решения задач. Никакого сакрального смысла в них нет. Если упрощают жизнь — пользуем, если усложняют — не пользуем.
Здравствуйте, Voblin, Вы писали:
V>Здравствуйте, jeeist, Вы писали:
J>>Самый радикальный подход — это отобрать все, кроме Нотепада и компилятора J>>и заставлять писать простые программы без ООП, пока дурь не вылетит из головы J>>Или есть другие варианты, менее радикальные? Интересует в основном опыт практического J>>применения.
V>Менее радикальный — это "сходить налево" туда, где ООП вообще не применяется. Это не обязательно Нотепад. Это может быть что-то из ФП, это может быть SQL, это может быть VBA или 1С.
Но хотелось бы делать то же самое, но по другому
Кстати — что было до этого? Помню, 15 лет назад читал учебники, но не помню,
что являлось тогда "серебряной пулей" — структурное или процедуральное программирование.
А также — что является альтернативой для ООП — декларативное, в т.ч.
функциональное программирование?
Т.е. Microsoft vs Apple, PepsiCola vs CocaCola, ООП vs что?
Здравствуйте, jeeist, Вы писали:
J>Кстати — что было до этого? Помню, 15 лет назад читал учебники, но не помню, J>что являлось тогда "серебряной пулей" — структурное или процедуральное программирование.
Копать нужно глубже. 15 лет назад народ (и я в том числе) уже вовсю фанател с ООП.
А лет 30 назад в мэйнстриме было именно структурное программирование. Ну и, естественно, применение ЯВУ было чрезвычайно модной фишкой.
J>А также — что является альтернативой для ООП — декларативное, в т.ч. J>функциональное программирование?
Не очень правильная постановка вопроса. Одно не исключает другое, и поэтому конкуренции нет. По крайней мере в своей голове я её не наблюдаю.
В одну и ту же программу можно напихать и объектно-, и функционально-, и компонентно-, и аспектно-, и ещё всяко разно ориентированных подходов так, что служба сопровождения с ума сойдёт
Короче, если отвёрткой шуруп не закручивается, а применять молоток — глупо, берём кувалду, и заходит он как миленький
Если интересно, что придёт на смену ООП, то правильный ответ — "ничего". Точно так же, как ООП не заменило структурное программирование, а лишь добавило инструментов и концепций, так и следующие модные фишки, думаю, будут добавлять, а не подменять.
Здравствуйте, Voblin, Вы писали:
V>Копать нужно глубже. 15 лет назад народ (и я в том числе) уже вовсю фанател с ООП.
Точно. И многие пинали необъектное программирование. Теперь точно так же рассказывают про то, что ООП ни на что не годен, а серебряная пуля это уже что то другое. Например ФП.
... << RSDN@Home 1.2.0 alpha 4 rev. 1237 on Windows 7 6.1.7100.0>>
Здравствуйте, AndrewVK, Вы писали:
V>>Копать нужно глубже. 15 лет назад народ (и я в том числе) уже вовсю фанател с ООП. AVK>Точно. И многие пинали необъектное программирование.
Эх, славные были времена. Где те TurboVision-ы и DBVist-ы, с которых все пёрлись?
AVK>Теперь точно так же рассказывают про то, что ООП ни на что не годен, а серебряная пуля это уже что то другое. Например ФП.
Страстные натуры всегда так — сначала приходят в дикий восторг, а потом... горькое разочарование в обманутых надеждах. Но можно и по-другому: по-прежнему приходить в дикий восторг и прыгать от радости, но где-нибудь в глубине сознания заранее зацепить, что новый объект страсти тоже не идеален т.к. "серебряных пуль" не бывает. А те, которые бывают, как правило для употребления вообще не пригодны.
Здравствуйте, AndrewVK, Вы писали:
AVK>Точно. И многие пинали необъектное программирование. Теперь точно так же рассказывают про то, что ООП ни на что не годен, а серебряная пуля это уже что то другое. Например ФП.
А некоторые считают, что если пепельница забилась, то нужно менять машину.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Это подобное мышление ущербно.
Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации. Т.е. тебе придется при разработке программы отвечать на вопрос "Что делать" (последовательность действий) и "Зачем делать" (логика). ООП и стиль "евоный" отвечает на вопрос "Как делать", как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...
Здравствуйте, denisko, Вы писали:
D>Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации.
Об этом разного рода мечтатели мечтают с того момента, когда я начал программировать. А это больше двадцати лет. И будут мечтать как минимум до тех пор, пока я не перестану программировать. А это ещё минимум двадцать лет.
D>Т.е. тебе придется при разработке программы отвечать на вопрос "Что делать" (последовательность действий) и "Зачем делать" (логика). ООП и стиль "евоный" отвечает на вопрос "Как делать", как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...
Ты путаешь императив и ООП.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, denisko, Вы писали:
D>>Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации.
IT>Об этом разного рода мечтатели мечтают с того момента, когда я начал программировать. А это больше двадцати лет. И будут мечтать как минимум до тех пор, пока я не перестану программировать. А это ещё минимум двадцать лет.
Думаю это было ещё до того момента
Имхо как раз из подобных соображений придумывались в том числе SQL, а до него COBOL. Ну а последнему полвека на днях исполняется
Здравствуйте, Курилка, Вы писали:
D>>>Так всегда говорили защитники старого стиля Просто подумай -- все идет к тому,что практически все рутинные операции реализуются в качестве библиотечных функций, поэтому довольно вероятно, что скоро твоя работа сведется к организации логики программы (последовательности действий) + 1% ковыряния на низком уровне при оптимизации.
IT>>Об этом разного рода мечтатели мечтают с того момента, когда я начал программировать. А это больше двадцати лет. И будут мечтать как минимум до тех пор, пока я не перестану программировать. А это ещё минимум двадцать лет.
К>Думаю это было ещё до того момента
Того момента я ещё не застал.
К>Имхо как раз из подобных соображений придумывались в том числе SQL, а до него COBOL. Ну а последнему полвека на днях исполняется
Кстати, SQL по логике denisko тоже должен умереть. В нём же при дизайне БД надо отвечать на вопросы 'как организовать структуру, чтобы все объекты дружили, как выстроить их иерархию, как, как,как ... Куча как...'
Если нам не помогут, то мы тоже никого не пощадим.
горькое разочарование в обманутых надеждах. Но можно и по-другому: по-прежнему приходить в дикий восторг и прыгать от радости, но где-нибудь в глубине сознания заранее зацепить, что новый объект страсти тоже не идеален т.к. "серебряных пуль" не бывает. А те, которые бывают, как правило для употребления вообще не пригодны.
Если нам не помогут, то мы тоже никого не пощадим.
