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

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

16.05.2014, 16:35. Показов 22281. Ответов 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
Модератор
Эксперт функциональных языков программирования
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
03.09.2016, 21:10
Студворк — интернет-сервис помощи студентам
Цитата Сообщение от Igor3D Посмотреть сообщение
Менее 1%. Но да, такое "неоднообразие" доставляет известные неудобства.
В больших программах менее 1%. А если я, например, пишу утилиту, которая скачивает страницу по http, парсит, данных сохраняет в csv. Соответственно, у меня 3 сторонние библиотеки и 4 типа для строк. Полезного кода (который содержит логику приложения) тут на 5-10 строк всего. Остальное - "обвязка".

Цитата Сообщение от Igor3D Посмотреть сообщение
не вижу каким образом (в идеале) это должно быть "стандартизовано" (и возможно ли это вообще)
В C# стандартизировано - классы String, List, Dictionary и т.п.

Цитата Сообщение от Igor3D Посмотреть сообщение
Дескать, в плюсах много запутанных и противоречивых правил, а вот всякие там "монады" (и прочие прелести с выносом мозга) - ото кайф!
Дело не в сложности, дело в объёме. В C++ нет ничего сложного для понимания, но много чего надо запомнить.
0
Заблокирован
03.09.2016, 22:28
Цитата Сообщение от Shamil1 Посмотреть сообщение
В C++ нет ничего сложного для понимания, но много чего надо запомнить.
Не <надо много чего запоминать>, а <надо много чего удерживать в голове> когда пишешь код на С++, чтобы не накосячить.
Это и называется "сложность"
0
 Аватар для Fulcrum_013
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
04.09.2016, 03:13
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Используя математические формулы и дифуры "просчитали"?
В том числе и при помощи дифуров. Не зря же Черчилль "Капитал" до войны изучил. А кое что читая переписку немецкого командования. А вот для этого математика во всю в Англии и Польше поработала.

Добавлено через 10 минут
Цитата Сообщение от ИсмаилПркопенко Посмотреть сообщение
Не <надо много чего запоминать>, а <надо много чего удерживать в голове> когда пишешь код на С++, чтобы не накосячить.
Лично я предпочитаю держать то что надо чтобы не накосячить держать не в голове а в переменных.

Добавлено через 1 минуту
Но для этого нужна абстрактная модель того что делаешь. Это и называется сложность. Но ее на любом языке никто не отменит

Добавлено через 1 час 56 минут
Цитата Сообщение от Shamil1 Посмотреть сообщение
В C# стандартизировано - классы String, List, Dictionary и т.п.
Ну и толку? Ну к примеру AnsiString потому и Ansi что соответствует национальному отраслевому стандарту - т.е. стандартизирован для всех вычислительных систем а не только для какого то одного языка. Но как бы ни для шарпа ни для джавы ни для STL оно почему-то не кошерно, у них типа свои стандарты.
0
Модератор
Эксперт функциональных языков программирования
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
04.09.2016, 03:29
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Ну и толку?
Каждый программист C# не придумывает свой класс для хранения строк.

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Ну к примеру AnsiString потому и Ansi что соответствует национальному отраслевому стандарту
AnsiString потому Ansi, что в кодировке ANSI. А не кошерно, потому что нельзя определить, что за символы она содержит (можно только пытаться угадать страницу кодировки), и нельзя хранить символы разных страниц кодировки.
0
 Аватар для Fulcrum_013
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
04.09.2016, 05:57
Цитата Сообщение от Shamil1 Посмотреть сообщение
Каждый программист C# не придумывает свой класс для хранения строк.
А типа пользует универсальный на все случаи жизни? Так случАев тоже многость могет быть и хранит их могет понадобится совсем по разному не зависимо от кодировки или размера символу.

Добавлено через 3 минуты
Цитата Сообщение от Shamil1 Посмотреть сообщение
AnsiString потому Ansi, что в кодировке ANSI.
Ну не только это. Есть еще стандарты на способ представления строки в паямти. многобайтовых строк они тоже кстати касаются.. WideString и UnicodeString от инстанса того же шаблона порождены обычно.
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,122
Записей в блоге: 2
04.09.2016, 09:04
Цитата Сообщение от Shamil1 Посмотреть сообщение
Каждый программист C# не придумывает свой класс для хранения строк.
Немало молодых ребят начинают программировать сразу с использованием Qt фреймворка. Ситуация аналогичная - ничего придумывать не надо, вот класс QString (внутри юникод), бери и пользуйся.

Однако результат оказывается далеко не таким уж хорошим. Да, сэкономлено немало времени на рутинную работу, но с др стороны человек не понимает многих вещей, ведь он просто "прочитал и запомнил", и все. Нет того понимания которое дает "изобретение своего велосипеда". Нет аккуратности которая приобретается при работе с примитивным char *. Не получал по ушам с "коровой" (std::string). Ну и, может, самое главное - "подрезаны крылья". Ничего придумывать сам он уже не хочет, все его усилия направлены на поиск "готовых решений/классов".
Все уже давно написано
Любимая песенка бездарности. Однако далеко не каждый проект сводится к подключению/эксплуатации готового. Попав в ситуацию где нужно "велосипедить" (да, искать решения) любитель "пользоваться готовым" оказывается беспомощным. Бросается в гуглу, находит "что-то похожее", оказывается это совсем не то.... В общем, плохо когда своей головы нет
0
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
04.09.2016, 12:34
Цитата Сообщение от Igor3D Посмотреть сообщение
Немало молодых ребят начинают программировать сразу с использованием Qt фреймворка. Ситуация аналогичная - ничего придумывать не надо, вот класс QString (внутри юникод), бери и пользуйся.

Однако результат оказывается далеко не таким уж хорошим. Да, сэкономлено немало времени на рутинную работу, но с др стороны человек не понимает многих вещей, ведь он просто "прочитал и запомнил", и все. Нет того понимания которое дает "изобретение своего велосипеда". Нет аккуратности которая приобретается при работе с примитивным char *. Не получал по ушам с "коровой" (std::string). Ну и, может, самое главное - "подрезаны крылья". Ничего придумывать сам он уже не хочет, все его усилия направлены на поиск "готовых решений/классов".
Любимая песенка бездарности. Однако далеко не каждый проект сводится к подключению/эксплуатации готового. Попав в ситуацию где нужно "велосипедить" (да, искать решения) любитель "пользоваться готовым" оказывается беспомощным. Бросается в гуглу, находит "что-то похожее", оказывается это совсем не то.... В общем, плохо когда своей головы нет
Изобретение велосипедов хорошо для обучения. Если же я на работе начну писать свой собственный класс под каждую типовую структуру данных, коллеги меня не поймут
1
Модератор
Эксперт функциональных языков программирования
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
04.09.2016, 13:13
Цитата Сообщение от Igor3D Посмотреть сообщение
Нет того понимания которое дает "изобретение своего велосипеда".
Изобретать свой велосипед для обучения - это хорошо. И наличие string/qstring из коробки этому никак не мешает. А вот когда ты вынужден изобретать велосипед от безысходности, вместо того, чтобы писать полезный код, ты транжиришь своё время. И не только своё, но и того, кто будет этот код поддерживать.

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Так случАев тоже многость могет быть и хранит их могет понадобится совсем по разному не зависимо от кодировки или размера символу.
В 99% случаев достаточно двух классов - неизменяемая строка (String C#) и изменяемая строка (StringBuilder C#). В тех случаях, когда стандартный класс не устраивает, всегда можно написать свой. Но это будет уже осознанное, полезное действие, а не бездарная трата времени от безысходности.
0
 Аватар для Fulcrum_013
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
04.09.2016, 13:27
Цитата Сообщение от Shamil1 Посмотреть сообщение
В 99% случаев достаточно двух классов - неизменяемая строка (String C#) и изменяемая строка (StringBuilder C#).
Как на меня в этом плане удобнее строка которая может быть как константной так и изменяемой. Но при этом еще нужен полиморфный класс подстрока. Например для обработки текста одновременно как единого целого так и набора строк.

Добавлено через 1 минуту
Цитата Сообщение от Shamil1 Посмотреть сообщение
А вот когда ты вынужден изобретать велосипед от безысходности, вместо того, чтобы писать полезный код, ты транжиришь своё время. И не только своё, но и того, кто будет этот код поддерживать
Иногда просто нужно другое поведение строк. К примеру строка полностью имитирующая char* но при этом сама ресайзящаяся и т.д.

Добавлено через 4 минуты
Цитата Сообщение от Shamil1 Посмотреть сообщение
И наличие string/qstring из коробки этому никак не мешает
std::string фигня полная. СString не сильно лучше. Посему под MSVC для нормальной работы со строкам другой альтернативы нет. Насчет qstring особо ничего сказать не могу что у нее под капотом не знаю.
Так что если не хочешь вязаться на какой то определенный оконный фреймверк а строки нужны с нормальными возможностями то свои строки будут полюбому.
0
Модератор
Эксперт функциональных языков программирования
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
04.09.2016, 13:37
Цитата Сообщение от Igor3D Посмотреть сообщение
Да, сэкономлено немало времени на рутинную работу
Перед программистом стоит задача (в широком смысле), которую нужно решать. Например, в виде списка "вариантов использования" (use case). Идеальный язык программирования должен позволять заниматься непосредственно решением этой задачи. Время, потраченное на кодирование структур данных, циклов и прочего, фактически, потрачено на борьбу с недостатками языка. И чем больший процент времени тратится на это, тем хуже язык.

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

Добавлено через 4 минуты
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Иногда просто нужно другое поведение строк.
Ключевое слово тут "иногда".

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
строки нужны с нормальными возможностями то свои строки будут полюбому
Это вызвано не объективными причинами, а отсутствием в стандарте языка "строк с нормальными возможностями". И для широкого класса задач это является серьёзным недостатком языка.
0
 Аватар для Fulcrum_013
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
04.09.2016, 13:37
Цитата Сообщение от Shamil1 Посмотреть сообщение
Время, потраченное на кодирование структур данных,
Фактически незначительное и дает возможность при решении задачи вообще об инфраструктуре не задумываться.
0
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
04.09.2016, 13:48
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
std::string фигня полная. СString не сильно лучше. Посему под MSVC для нормальной работы со строкам другой альтернативы нет.
В серъезных конторах, где пара десятков человек пишет продукт, за изобретение собственных классов строк расстреляют.
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,122
Записей в блоге: 2
04.09.2016, 13:49
Цитата Сообщение от Shamil1 Посмотреть сообщение
А вот когда ты вынужден изобретать велосипед от безысходности, вместо того, чтобы писать полезный код, ты транжиришь своё время. И не только своё, но и того, кто будет этот код поддерживать.
Не понял откуда взялась "безысходность"? На плюсах, как и в любом языке, ее никогда не было. Другое дело бывает нелегко выбрать подходящее. Подключение Qt выльется в заботы с либами, std::string не так уж удобен как хотелось бы и.т.п. Бывает посмотрел - та, тут и char * можно обойтись, а потом задача разрослась и этот выбор оказался неоправданным. Но это никак не "недостаток языка"

Цитата Сообщение от Shamil1 Посмотреть сообщение
В 99% случаев достаточно двух классов - неизменяемая строка (String C#) и изменяемая строка (StringBuilder C#).
Просто C# моложе и еще не успел обзавестись наследством (legacy)
0
 Аватар для Fulcrum_013
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
04.09.2016, 14:00
Цитата Сообщение от oldnewyear Посмотреть сообщение
В серъезных конторах, где пара десятков человек пишет продукт, за изобретение собственных классов строк расстреляют.
В серьезных конторах эти пару десятков человек сначала думают что им надо (в том числе какие типы данных и т.д. понадобятся) и согласовывают интерфейсы модулей которые каждый реализовывает. При этом если это действительно 2 десятка человек то фреймверк скорее всего свой.

Добавлено через 4 минуты
Цитата Сообщение от Shamil1 Посмотреть сообщение
Ключевое слово тут "иногда"
В реалиях это иногда может просто содержаться под капотом строки которая пользуется всегда.

Добавлено через 1 минуту
Реально что не укладывается в одном типе строк - это к примеру обязаловка на 0-терминатор и возможность делать подстроки указателем на исходную строку.

Добавлено через 1 минуту
Ну и разный тип символа тоже обычно к разным инстансам одного шаблона строки приводит.
0
Модератор
Эксперт функциональных языков программирования
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
04.09.2016, 14:04
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
В серьезных конторах эти пару десятков человек сначала думают что им надо (в том числе какие типы данных и т.д. понадобятся)
Сначала - это в какой момент? Например, серьёзная контора уже 15 лет разрабатывает продукт. В настоящий момент ведётся работа по версиям 8.0, 7.5 и 7.4.12. Какой именно момент Вы называете "сначала"?

Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
и согласовывают интерфейсы модулей которые каждый реализовывает
По человеку на модуль? Часто несколько человек одновременно правят один и тот же класс.
0
440 / 432 / 159
Регистрация: 21.05.2016
Сообщений: 1,338
04.09.2016, 14:05
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
При этом если это действительно 2 десятка человек то фреймверк скорее всего свой.
Чтобы заказчик потом разбирался с кустарными классами строк?
0
Модератор
Эксперт функциональных языков программирования
3140 / 2288 / 469
Регистрация: 26.03.2015
Сообщений: 8,898
04.09.2016, 14:07
Цитата Сообщение от Fulcrum_013 Посмотреть сообщение
Ну и разный тип символа тоже обычно к разным инстансам одного шаблона строки приводит.
Мне нужно вывести на экран предложение, в котором часть слов кириллицей, а часть - китайские иероглифы. Мне нужен один объект, а Вы предлагаете разные классы использовать.

Добавлено через 1 минуту
Цитата Сообщение от oldnewyear Посмотреть сообщение
Чтобы заказчик потом разбирался с кустарными классами строк?
Всё как в лозунге выше: каждая библиотека должна использовать свой класс строк!
0
 Аватар для Fulcrum_013
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
04.09.2016, 14:09
Цитата Сообщение от Shamil1 Посмотреть сообщение
Часто несколько человек одновременно правят один и тот же класс.
Так говнософт делается а не серьезный софт.
Цитата Сообщение от Shamil1 Посмотреть сообщение
Какой именно момент Вы называете "сначала"?
Сначала - это этап аналитики и постановки задачи. При внесении изменений та же самая песня.
0
1977 / 833 / 115
Регистрация: 01.10.2012
Сообщений: 5,122
Записей в блоге: 2
04.09.2016, 14:12
Цитата Сообщение от Shamil1 Посмотреть сообщение
Перед программистом стоит задача (в широком смысле), которую нужно решать. Например, в виде списка "вариантов использования" (use case). Идеальный язык программирования должен позволять заниматься непосредственно решением этой задачи. Время, потраченное на кодирование структур данных, циклов и прочего, фактически, потрачено на борьбу с недостатками языка. И чем больший процент времени тратится на это, тем хуже язык.
Может Вы хотите от языка слишком многого. Предлагаю небольшой тест

Есть 2 полупрозрачных цветных стекла: переднее и заднее (front & back). Это 2 структуры данных ARGB, каких конкретно - на Ваше усмотрение, можно использовать любые готовые классы. Нужно посчитать итоговый цвет как это делает фотошоп и др приложения. Формально: вычитающая прозрачность, цветовая модель (A)RGB.

Вот я не уверен что есть язык на котором этой крохотной задачке будет посвящено столько строк сколько она заслуживает. Вот со своими великами да, а так... ну не знаю, не знаю
0
 Аватар для Fulcrum_013
2083 / 1576 / 169
Регистрация: 14.12.2014
Сообщений: 13,614
04.09.2016, 14:17
Цитата Сообщение от Shamil1 Посмотреть сообщение
Мне нужен один объект, а Вы предлагаете разные классы использовать
А из другого места приходит текст в wchar_t а из третьего вообще в char. При этом его нужно из всех мест принять и если уж юзать в одном предложении то сконвертить в уникод. Вот для этого разные инстансы одного и того же шаблона и пользуются. А еще бывают знаете ли специальные типы символов которые тоже удобно как строки обрабатывать. К примеру набор токенов на выходе лексера по факту тоже строка только с гораздо более сложным символами. Как к примеру удобно и всякие маски в виде строк каждым символом которой является структура с указанием к примеру допустимых диапозонов символов и т.д. хранить и обрабатывать (например комбинировать складывать и т.п.)
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
BasicMan
Эксперт
29316 / 5623 / 2384
Регистрация: 17.02.2009
Сообщений: 30,364
Блог
04.09.2016, 14:17

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

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

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

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

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


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

Или воспользуйтесь поиском по форуму:
180
Ответ Создать тему
Новые блоги и статьи
Был праздник вчера, а я и не знал.
kumehtar 28.07.2026
27. 07. 2026г. Intel Core 2 Duo исполнилось 20 лет Новости компьютерного мира и их обсуждение (4) Салют, шампанское, овации! :drink:
Нейтральные знания, чистый код - бла-бла-бла-бла, на самом деле кликбейт и самореклама, плагиат, и вот почему
Hrethgir 27.07.2026
То-есть отклонение такой публикации говорит само за себя, и пусть только возьмут на вооружение после отклонения публикации - это будет чистейшим актом плагиата. Отклонял Хабр. Дословно, отклонённая. . .
тв 16 бой ии
anaschu 27.07.2026
Великий Перелом ИИ: Как уравнения ОДУ Radau дожали цензурные фильтры Алисы Фиксируем в мемофонде Теории Всего беспрецедентный факт в истории ИИ-зондирования. В затяжном многораундовом. . .
мв 15. непроверенное, возможно, глюк
anaschu 27.07.2026
НАУЧНО-АНАЛИТИЧЕСКИЙ ОТЧЕТ. РАЗДЕЛ 1. 1: «НАУКА» (РАСШИРЕННАЯ СТЕХИОМЕТРИЧЕСКАЯ И ГЕНЕТИЧЕСКАЯ ВЕРСИЯ)Тема: Теоретическое обоснование инвариантности 19-мерного тензорного ядра непрерывных ОДУ и. . .
Очистка реквизитов и табличных частей документа при копировании (вариант 2)
Maks 26.07.2026
Алгоритм из решения ниже разработан на примере нетипового документа "ЗаявкаНаРаботу", разработанного в КА2. Задача: Заменить алгоритм запрета копирования документов для сотрудников с ролью "Стажер",. . .
Доктрина интенционального знания - Доктрина для портала "Срез".
Hrethgir 25.07.2026
Может найдётся кто захочет оценить доктрину. . . Написания правил участия для меня роскошь, требующая лимита времени, поэтому все сообщения не прошедшие модерацию будут видны только участникам портала,. . .
сукцессия 44. Решил подать на припринт в межународные сервисы препринтов. Но нужно одобрение от ученых
anaschu 25.07.2026
Английский вариант. Пока кто то не одобрит мою личность, мне не получиться это опубликовать на препринте. Но заявку на публикацию статьи я сегодня подам.
сукцессия 43. Вторая научная статья за месяц- прайминг и гатгил
anaschu 25.07.2026
две стороны одной монеты
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2026, CyberForum.ru