mayton2019

Желательно возвращать либо иммутабельные объекты (LocalDateTime вместо java.util.Date)
либо клонировать.

Если вернуть сложный объект со связями, то дальнейшее использование этого может
привести к сложным и трудно-воспроизводимым багам.

Разумеется жизнь полна исключений и тут главное чтоб вся команда разработчиков ПОНИМАЛА что
ты сделал и для чего. Иначе будут конфликты и война правок в коде проекта.

Т.к. мы не можем сделать выборку всех заказов в статусе X, т.к. их очень много, но мы и не можем сделать выборку с лимитом т.к. не знаем точно, что данные заказы будут оплачены платёжной системой Y и наоборот, если будем строить выборку от оплат. В общем получается, что мы решаем вопросы, которые легко решены в БД, но мы их пытаемся решить в коде. Как поступать то?

Это типичная проблема которая возникает после распила монолита на части. Если раньше
монолит ходил в базу и делал любые SQL, то после разделения отвественностей уже такие
игры не работают.

Вы говорите что не знаете точно какие заказы оплачены. Вам нужно создать новый метод
который в правильном сервисе выдает только оплаченные заказы. А в базу ходить не надо.
Она вообще может быть недоступная по инфо-безопасности для прочих модулей.

Вот и есть правильная микросвервисная архитектура.

Программирование в ООП предполагает что мир состоит из "объектов".
Например твоя программ (процесс) калькулятор это уже объект. Даже не имея декларации
она уже является объектом с точки зрения ОС.

Но если твой преподаватель - такой душный, то сделай

class Calculator {
   ...
}

Можно сделать объектом число и операцию над ним (унарная или бинарная) но это уже немотивированное
(или слабо мотивированное) действие. Теоретики ООП всегда пишут что введение объекта должно иметь смысл. Иначе так можно
дойти до абсурда и объявлять объектом любую чепуху, что только усложнит написание кода
и создаст бюрократию на пустом месте.

Поясни это преподавателю если он будет сильно настаивать на том что мало объектов.

Классы удобны когда все функции объединяются общим контекстом. Например подключение к БД.
Или класс - клиентское окно где можно рисовать графику. Можно кодить и без классов на голых
функциях (такое тоже практируется) но тебе придется одним параметром всегда передавать
контекст.

Использование классов (объектов) для хранения состояния - это признак зрелости исходного кода.

Судя по описанию pygame - это игровая библиотека. И она учит школьников делать игрушки.

Никакому ООП она не научит. Если ставить цель - именно ООП - то лучше просто брать курс Python
там и будет обязательно лекция по ООП в парадигме Python.

Тут нужно копнуть в историю и почитать для чего JavaScript созадавался. Какие цели и задачи перед ним ставились. Почитайте это интересно. И в части Lisp в браузерах - тоже.

Что такое вообще ООП применительно к теории и к конкретному языку? На сегодняшний день не существует канонической реализации ООП. Грубо говоря ни один язык не может претендовать на трушное ООП. Хотя другие ООП (класса строго типизированных) просто вводят больше ограничений на компилляцию
и рантайм запрещая на ходу менять тип объекта или внедрять в него новые методы и перегружать существующие.

JavaScript является таким себе податливым пластилином который разрешает очень многое делать
с объектами и именно это является объектом критики. Прототипирование вместо наследования и прочее.
JavaScript насколько я знаю расширяет спецификацию и все таки вводит понятие класса. Ключевое
слово есть. Это хорошо. Это его приближает к ООП и дает возможность больше проводить параллели с back-end например.

Есть языковые надстройки (транспилляторы) типа type-script которые вводят некий повышенный уровень
строгости по отношению к типам. Но Runtime насколько я понимаю по прежнему остается либеральным.

Вообще тема чистоты ООП - это достаточно трольная тема особенно на собеседованиях. Теоретики до сих
пор не могут посчитать сколько же свойств нужно для описания ООП. Там вроде как 3 свойства было или 4.
До сих пор нед единого трактования термина инкапсуляция.

Поэтому всех религоизных фанатиков ООП надо слать к чорту. А на собеседовании отвечать очень обтекаемо
и с отсылкой на всяких Кентов Беков и Фаулеров и Дядек Бобов. Пускай они там друг с другом договоряться
о терминологии а потом уж мы подтянемся.

Поскольку топик тегирован PHP то я-бы предложил взять PHP фреймворки и смотреть как они видят себе реализацию шаблона например репозиторий. Я-бы мог рассказать о Spring Data Repository но боюсь что для PHP будут отличия и автор просто запутается.

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

Что такое шаблон Store - я не знаю. Опять-же это специфика PHP скорее всего.

Что такое шаблон Сервис. Ну я вообще не рискнул бы его никак определять. Это КМК слишком размытое понятие и его надо срочно сузить. Хотя-бы до уровня техно-стека. Может сервис в терминологии SOAP это одно. Облачный сервис - может быть вообще другое. Короче архитекторы этих технологий будут бить друг друга здесь как епископы разных церквей друг друга за ереси.

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

Непонятно что вы хотите увидеть в этой табличке? Кейсы в которых надо брать ООП или не-ООП?

Мы живем в эпоху мультикультурализма в разработке. Языки такие как C++/Scala в принципе - мультипарадигменные. Они являются одновременно ООП и ФП. И эта диффузия продолжается.
И другие языки тоже идут в этом направлении.

Есть хороший доклад Брагилевского где он просто напримере геометрических фигур (круг, квадрат)
показвывает что ФП и ООП - это просто две ортогональные технологии которые одинаково ведут
к успеху.

По реализациям. 99% зависит от платформы. Например языки C#/F# будут скорее всего использовать
платформу .Net и ее реализацию типов и классов. Языки Java/Kotlin/Scala - соотв будут опираться
на JVM-представление классов и ее типы. Erlang/Elixir - своя реализация типов в beam-машинке.
Нативные языки - кто во что гаразд.

Когда использовать не-объектные языки. Ну не знаю. Я-бы опять уточнил - когда вам не стоит
внедрять пользовательские типы/классы. Вот я щас пишу утилиту для копирования данных
с продуктового ftp на тестовый. Там нужно файлы выбирать по датам. Код на scala. Состоит
из 1 объекта Main и порядка 40 штук функций. Пользовательских типов нет. Вот мне как-то
так хватило и этого. Если писать notebooks под Databricks то там тоже идет такой себе
стиль программирования где нет явной декларации классов.

Вобщем самый лучший язык - это тот который вы знаете. И профессионал может решить любую
задачу в своём языке всегда. Поэтому я-бы не стал париться рисованием таких табличек.
Тем более что она очень спорная и бесполезная.

Есть две функции и класс сервис. Для упращения функцию сервиса буду называть ФС. Так вот обе функции одинаковые до момента использования ФС в функциях. Как быть в таком случае? Делать абстрактный класс и абстрактную функцию, где будет вынесен общий алгоритм. А в абстрактной функции сделать вызов функции. Это нормальная идея или нет?

Здесь - недостаточно информации. Можно начать с того что нет даже оснований для ООП.
Есть просто какая-то функция которая висит в космосе. Ты можешь ее просто объявлять функцией.
ООП не запрещает функции.

Кстати по поводу ООП. Нет канонического рефакторинга для ООП. Обычно все учебные ООП
примеры - применительны к конкретным языкам. На примерах всегда пишут Джош Кериевски,
Мартит Фаулер и Дядя Боб. Поэтому чтобы дальше обсуждать твой вопрос предметно - нам
нужны сорцы.

Иначе получается битва телепатов. Мы тут мним твой исходник каждый в своём языке.

Давайте представим объект и DTO которым пользуется объект. Если объект возаращает DTO как представление самого себя, например методом showStruct(): DTO будет ли это являться нарушением инкапсуляции?

Я понял ваш вопрос. Смотрите. Философия ООП базируется на том что все действия с объектом должны быть санционированы языком или средой выполнения. Например в Java есть техника рефлексии которая позволяет много чего делать например менять приватные поля. Это часто используется в Mock/Mockito и я часто про это говорю. Мокито - фактически взламывает инкапсуляцию. Но это всех устраивает потому-что "тестить нуна!".
В Java также есть технология сериализации-десериализации которая обеспечивает сохранения состояния объектов на диск или передачу их в сеть для дальнейшей работы (например пользовательская сессия прыгает между нодами кластера). И это действие (сериализация) полностью санкционировано средой и языком. Всех это устраивает. Хотя с моей точки зрения - этож капец взлом. Но зато в Java вы никогда не сделаете down-casting объекта одного типа к типу другого если иерархия этого не позволяет. Этого делать нельзя ... ну потому что это точняк нарушение ООП. И нельзя найти никакой санкции на такое странное действие. Вот в языке С++ например вы можете жонглируя указателями взглянуть в любую память своего процесса или потока и прочитать любой байт или word/dword. Что можно сделать в PHP из подобного? Я не знаю. Но новерное что в PHP много механик которые не позволяют делать хакинг когда. Вот. Поэтому ООП и считается философией программирования а вовсе не тюрьмой. Вобщем код надо писать по правилам языка и среды а не "хачить". И лучшие практики ООП они как раз стоят именно на этой идее. Кроме того - не существует единого ООП - а есть просто разные его реализации в разных языках. Короче вы не найдете самого-самого-ООП-шного языка.

А вообще если это опнсорц - ну сделайте себе форк и меняйте что хотите в исходниках.

И Еще пример. если объект не будет возвращать никаких данных о себе, то тогда как придерживаться принципа OpenClosed?

Про что вообще OpenClosed? Это - расширенная трактовка ООП в части SOLID (вторая буква О).
Означает что если вы хотите внести изменение в класс - то вы его наследуете. Например
class BMWX5 extends BMW { .. }
Мы ничего не нарушили. Мы не меняли свойств BMW. Мы создали новый класс BMWX5 где есть изменные методы. Оригинальный BMW мы не трогали. Все - в правовом поле.

По Multithreading

"Что выведет следующий фрагмент кода"

Это - самый плохой класс задач на мультипоточку. Я видел много таких. Большинство из них основаны на Race Conditions и бывало и такое что негативный эффект не воспроизводится хотя и ожидается в задаче. А не воспроизводится по тесяче причин. По другой операционке или по другой версии JDK/JRE. Вобщем что
выведет код нужно выкинуть и заменить его на какой-то модульный тест да и еще и под нагрузкой. И беря
во внимание комплексность самого вопроса я-бы не стал такое выводить например в собеседования. Так
можно и мидла макнуть головой в сортир. Попробуйте распознать в коде например задачу обедающих
философов. Я готов спорить на коньяк что если вы никогда не слыхали - то не распознаете подвох.

Где и как подтянуть теорию Multithreading(М). Ответ - нигде. Самый лучший вариант - начать писать много кода
с мультипоточкой и наблюдать. Очень многие эффекты книги не объясняют. И 99% новичек нигде не прочитает
про разницу между использованием synchronized и atomic.

Вобщем берите код с нагрузкой и наблюдайте.

Exe-шник - это конечный продукт после которого уже ничего не делают. Более того. Владелец этого артифакта обычно предпринимает все технические и юридические ходы чтобы ты не мог ничего сделать с файлом кроме как просто его выполнить.

и как будет происходить компиляция минуя среду разработки?

Если хотят пере-использовать какой-то бинарник в API - то создают *.dll и к нему идет спецификация (заголовочный файл *.h) который описывает функции которые внутри. Это - легальный способ переиспользования бинарного кода в Windows.

Что ты там придумал с билдером - непонятно. Возможно ты пытаешся собой подменить компиллятор. Почитай про сборщики (CMake например). Может там будут ответы на твои вопросы.

Да можно. Но обычно объединение идет по модулям приложения. Это упрощает процесс релиза. Например если меняется что-то в модуле работы с физ-лицами - то в релиз должен пойти в лучшем случае 1 артифакт. В худшем случае тебе придется релизить сразу все модули а это хлопотно.

Python - это хороший старт для карьеры, но плохой для ООП.

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

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