mes,

>а терь можно узнать пару тройку фактов почему ? 

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

Доброе утро.

Про IT в образовании вообще отдельный вопрос, по крайней мере в этой стране.

п.с. Я за процедурное программирование и функциональный подход.

А власти скрывают!


"C с классами и наследованием" реализует все три основополагающих принципа ООП, которые вбивают в мозг студентам айтишных специальностей. Хочешь мастдайнуть собственные приёмы программирования?


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


И что плохого в использовании ООП подхода в программировании?

инкапсуляция, полиморфизм и наследование хороши как концепции
какая разница, какой язык, есть там классы или нет?

пример
ядро linux - сплошное ООП и выглядит это все логично, красиво, расширяемо
мне достаточно

Пост был пропатчен. Shaggie, заголовок лишь для провокации флейма. Это ж раздел с холиворами!

Добавлено через 11 минут и 54 секунды
А, забыл. Православный ООП - это тот, что отписан в bluebook (это тот блюбук, который про смолток 80).

Главное, чтобы ООП не лишали здравого смысла как например это сделли в С#. Вот какого фига оттуда убрали локальные функции? Почему они в Делфи есть а в С# нет? В результате приходится подпрограммы выносить на уровни метода, а это логический ###.

Это сообщение отредактировал(а) Vex - 28.9.2010, 10:15

Зато в Nemerle есть локальные функции   

A5uKa, 


я про него прочитал это какой-то рак мозга )

Добавлено через 39 секунд
а в джаве тоже нет локальных функций?

Почему ?

djamshud, ИМХО, не надо было капитально редактировать первый пост, лучше бы накатал масштабный ответ и дал с первого поста ссылку на него, а то и вправду вся тема поехала.



Инкапсуляция на низком уровне - это способ скрыть низкоуровневые детали реализации, предоставив базовый API собственным модулям с тем, чтобы можно было легко менять нужный слой приложения при переходе с одной платформы/библиотеки на другую.


   А есть ссылочка, где бы можно было про неестественность инкапсуляции высоких материй почитать?
Любой слой приложения имеет в подчинении совокупность интерфейсов низлежащего слоя, владение ими и порядок вызовов имеет смысл инкапсулировать в объекте, предоставив набор методов наружу. Даже будь это самый-самый высокий уровень, всё равно надо спрятать детали в вызове application.execute(), спрятав потроха.


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


Можно и без ООП с успехом запороть повторное использование. Лично моё мнение такое, что reuse кода и подход к программированию вообще слабо друг с другом коррелируют.


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


Дальше прекрасное:

Отлично, значит C по умолчанию ООП язык   


Библиотека контейнеров прекрасно пишется труъ-функциональным способом, ни капли не теряя в удобстве использования. К чему лишнее использование ООП, если оно тебе не нравится?


О, таки при работе над крупной задачей преимущество ООП внезапно было осознанно!


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

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

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

Shaggie,

>Инкапсуляция на низком уровне - это способ скрыть низкоуровневые детали реализации, предоставив базовый API собственным модулям с тем, чтобы можно было легко менять нужный слой приложения при переходе с одной платформы/библиотеки на другую.

Ну и каким боком тут инкапсуляция вообще? Инкапсуляция != скрытие. Мы написали функцию, в ней низкоуровневая реализация. Что куда и с чем инкапсулировалось? Или мы будем называть инкапсуляцией написание любой процедуры?

>А есть ссылочка, где бы можно было про неестественность инкапсуляции высоких материй почитать?

Это мое имхо. Могу дать ссылку на первый пост:)

>Даже будь это самый-самый высокий уровень, всё равно надо спрятать детали в вызове application.execute(), спрятав потроха.

Какие еще потроха у высоких то материй?! На этом уровне занимаются спариванием сферических коней в вакууме.

>Похоже, в команде программировать не приходилось?

Как раз таки приходилось. И как раз таки убедился в полной непригодности black box-ов. Потому что иногда нужны перламутровые пуговицы. Отныне максимум - защита от дурака, т.е. protected на языке С++ и никаких private.

>Можно и без ООП с успехом запороть повторное использование.

ООП предоставляет куда больше возможностей в этом плане!

>Отлично, значит C по умолчанию ООП язык

Интересный вывод. "C с классами" - это C++, в котором максимум используется class для инкапсуляции.

>Библиотека контейнеров прекрасно пишется труъ-функциональным способом, ни капли не теряя в удобстве использования. К чему лишнее использование ООП, если оно тебе не нравится?

Так как она писалась для использования в C и C++ проектах, использовать труъ-способ - это как вырывать гланды через жопу.

>О, таки при работе над крупной задачей преимущество ООП внезапно было осознанно!

Это вовсе не крупный проект. Пара тысяч строк. И как я писал, ООП там используется в основном для реализации dataflow и интерфейса к нему.

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

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

 внимательный просмотр паттернов позволит понять, что
1. многие из ООП патернов применимы также и во многих других концепциях. например Делегат, Стратегия, Контроллер, Итератор..
2. некоторые паттерны в ООП реализованы как средства языка и поэтому фактически не могут быть ООП-патернами, например: Полиморфизм, Наследование
3. есть паттерны определяющие архитектуру устройства:
плагин, сервер/клиент 
4. паттерны взаимодействия и обмена данных
точка-точка/ точка-звезда, удаленный вызов, база данных, файловая ситема
.
..
... и т.д.
(возможно в высшесказонном есть мелкие недочеты, но неохото напрягать голову сейчас.. главное суть в том, что паттерн это не технология ООП, а технология, которую можно выделить и описать)

Добавлено через 1 минуту и 30 секунд

но статические же методы оставили ?!.. так вроде там и статические классы даже есть..



Это сообщение отредактировал(а) mes - 28.9.2010, 20:20

Ну так это не проблема инкапсуляции, а кривых рук... 





имхо повторное использование к этой теме вообще отношения не имеет.. 


имелся ввиду процедурный стиль ?


некоторое удобство теряется из за незнания контейнера как управлять жизнью объекта и создавать копии..


нет. Инкапсуляцией прежде всего называется сокрытие данных, а не сокрытие процедур. 
Вобщем для начала неплохо было бы ознакомиться с АТД и понять его суть и преимущества.. 


нда.. как связаны black box и перламутровые пуговицы.
интересно насколько по Вашему быстрее и удобнее была бы работа, если бы поле m_size  у string было бы public.. 


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



не понятно о чем тут.. 


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


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

Добавлено @ 21:07

вот на С++



Это сообщение отредактировал(а) mes - 28.9.2010, 21:08