mayton2019

обязательно ли именовать пакеты в Java именно так "com.javastart.NAME"

Их можно именовать как угодно. Просто если делать интеграцию твоего приложения с другими
библиотеками то конфликтов имен можно избежать если всегда добавлять домен + твое имя.
Это практически всегда уникально.

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

В Scala есть object - это уже готовый синглтон из коробки поэтому необходимости в следовании паттерну уже вроде как нет.

Смотрю ролики по программированию. Заинтересовали ролики Немчинского (хотя некоторые вещи он объясняет крайне непонятно для новичка).

Немчинский - популист и популяризатор своей собственной it-школы. Обычно в каждом видосе - реклама.

У него есть контр-образовательная позиция. Он например считает что после 1 курса универа надо сразу идти работать и наплевать на диплом вообще.

Во многих роликах Немчинский говорит, что надо использовать классы через интерфейсы.
....
У меня есть класс 1, в нем есть методы. Класс 1 используется в классе 2. Зачем интерфейс?

Не смотрел видео. Но в этом вобщем-то есть смысл для создания слабой зацепленности и InversionOfConrol.
Новичку такое объяснить нельзя. Нужны месяцы и годы чтобы понять. Желательно не на синтетических
уроках а на реальных боевых проектах где МНОГО кода. Именно обилие кода и требование проводить
сложны рефакторинги, замены движков одни на другие и цикл постоянной доработки - мотивируют к
внедрению базовых интерфейсов вместо классов.

То что ты не понял с 1 раза - это нормально. Я тоже когда изучал ооп и полиморфизм на примере Borland Pascal
тоже подумал что это туфта и я это использовать никогда не буду ибо незачем.

Можно привести пример на php и показать выгоду такого подхода?

Тут я не уверен. Вроде в PHP OOP есть с 5 версии. А есть ли там механики полиморфизма - ХЗ.
Пускай знающие прокоментируют. Но если есть - то хороший пример переключения
функционала например с Db MySQL на Postgresql без переписывания бизнес-логики.
В идеале у вас переключение должно произойти в 1 строчке кода. Если удалось - значит
метод работает.

Упоминалось об изменении иерархии классов во время выполнения.

Постарайтесь найти пример. Что имелось в виду. Создание новой пары класс+объект? Или изменение
интерфейса объекта? Информатика и вычислительная техника за 20й век насоздавала столько экзотических
языков и парадигм что на любой каприз можно что-нибудь да найти. Создавались даже такие языки
цель которых - максимально усложнить (Malbolge) разработку. Поэтому если "просто так менять иерархию" - то
можно уподобляться комсомольцам которые сначала создают проблемы а потом их героически решают.

Могу рассказать насчет фасада. Это - самый простой шаблон. Если у тебя есть некая сложная задача и ее надо сводить к вызову 1 метода - то это фасад. Например для С++ языка - main функция является "фасадом". А консольные параметры - это как-бы аргументы к функциям фасада. PHP скрипт тоже является фасадом а параметризируется через параметры URL.

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

В обоих из них можно изобразить стрелочкой или агрегацию (для классов) или связь child-parent как ссылочный
ключ в таблицах.

В случае с классами достаточно просто описать что поле имеет тот-же тип что и сам класс. Это будет всем понятно.

ООП предполагает что в задаче есть некая сущность. Объект. И у него должны быть методы. Что происходит в данной задаче? Пользователь вводит x, потом размер массива. Потом сам массив. После этого делаются какие-то манипуляции с массивом. И после этого массив распечатывается на экран. Где тут ООП? Я не знаю! Я чорт возьми не пойму где здесь ООП.

Вобщем скажи своему преподавателю что здесь нет смысла вводить ООП. Код достаточно хорош и концептуален в том виде как он записан. И надо не забывать про принципы KISS/YAGNI которые никто не отменял.

Поскольку ты тегнул вопрос "JAVA" то имеет смысл просто начать изучение сразу по книгам Брюса Эккеля и Хостмана.
Вот в разрезе того как они описывают ООП - тебе будет достаточно. Еще посмотри на книгу Шаблонов проектирования (от Банды четырех) и Рефакторинг с шаблонами от Джоша Кериевски.

Читать чистую ООП - теорию я тебе не советую. Там нет того что тебе понадобиться.

Мне кажется что JavaScript/TypeScript - это плохой старт для изучения ООП. Дело в том что JavaScript исполняющая среда изначально была разработана с слишком вольной интерпретацией объекта. Грубо говоря она настолько flexible что те строгие законы и правила которые навязывает ООП в JavaScript могут быть слишком легко нарушены.

Поэтому чтобы почувстоввать нужность ООП, как дисциплины. Я-бы предложил Java или C#. Это как в музыке. Нельзя начать сразу ипровизировать джаз на музыкальном инструменте в 5 лет. Надо пойти в музыкальную школу где преподаватели тебе поставят руку правильно. А потом уже после семилетки - муз-училища - консерватории - иди в импровизации. Или даже иди раньше. Но какая-то дисциплина должна быть. ООП - это дисциплина. Не волюнтаризм.

Непонятно целеполагание. Автор хочет что-то сделать зачем?

Непонятно зачем тегать ООП ? В наше время сферического ООП не существует. Есть ООП в реализации конкретных языков. И оно очень сильно отличается. Например в некоторых языках все объекты - суть прототипы. В других не так.

Добавил версию с тегами js, ruby. И давайте обсуждать вот в разрезе языков. А то запутаемся совсем.

Полиморфизм - относится к базовым возможностям ООП. Тоесть к способности рассматривать объекты сквозь призму базового интерфейса.

Типизация - это обычно свойство компиллятора (или рантайма) по определению выводу типа каждой переменной.

Это две разных оси измерений вобщем-то. Квадрат по сути ч 4 ячейками. Есть полиморфизм или нет. И статический тип или динамический.