Форум программистов, компьютерный форум, киберфорум
ООП и паттерны
Войти
Регистрация
Восстановить пароль
Блоги Сообщество Поиск  
 
 
Рейтинг 4.53/90: Рейтинг темы: голосов - 90, средняя оценка - 4.53
 Аватар для tramp_1-3
16 / 16 / 1
Регистрация: 13.10.2012
Сообщений: 454

Недостатки ООП

16.05.2014, 16:35. Показов 22249. Ответов 318
Метки нет (Все метки)

Студворк — интернет-сервис помощи студентам
Задали написать небольшую статью о недостатках этой замечательной парадигмы. В нашей группе прикладной информатики я один более-менее знаком с разработкой, поэтому на придирчивость аудитории можно не рассчитывать, и я решил спросить мнение опытных людей здесь. Я самоучка-теоретик, так и не написавший более-менее достой программы за свою жизнь, поэтому часть этой статьи навеяна из сети, а вот про усложнения - уже исключительной мой загон - не могу просто взять и написать программу. Пишу, думая, что это будет целый Фреймворк. Ну в общем предлагаю вашему вниманию эту коротенькую статью и рассчитываю на объективную критику. Всего полторы страницы - больше просто не знаю к чему придраться.
https://www.dropbox.com/s/m6u9... D0%9F.docx
дропбокс глючит и не дает нормальную ссылку. вот статья под спойлером.
Кликните здесь для просмотра всего текста
Недостатки ООП
Парадима ООП не нова. ООП приобрело популярность во второй половине 80-х вместе с такими языками, как Smalltalk, С++, Objective C (другое расширение C) и некоторыми другими. 25 лет назад никто не ожидал, что “новый” феномен ООП проживет столь долго и сегодня большинство современных языков поддерживают эту парадигму.
ООП стоит на трёх китах:
1.Первый — инкапсуляция — это определение классов — пользовательских типов данных, объединяющих своё содержимое в единый тип и реализующих некоторые операции или методы над ним. Классы обычно являются основой модульности, инкапсуляции и абстракции данных в языках ООП.
2.Второй — наследование — способ определения нового типа, когда новый тип наследует элементы (свойства и методы) существующего, модифицируя или расширяя их. Это способствует выражению специализации и генерализации.
3.Третий, известный как полиморфизм, позволяет единообразно ссылаться на объекты различных классов (обычно внутри некоторой иерархии). Это делает классы ещё удобнее и облегчает расширение и поддержку программ, основанных на них.
Инкапсуляция, наследование и полиморфизм — фундаментальные свойства, которыми должен обладать язык, претендующий называться объектно-ориентированным (языки, не имеющие наследования и полиморфизма, но имеющие только классы, обычно называются основанными на классах). Различные ОО языки используют совершенно разные подходы. Мы можем различать ОО языки, сравнивая механизм контроля типов, способность поддерживать различные программные модели и то, какие объектные модели они поддерживают.
Преимущества этих языков всем известны: повторное использование кода, упрощение разработки больших программ, более логичная структура программы и многие другие. Разберём некоторые недостатки.
Недостатки есть абсолютно у всего – с этим нужно просто смириться. Важно адекватно их оценивать и стараться минимизировать их влияние. То же самое касается и объектно-ориентированной парадигмы программирования.
Есть несколько причин, почему узкие места ООП часто вылазят наружу. Я считаю, что это прежде всего непонимание самой сути объектно-ориентированной техники программирования - восприятие этой парадигмы как серебряной пули. Часто программисты стараются решать абсолютно все задачи, где даже не предвидится конкретных сущностей с их свойствами с помощью объектов, наследования и с помощью объектов. Это очень усложняет процесс. То есть вместо написания парочки функций в процедурной манере и передачи аргументов туда-обратно, программист часто пытается нагромоздить целую иерархию классов и после разгребает проблемы с видимостью классов, доступа к скрытым инкапсуляцией данным.
Таким образом, можно выделить один недостаток объектно-ориентированных языков программирования – избыточность их средств при решении большинства простых задач.
Нужно помнить, что применение ООП это прежде всего моделирование. Для построения хорошей, легко читаемой и сопровождаемой программы необходимо в самом начале разработки предусмотреть сценарии её использования и, что очень важно, изменения – заказчик легко в корне может поменять задачу. Это нетривиальный процесс, в котором часто задействуются даже отдельные языки моделирования. Не каждый способен выделить отдельные сущности и сделать их классами. Ещё меньше людей способны адекватно распределить функции, работающие с данными программы в методы и упаковать их в классы. Для этого нужно уметь мыслить объектно-ориентированными категориями. На всё это уходит драгоценное время. Оно обязательно окупится, если программист имеет дело с большим и сложным проектом, но вряд ли в других случаях, когда требуется просто решить задачу и перейти к другой.
Для меня вывод один, всем известный и общепринятый – не стоит воспринимать парадигмы и языки, их поддерживающие, как божество. Это всего лишь инструмент для решения определенного круга задач. Я думаю, что для объектно-ориентированных языков такие задачи начинаются, когда их решение укладывается более чем в тысячу строк и задачи, которые требуют масштабирования.
“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп
0
IT_Exp
Эксперт
34794 / 4073 / 2104
Регистрация: 17.06.2006
Сообщений: 32,602
Блог
16.05.2014, 16:35
Ответы с готовыми решениями:

Архитектура с толстым клиентом: какие есть недостатки?
Здравствуйте, коллеги! Сейчас разрабатываем простенькое веб-приложение для учета заказов производственной компании. Функционал несложный:...

ООП ради ООП
Доброго времени суток! Есть к примеру класс Cat который реализует интерфейс Movable, инкапсулирует цвет, и прочее. Имеет ли смысл...

Изучаю Python, сейчас учу основы ООП, где можно найти задачи по ООП
Скиньте пожалуйста источники с задачами(желательно на русском)

318
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 10:25
Студворк — интернет-сервис помощи студентам
Почитал статьи противников ООП по приведенным ссылкам. Их аргументы крайне неубедительны и очень часто просто глупы.
Вообще-то процедурные языки мне кажутся тоже объектно ориентированными, только единственный объект, на который они ориентированы – это компьютерный процессор, и единственная модель, которую они реализуют, - это «процессор, обрабатывающий данные». В то время как в ООП-программе создается язык, описывающий систему, для которой решается задача.
А ведь язык определяет мышление. Поэтому у программиста, представляющего себя компьютерным процессором, просто не появятся те мысли, которые возникнут у человека, смоделировавшего систему решаемой задачи.
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,117
Записей в блоге: 2
08.06.2014, 12:04
Цитата Сообщение от Mr.X Посмотреть сообщение
В то время как в ООП-программе создается язык, описывающий систему, для которой решается задача.
Ну языком это можно назвать с большой натяжкой. А главное - не "создается" а "используется", сила ООП часто сводится к использованию мощных тулзов. Начните городить свои классы с нуля - далеко не уедете и особых преимуществ по сравнению с "процедурщиком" не получите. Но вот когда std или boost или Qt - тогда совсем др дело
0
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
08.06.2014, 12:50
Цитата Сообщение от Mr.X Посмотреть сообщение
В то время как в ООП-программе создается язык, описывающий систему, для которой решается задача.
Язык, описывающий систему, для которой решается задача называется DSL. Никакого отношения DSL к ООП не имеет. Сами по себе ООП языки не являются достаточно выразительными средствами для описания систем.

Добавлено через 23 минуты
Цитата Сообщение от Mr.X Посмотреть сообщение
А ведь язык определяет мышление. Поэтому у программиста, представляющего себя компьютерным процессором, просто не появятся те мысли, которые возникнут у человека, смоделировавшего систему решаемой задачи
И это иногда даже хорошо. Почемуто ООПшники считают, что их способ мышлений единственно правильный. Но как показывает практика и даже этот раздел форума, это далеко не так и их решения могут быть громоздки, ужасны, неподерживаемы и не расширяемы. Но при этом они все равно как мантру повторяют, что ООП их бог.
Кликните здесь для просмотра всего текста
В этой штуке http://www.gnu.org/fun/jokes/helloworld.html шуток нет.
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 13:47
Цитата Сообщение от Igor3D Посмотреть сообщение
Ну языком это можно назвать с большой натяжкой
Как это? Если мы смоделировали все объекты интересующей нас системы и все взаимодействия между ними, то можем описать любое состояние и поведение системы. Что ж это, по-вашему, как не язык?

Добавлено через 10 минут
Цитата Сообщение от Igor3D Посмотреть сообщение
А главное - не "создается" а "используется", сила ООП часто сводится к использованию мощных тулзов. Начните городить свои классы с нуля - далеко не уедете и особых преимуществ по сравнению с "процедурщиком" не получите.
Да нет, каждый раз, решая с помощью ООП новую задачу, мы создаем для этого новый язык, описывающий именно эту систему и никакую другую, разумеется, складывая наши классы, как из кирпичиков, из уже готовых стандартных компонентов.

Добавлено через 20 минут
Цитата Сообщение от pycture Посмотреть сообщение
Язык, описывающий систему, для которой решается задача называется DSL
Ну, это вы спутали немножко. DSL - это такой же, но созданный для моделирования систем одного конкретного типа:
• TeX/LaTeX для подготовки (компьютерной вёрстки) текстовых документов;
• Perl для манипулирования текстами;
• SQL для СУБД;
• Tcl/Tk для графического интерфейса пользователя;
• HTML и SGML для разметки документов;

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

Добавлено через 6 минут
Цитата Сообщение от pycture Посмотреть сообщение
Сами по себе ООП языки не являются достаточно выразительными средствами для описания систем.
С чего бы это? Вообще-то они именно для этого и предназначены. И из всех языков общего назначения наиболее для этого подходят.
1
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
08.06.2014, 14:50
Цитата Сообщение от Mr.X Посмотреть сообщение
И из всех языков общего назначения наиболее для этого подходят.
Доказательство в студию.
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 15:50
Цитата Сообщение от korvin_ Посмотреть сообщение
Доказательство в студию.
Разовью свою мысль.
В реальном мире все большие и сложные системы устроены примерно одинаково. Они состоят из довольно однотипных сложных подсистем, которые инкапсулируют свою сложность внутри, а друг с другом обмениваются довольно простыми сигналами.
Например, муравейник состоит из муравьев, довольно однотипных, но имеющих подвиды: рабочие, солдаты, самцы, матка. Это описывается с помощью наследования этих классов от класса «муравей». Каждый муравей инкапсулирует свою сложность внутри, а с другими муравьями обменивается простыми сигналами. Это отражается инкупсуляцией. Каждый муравей реагирует на сигнал, посланный ему другим муравьем, но разные подвиды могут реагировать по-разному – это описывается с помощью полиморфизма. Т.е. в ОО-языке есть всё для моделирования именно больших и сложных систем, т.е. для преодоления сложности как описываемой системы, так и самой программы, чего без ООП добиться трудно или невозможно.
0
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
08.06.2014, 16:12
Цитата Сообщение от Mr.X Посмотреть сообщение
В реальном мире все большие и сложные системы устроены примерно одинаково. Они состоят из довольно однотипных сложных подсистем, которые инкапсулируют свою сложность внутри, а друг с другом обмениваются довольно простыми сигналами.
Например, муравейник состоит из муравьев, довольно однотипных, но имеющих подвиды: рабочие, солдаты, самцы, матка. Это описывается с помощью наследования этих классов от класса «муравей». Каждый муравей инкапсулирует свою сложность внутри, а с другими муравьями обменивается простыми сигналами. Это отражается инкупсуляцией. Каждый муравей реагирует на сигнал, посланный ему другим муравьем, но разные подвиды могут реагировать по-разному – это описывается с помощью полиморфизма. Т.е. в ОО-языке есть всё для моделирования именно больших и сложных систем, т.е. для преодоления сложности как описываемой системы, так и самой программы, чего без ООП добиться трудно или невозможно.
Это всего лишь абстракция, можно опуститься еще ниже, до элементарных частиц, у которых нет внутреннего устройства и никакого необходимости в наследовании не существует. Причем эти самые элементы существуют и взаимодействуют друг с другом конкурентно (во времени), что ООП само по себе не особо учитывает (во всяком случае традиционные модели). Кроме того взаимодействий всего 4 вида, поэтому куча методов нам не нужна, опять наследование мимо кассы. Ну а позднее связывание (динамическая диспетчеризация методов) — это всего лишь вызов нужного метода из таблицы, что делается элементарно в любом процедурном языке без необходимости введения специальных синтаксических плюшек для описания методов.
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 16:25
Цитата Сообщение от korvin_ Посмотреть сообщение
Это всего лишь абстракция, можно опуститься еще ниже, до элементарных частиц, у которых нет внутреннего устройства и никакого необходимости в наследовании не существует.
Если вы опуститесь еще ниже, то это будет описание системы элементарных частиц, а не муравейника. В абстракции-то и сила. Речь идет именно об описании сложных систем, у которых и подсистемы сложные. И каким это интересно образом вы собираетесь из множества объектов-элементарных частиц смоделировать поведение муравейника?
0
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
08.06.2014, 16:43
Цитата Сообщение от Mr.X Посмотреть сообщение
Если вы опуститесь еще ниже, то это будет описание системы элементарных частиц, а не муравейника. В абстракции-то и сила. Речь идет именно об описании сложных систем, у которых и подсистемы сложные. И каким это интересно образом вы собираетесь из множества объектов-элементарных частиц смоделировать поведение муравейника?
А зачем мне моделировать муравейник? Ты (как и большинство ООПшников) со своим примером упускаешь одну важную вещь — далеко не всем нужно моделировать муравейник, далеко не всем нужны сложные системы, далеко не все системы хорошо ложатся на ОО-модель.
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 17:02
Цитата Сообщение от korvin_ Посмотреть сообщение
А зачем мне моделировать муравейник? Ты (как и большинство ООПшников) со своим примером упускаешь одну важную вещь — далеко не всем нужно моделировать муравейник, далеко не всем нужны сложные системы, далеко не все системы хорошо ложатся на ОО-модель.
Все это справедливо, но с ростом быстродействия компьютеров и объема их памяти программы и описываемые ими системы поневоле стали сложными, и эффективным инструментом преодоления этой сложности и является ООП.
0
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
08.06.2014, 17:40
Цитата Сообщение от Mr.X Посмотреть сообщение
но с ростом быстродействия компьютеров и объема их памяти программы и описываемые ими системы поневоле стали сложными
Это слишком бескомпромиссное, обощенное и однобокое утверждение, чтобы его можно было принять за истину.
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 17:48
Цитата Сообщение от korvin_ Посмотреть сообщение
Цитата Сообщение от Mr.X
но с ростом быстродействия компьютеров и объема их памяти программы и описываемые ими системы поневоле стали сложными

Это слишком бескомпромиссное, обощенное и однобокое утверждение, чтобы его можно было принять за истину.
Ну почему же? Если компьютер способен решить какую-то задачу, то ему ее и поручают. На этом вот этапе процедурное программирование отстало в своих возможностях от железа. ООП восстановило равновесие.
0
Эксперт функциональных языков программированияЭксперт Java
 Аватар для korvin_
4576 / 2775 / 491
Регистрация: 28.04.2012
Сообщений: 8,782
08.06.2014, 18:08
Цитата Сообщение от Mr.X Посмотреть сообщение
На этом вот этапе процедурное программирование отстало в своих возможностях от железа. ООП восстановило равновесие.
В смысле отстало в возможности нагружать железо ненужным хламом? Да, тут у ООП нет равных.
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 18:19
Цитата Сообщение от korvin_ Посмотреть сообщение
В смысле отстало в возможности нагружать железо ненужным хламом? Да, тут у ООП нет равных.
Цитата Сообщение от korvin_ Посмотреть сообщение
Это слишком бескомпромиссное, обощенное и однобокое утверждение, чтобы его можно было принять за истину.
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,117
Записей в блоге: 2
08.06.2014, 18:45
Цитата Сообщение от Mr.X Посмотреть сообщение
Например, муравейник состоит из муравьев, довольно однотипных, но имеющих подвиды: рабочие, солдаты, самцы, матка. Это описывается с помощью наследования этих классов от класса «муравей». Каждый муравей инкапсулирует свою сложность внутри, а с другими муравьями обменивается простыми сигналами. Это отражается инкупсуляцией. Каждый муравей реагирует на сигнал, посланный ему другим муравьем, но разные подвиды могут реагировать по-разному – это описывается с помощью полиморфизма. Т.е. в ОО-языке есть всё для моделирования именно больших и сложных систем, т.е. для преодоления сложности как описываемой системы, так и самой программы, чего без ООП добиться трудно или невозможно.
Такого рода примеры привлекательны для начинающих. На практике же от выделения базового класса "муравей" - толку не так уж много. Ах, он может получать сигнал! Ну так те же окна в Вындоуз тоже получают меседжи - и тоже реагируют на них по-разному (причем без всякого ООП). Вообще наследование - одна из самых уязвимых позиций. Чего это матка унаследована от муравья? Общности тут очень мало, гораздо логичнее - от базовой "рожалки", ведь почти весь ф-ционал будет посвящен этому. В общем, "популизм" гоните
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
08.06.2014, 20:20
Цитата Сообщение от Igor3D Посмотреть сообщение
Такого рода примеры привлекательны для начинающих. На практике же от выделения базового класса "муравей" - толку не так уж много. Ах, он может получать сигнал! Ну так те же окна в Вындоуз тоже получают меседжи - и тоже реагируют на них по-разному (причем без всякого ООП). Вообще наследование - одна из самых уязвимых позиций.
Одно из свойств больших и сложных систем как раз в том, что они состоят из весьма однотипных подсистем, которые отличаются друг от друга незначительно. Примеры я уже приводил: армия, многоклеточный организм, поведение тех же окон Windows это подтверждает. Наследование как раз отражает это свойство.
Цитата Сообщение от Igor3D Посмотреть сообщение
Чего это матка унаследована от муравья? Общности тут очень мало, гораздо логичнее - от базовой "рожалки", ведь почти весь ф-ционал будет посвящен этому. В общем, "популизм" гоните
Ну, открытое наследование означает «является разновидностью». Т.е. наследование класса муравьиной матки от класса Муравей означает только, что она тоже является муравьем.
0
1195 / 588 / 88
Регистрация: 20.09.2012
Сообщений: 1,881
09.06.2014, 08:33
Цитата Сообщение от Mr.X Посмотреть сообщение
DSL - это такой же, но созданный для моделирования систем одного конкретного типа
каждый раз, решая с помощью ООП новую задачу, мы создаем для этого новый язык, описывающий именно эту систему и никакую другую
т.е. основная задача ассемблера ООП это построить DSL для решения конкретной задачи.
Ну как и говорилось, DSL можно делать в любом языке, и именно DSL описывает и обеспечивает логику функционирования системы. А что там на низком уровне ассемблер или ооп совершенно никакой разницы - они не являются высокоуровневыи описанием.
С чего бы это? Вообще-то они именно для этого и предназначены. И из всех языков общего назначения наиболее для этого подходят.
Если б они для этого подходили, то не пытались бы при малейшем усложнении системы прикрутить внешний DSL. До смешного доходит в FAR Lua прикрутили. Полагаю это от безмерной крутизны ООП в С++ дошли до жизни такой. И это самый примитивный пример.

Ну а вообще проходили уже. Вот конкретная задача https://www.cyberforum.ru/post6164995.html
Вот ее решение в языке обшего назначения который внутри себя формирует DSL http://ideone.com/afT4f2
Если синтаксис не знаком то читать с места [<EntryPoint>], т.к. в программе сформирован (внутри средствами языка а не внешний как в ооп) DSL, то описание условий для решения задачи практически повторяет текст на английском языке. Теперь можете попробывать доказать, что использование ООП позволит сформировать более вменяемый DSL для описания условий. И да.. т.к. по вашему "ООП наиболее для этого подходят", полный код решения должен быть соотвествено меньше.
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,117
Записей в блоге: 2
09.06.2014, 10:33
Цитата Сообщение от Mr.X Посмотреть сообщение
Одно из свойств больших и сложных систем как раз в том, что они состоят из весьма однотипных подсистем, которые отличаются друг от друга незначительно
Напр организация рабочих муравьев и система размножения - какая тут однотипность?

Конечно нет ничего плохого в базовом классе "муравей", но не надо подавать его как "правильное (или даже волшебное) решение ООП". Само по себе оно ничего не решает. Вообще явная аналогия/следование реальной жизни часто ошибочно. Типично отсутствие цели - вот, мол, описываем муравейник, т.е. пока все "висит в воздухе" (типа учебный пример) еще так-сяк. Но вот появляется конкретика, напр добывание пищи рабочим муравьем, эта тема недавно тут была. И выясняется что сущность "муравей" там совсем не нужна, зато надо иметь понятие в теории вероятности, графах и.т.п.
0
Эксперт С++
 Аватар для Mr.X
3225 / 1752 / 436
Регистрация: 03.05.2010
Сообщений: 3,867
09.06.2014, 11:10
Цитата Сообщение от Igor3D Посмотреть сообщение
Напр организация рабочих муравьев и система размножения - какая тут однотипность?
Мне кажется, вы несколько смешиваете понятия типа и подтипа. То, что подтипы у объектов очень отличаются отнюдь не мешает им принадлежать одному типу. И рабочие муравьи, и муравьиная матка являются муравьями, поэтому тип у них один, а подтипы разные.
Вот если бы в муравейник входили и муравьи, и атомные электростанции средней мощности, то они точно не поняли бы друг друга. А муравей муравья всегда поймет.
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,117
Записей в блоге: 2
09.06.2014, 12:42
Цитата Сообщение от Mr.X Посмотреть сообщение
Мне кажется, вы несколько смешиваете понятия типа и подтипа. То, что подтипы у объектов очень отличаются отнюдь не мешает им принадлежать одному типу
Да на здоровье. Просто от того что создана общность "муравей" - ничего особо не изменилось, и до решения конкретной задачи столь же далеко. И легко привести пример где эта общность вообще не нужна. Поэтому не надо выставлять дело так что якобы - "применил ООП, и вот оно, счастье" Во всяком случае пример с муравейником этого никак не подтверждает.

Добавлено через 9 минут
Да, вот еще. Несмотря на всю раздутость/пиар, ООП все-таки что-то предлагает. А вот что предлагает взамен критика ООП - я лично не вижу. "Писать как умеешь" - ну это и так все делают А значит такую критику нельзя считать конструктивной.
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
BasicMan
Эксперт
29316 / 5623 / 2384
Регистрация: 17.02.2009
Сообщений: 30,364
Блог
09.06.2014, 12:42

Недостатки React
Здравствуйте. Расскажите пожалуйста о недостатках, архитектурный просчетах, неудобствах и т.д. с которыми вы сталкивались при написании...

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

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

Какие недостатки
Люди, что можите сказать о http://www.rucar.ru? Заранее спасибо! :)

недостатки системы
Пожалуйста, скажите, кому что не нравится в windows 7 с точки зрения безопасности.


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
40
Ответ Создать тему
Новые блоги и статьи
Теория всего 12. ВГК
anaschu 21.07.2026
### Главные семантические изменения и дешифровка новой физики 1. **`REPRODUCTIVE_EMISSION` вместо фотосинтеза (`PS_base`)**: Энергия и ресурсы, которые класс средних мужчин (`_W_MEN_DONORS`). . .
Публикация отклонённая на хабре. Как «пернатого» заставить осваивать новые горизонты опыта через масштабирование задачи и целеполагание
Hrethgir 21.07.2026
https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11948&stc=1&d=1784657928 Привет Хабр. В этой статье я расскажу, как один закон эпистемологии позволил мне с ходу запустить уникальный. . .
Теория всего 11. Основные параметры
anaschu 21.07.2026
Дешифровка тензорного ядра Soil Chemistry 2. 0: Истинный инвариант Теории Всего Чистовой исходный код многокомпонентной сукцессии зафиксирован. Модель оперирует единым вектором состояния. . .
Теория всего 10. Клод трусишка
anaschu 21.07.2026
Алгоритмический суицид ИИ: Когда математика ОДУ взламывает цензурные шлюзы Свежайший мета-прецедент нашей разработки! Клод официально отказался строить итоговую кроссплатформенную модель, как. . .
Теория всего 9. Окончательная проработка метафоры "дерево = традиции"
anaschu 21.07.2026
Скрытые параметры ядра ОДУ: Механика Глубинного Рока Клод утаил от вас ключевую математику кризисов. В движке игры зашиты пять скрытых коэффициентов, определяющих, как именно ТНК и Мемы ломают. . .
Теория всего 8. Clauude трусишка. Ответ джемени
anaschu 21.07.2026
Игровой баланс «Модели Всего»: Алгоритмический блок как механика Семантического БуфераЭтот скриншот отказа Клода — идеальный, чистейший прецедент для нашей Теории Всего. Вы столкнулись не просто с. . .
Теория всего 7. Дерево - это патриархат, грибы - это феминизм
anaschu 21.07.2026
Уничтожение Патриархата: Как ТНК, Мемы и Половой отбор зачистили «Сексуальный Пролетариат» Величайшая иллюзия современного человека — вера в «свободу воли», «социальный прогресс» и «эволюцию. . .
История и социология Терры на примере борьбы микориз за пространство. 1. Глоссарий терры.
anaschu 21.07.2026
Решил тут подумать о возможности сделать лор некоторой комп игры - стратегии, или худжественной книги антиутопии, которые будут юзать планету,которая максимально будет похожа на нашу землю, но где. . .
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2026, CyberForum.ru