Сергей Протько

основной — наследование.

Наследование типов а не классов. То есть через интерфейсы.

В Java нет множественного наследования.

В Java есть возможность делать композицию типов путем имплементации множества интерфейсов. А с учетом того что в Java8 у вас теперь есть возможность делать "дефолтные" имплементации методов в интерфейсах - у вас есть "правильное" наследование.

Через некоторое время, этот класс захотят расширить по OCP — унаследуются, и сделают класс Бармен.

А как потом быть если мы захотим сделать робота бармена? Я это к тому что "человек" не всегда будет являться базовым типом "бармена".

В целом Dmitry Roo вам верно сказал. "Бармен" это профессия. Свойство человека. У человека может быть много профессий:

class Human
{
    Profession[] professions;
}

Таким образом мы можем крутить и вертеть как хотим.

и как отдельный класс-синглтон

Зачем? Зачем сингелтон? Ответте на вопрос когда это нужно?

Есть ли практики, которым следует придерживаться, чтобы сделать правильную и простую архитектуру?

- Разделение ответственности - важный принцип инженерного дела в принципе.
- Принципы SOLID - хорошо дают понять как работать с зависимостями и делать декомпозицию системы. Сильно пересекается с инкапсуляцией, полиморфизмом и разделением ответственности.
- Паттерны GRASP - эдакая смесь принципов и паттернов, описывают нюансы цикла жизни объектов и их взаимодействия друг с другом.
- Закон Деметры - про инкапсуляцию.
- CQRS - подход по разделению операций записи и операций чтения. Естественно подход такой не работает если вам надо реализовать атомарную запись и чтение, но это минимальный набор задач.
- Рефакторинг. Он нужен всегда. Его нужно делать по чуть-чуть когда видно что "уже мешает" или "можно было сделать лучше". Ну то есть это не переписывание всего и вся большими кусками, а маленькие изменения которые с течением времени эволюционно меняют архитектуру проекта. Возможно только если код покрыт тестами, это отдельная жирная тема.

Не нужно знать "архитектуры", они являются лишь результатом соблюдение принципов. И уж тем более "паттерны" это лишь элементы архитектуры. Не нужно на них зацикливаться, это лишь словарь.

https://en.wikipedia.org/wiki/Category:Programming...

Для начала упростим JDBC до общего случая Data Access Object (DAO).

Суть DAO сводится к тому, что у нас есть объект, инкапсулирующий в себе работу с хранилищем данных. Ну то есть весь SQL и все детали работы с хранилищем вшиты в него. Причем их может быть множество (не пихать же вообще всю работу с базой данных в один объект).

Словом, основная задача DAO - предоставить механизм работы с базой данных скрывая детали внутри себя.

ORM (Object-relational mapping) - это, если опять же упростить, общая идея конвертации "объектов" между системами с несовместимыми типами. Ну то есть как объекты из базы мэпятся на объекты.

Если под ORM брать мощные реализации вроде Hibernate, то тут становятся очевиднее минусы конкретно этой реализации. А именно - работать это будет эффективно когда вам нужно построить объектную модель логики приложения, нежели модель данных. Такие подходы хорошо работают в приложениях с реально сложной логикой, где вам бы хотелось в коде передать суть того, как все работает в реальности. Например как именно происходит автоматизация бизнес процесса. С реальными объектами и т.д.

Для вещей вроде генерации репортов ORM такого плана приносят больше вреда чем пользы. ORM очень хорошо работают в операциях на запись, ито только если речь идет о взаимодействии небольшого количества объектов (пара сотен например, или десятков но не тысяч), когда логика взаимодействий этих объектов сложная, или правил много. Если вам скажем нужно обновить все значения в таблице - сделать это через SQL намного удобнее.

Ну и в целом, ORM и DAO это весьма разные концепции, они о разных вещах. То есть у вас может быть использовано и ORM и DAO. Или ORM внутри использующее DAO... это не столь важно.

Что такое адаптер?

Смотрите. Есть у вас например micro USB кабель. И есть дырка в новом макбуке - Usb type c. Друг в друга они, как вы понимаете, не втыкаются. И можно взять адаптер microUSB -> USB type-c.

В этом суть адаптера. Конвертация интерфейсов. Мы сделал интерфейс штуки которая нам нужна, потом взяли готовую штуку которая вроде бы то что нам надо делает, и сделали адаптер, который закрывает нестыковки в интерфейсах.

Таким образом если вдруг через месяц обнаружатся проблемы, вы сможете заменить "готовую штуку" на другую готовую, сделать другой адаптер, и все. Изменения с точки зрения кода, который использует нужный нам интерфейс, будут только в используемом адаптере.

За счет этого достигается независимость.

Что значит "принимает зависимость"?

Предположим у нас есть метод для смены пароля юзера. Что бы это безопасно провернуть, нам надо пароль захэшировать и хранить в захэшированном виде. То есть нам нужна какая-то штука, которая будет эти пароли хэшировать. Мы о ней знать ничего не хотим, хотим что б нам ее давали:

public function changePassword(string $password, PasswordEncoder $encoder)
{
    $this->password = $encoder->encode($password);      
}

Это зависимость нашего метода. Он зависит от него. Диалог между объектами можно представить себе такой:

- Слыш, поменяй пароль на этот
- Оке, только хэшер паролей мне дай, мне очень надо
- А какой тебе?
- Да любой с этим типом
- Ну ок. На вот пароль и хэшер. Делай дела.

Что такое вообще эта зависимость?

Зависимости - это все что мы используем чтобы сделать дела. Это не только библиотечки, но и просто классы, функци и т.д. Весь "сторонний" код с точки зрения нашего кода. И самое важное в том, что "нашим" кодом является тот, над которым мы работаем в данный момент времени, а не все что мы написали. Даже функции, которые есть в языке программирования из коробки являются зависимостями. Вот только от них вам не деться никуда особо, а потому с ними замарачиваться не стоит. Или если есть долговременная поддержка у библиотеки и она устаялась - тоже можно просто использовать. А вот если это поделка на гитхабе с 10-ю звездочками и там до сих пор нет ни одного релиза - но она вам вот очень нужна, возможные поломки в ней (а они рано или поздно будут) стоит "закрыть" адаптером что бы потом поменять на что-то получше или обновить без боли.

Сколько нужно мне проработать в организации чтобы стать Middle если сейчас я Junior?

я видел людей которые за 5 лет в "организации" настолько остановились в развитии что как были джунами так и оставались.

Джуниор - решает стандартные задачи без вопросов с незначительными рисками.
Мидл - решает нестандартные задачи с высокими рисками. Стандартные делает быстрее и с меньшим количеством багов.
Синьер - решает нестандартные задачи с незначительными рисками то есть меньшим количеством багов. Могут менеджить людей или проекты с технической точки зрения.

Вот и прикидывайте.

C# .NET для windows максимально эффективны. Если же вам нужна кросплатформенная разработка - уже можно думать.

С другой стороны есть куча других вариантов, вроде html5 + js.

Это умеют все серьезные IDE (VisualStudio, Jetbrains CodeLion и т.д.)

Плюсы:

Си это сила. У него пока нет конкурентов в системном программировании (разве что rust подкрадывается и D, но они чуть на другие вещи ориентированы).

Минусы:

Сегодня Си это специфика. Это либо системное программирование (разработка драйверов, низкоуровневых вещей, баз данных, интерпритаторов, компиляторов) либо микроконтроллеры и т.д. Так же есть определенные задачи для которых критически важна производительность, там и ассемблер иногда используют, но скоро перейдут на FPGA.

То есть знание Си = знание архитектуры комьютера, а это уже неплохо и пригодится. Сам же язык относительно простой и много времени на его изучение не потребуется.

Если же вас интересуют более мэйнстрим вещи вроде web или мобильная разработка - проще сразу брать какой-нибудь современный динамический язык (python, javascript) и радоваться жизни.

Вот проектируя большой проект с нуля ты уже оперируешь не паттерновыми объектами а частами систем

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

Большие проекты начинают проектировать с более высокого уровня. Сначала принимают решение о том, какое разделение на слои у нас будет (для проектов со сроками жизни ~10+ лет имеет смысл позагоняться и вводить гексагональную архитектуру, для проектов со сроками жизни <= строк поддержки фреймворка можно не сильно париться), какие компоненты можно выделить, а уже потом дробить эти большие компоненты на компоненты поменьше.

Затем уже приступать к проектированию каждого отдельного компонента на уровне классов.

Так же если у нас сложная предметная область - проектируют модель предметной области. Обычно тут "паттерны" сами собой получаются тупо при снижении связанности между объектами.

> Собственно вопрос: существует ли сборник всех этих лучших практик?

вне контекста не бывает лучших практик, есть просто практики. В этом плане можно например Фаулера почитать, он очень качественно описывает практики, их плюсы и минусы.

В целом же я бы рекомендовал вам познакомиться поближе с принципами SOLID и GRASP. Последнее мало кто знает, но понимание, например, что такое высокое зацепление, сильно влияет на то, как вы будете проектировать систему.

Это правило необходимо для того, что бы код удобнее читался (что бы не приходилось пользоваться горизонтальным скролом, и вертикального хватает). Вглянул на код - и все видно.

Других причин следовать этому правилу особо нет. Я стараюсь придерживаться этого правила и для html, делая переносы строк в случае с большим количеством аттрибутов.

1) BLOB
2) запаковать в int32