Sozdatel_Nichego, нет, чтобы понять абстракцию, нужно обобщить свой опыт, и его получить можно только, если писать код. Формальный ответ на ваш вопрос звучит так: парадигма объявляет термины в каком-то контексте, а методология вводит абстракции и их правила взаимодействия с ними для определенного контекста. Но такой ответ нельзя назвать понятным.
Sozdatel_Nichego, пожалуйста, по-конкретнее укажите на то, что вас смущает, чтобы я мог скорректировать ответ и дать пояснения.
Igor Tkhorik, нет, там расчёт на то, что "ну, ты же сам предложил kpi , по которым тебя нам приходится тебя оценивать"
И потом очень легко заставить человека и перерабатывать, и выходить в выходные, да хоть брать работу на дом
По вики ничего никогда не поймёте.
Для того, чтобы что-то понять, нужно это обобщить.
Хотите понять процедурную парадигму, напишите несколько программ на ассемблере. Хотите понять структурную парадигму, напишите несколько программ на Си. Хотите понять функциональную, ООП - напишите. Когда поймёте, сравните парадигмы, как одни и те же концепции будут выглядеть в разных парадигмах. Вот в этот момент вы поймёте, что такое парадигма. Почему важно оставаться в рамках парадигмы и всю важность четко сформулированнвх термнов.
То же самое с методологиями разработки.
Попробуйте одну, вторую, третюю, обобщите, сравните.
Википедия - это не обучающий ресурс, а справочник, в котором без понимания вы видите буквы и слова, а не термины и суть.
Потому что класс - это интерфейс для взаимодействия с абстракцией, а БД эти абстракции вообще не сдались, там главное транзакции, скорость чтения, минимальные блокировки. Поэтому в сути, реляционная модель и ООП находятся в конфликте интересов.
У вас в примере класс типа Object Value, их хранить в БД проблемы нет. А вот с Reference Object начинаются проблемы, потому что каждый член класса заключает данные, которые могут храниться от 1 до десятка разных таблиц.
Подходы разные, начиная от ручного статического определения таблиц в коде, скриптами генерации таблиц, скриптами для пересоздания таблиц при изменении модели и заканчивая полетом фантазии, всякими вещами типа LiNQ в C# и прочими DSL.
Но если работать в сферическом вакууме, обычно хватает репозитория.
Вам нужно сделать функцию принимающую три числа и возвращаю минимум и максимум.
После ввода трёх вершин, вызвать ее для абсцисс и ординат вершин.
Ещё одна функция делает проверку, что у заданной точки, абсцисса точки и ордината точки входит в промежутки [Х Макс, Х мин], [ Y max, Y min ].
А то что вы написали, это называется расчет вручную. Что вы будете делать, если условие задачи меняется, и теперь у вас 1000 точек для проверки?
Если треугольников 100?
Это нормально. Книги Таненбаума это как читать zip архив. Для полного понятия рекомендую прослушать курс лекций по Операционным системам на stepik
Тогда пазл сложится.
Ну ещё курс по многопоточности от mail.ru на Ютубе или stepik
Кажется, здесь слишком абстрактная формулировка.
В теории автоматизации и управления и в системном анализе сложность описывается разными терминами.
Пожалуйста, конкретизируйте вопрос.
Sozdatel_Nichego, пожалуйста, по-конкретнее укажите на то, что вас смущает, чтобы я мог скорректировать ответ и дать пояснения.