MrCreame

Нет.

Полиморфизм, как следует из названия, это когда что-то маскируется под что-то другое. Это свойство системы типов языка на котором вы пишите, он может позволять вам делать вещи, маскирующие свой внешний вид ("названия") но все же это не та же вещь. Ну и стоит заметить что у полиморфизма есть еще разные виды. Например:

Параметрический полиморфизм. Это когда мы можем написать один код, с одним набором имен, которые работает с разными типами аргументов. Пример - шаблоны из C++ или дженерики в Java. То есть "имена" методов одинаковые, потому что они в одном экземпляре. Реализация одна, одно поведение. А вот аргументы могут отличаться.

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

Полиморфизм подтипов. При этом у нас как раз таки будет одни и те же имена и может быть совершенно разное поведение. Например мы можем создать какой-то базовый тип, который, к примеру, отправляет email-ы, и создать его подтип, который вместо отправки email-ов записывает в лог то что мы хотели отправить, после чего уже отправляет данные дальше другому объекту этого типа (шаблон проектирования декоратор).

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

Ну и еще есть одно серьезное ограничение. Если мы хотим заменить в системе объект какого-то типа на объект подтипа (грубо говоря наследника), то система не должна сломаться. То есть "другое" поведение нашего подтипа должно быть совместимо в плане интерфейса с базовым типом. Об этом можно почитать загуглил "Принцип подстановки Барбары Лисков".

Ad-hoc полиморфизм - это пожалуй самый интересный вид полиморфизма с которым можно долго холиварить. По сути при этом виде полиморфизма, у нас одинаковые имена, а поведение зависит от входящих аргументов. Пример - перегрузка методов в C++. Интересен этот вид полиморфизма в основном тем, что он не является "настоящим".

При динамической системе типов не требуется никаких дополнительных возможностей вроде той же перегрузки методов для достижения ad-hoc полиморфизма. Тупо кидаем что хотим в функцию, а там уже if-ами рагребаем или же приводим к какому-то одному варианту. Отдельные конструкции нужны в языках со статической системой типов. То есть нам нужно еще на этапе компиляции кода знать какие именно типы могут приходить в наши методы, и в зависимости от оных вызывать тот или иной код.

Среди PHP-разработчиков немало тех, кто мечтает увидеть в этом языке с динамической системой типов честную перегрузку методов как например в Java или C++. Просто так, потому что if-ы это плохо и лучше уж пусть они будут неявные на уровне компилятора/рантайма.

Полиморфизм с приведением типов - еще один вид "не настоящего" полиморфизма. Мы "эмулируем" полиморфизм за счет того, что на уровне рантайма языка происходят касты действительного в желаемое. Например в PHP мы можем выставить у функции тайпхинтинг string, и можем внутри иметь одно и то же поведение для всех входящих аргументов. Передать же в качестве аргумента мы можем все что можно скастить в строку.

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

Любой фреймворк с инверсией зависимостей подойдет. На Symfony и Yii2 точно можно сделать. На русскоязычном форуме Yii по теме DDD очень много обсуждений. Но если не увидели единого согласия по DDD, то скорее всего не читали книгу Эванса или Вернона. Если так, то лучше начать с кого-нибудь из них.

Многоуровневая архитектура рассказывает нам о слоях presentation, application, domain и infrastructure. С однонаправленным потоком данных. Нижестоящий слой, никогда не должен вызывать вышестоящий. Это значит, что к примеру можно выбросить presentation слой и не придется ничего изменять в оставшихся 3.

Фактически выходит, что в любой момент можно выбросить фреймворк и заменить другим, так как это presentation layer в многоуровневой архитектуре. Можно даже сначала написать application/domain, проверить их юнит-тестами, а только потом уже задуматься о фреймворке. Application/domain слои никогда ни при каких обстоятельствах не должны вызывать методы фреймворка. Контроллеры фреймворка работают с доменной моделью, через вызовы методов application layer.

Соответственно, при миграции на другой фреймворк, всё что потребуется, это переписать контроллеры (методы очень простые 1-5 строк) и реализации классов в infrastructure layer если вы завязывали их на фреймворк. Хотя лично я бы, не советовал этого делать. Лучше найти/написать отдельные библиотеки/компоненты под инфраструктурный слой, тем самым облегчив себе жизнь в будущем, когда фреймворк умрет или при очередном релизе мажорной версии.

Symfony под DDD наилучший выбор, он компонентный, можно подтянуть только то, что нужно. С другой стороны Yii2, он монолитный и вы затяните Active Record и кучу всего еще, чем не будете пользоваться, но джуниор придет и обязательно понавызывает AR или чего-нибудь еще в application/domain слоях, чего вы явно не ожидаете. Поэтому в случае с Yii2 нужен будет тотальный контроль. :)

Про Laravel не пишу ничего, так как не работал с ним. Но судя по беглому просмотру документации, никаких проблем сделать на нем DDD также нет.

1. А как вы себе представляете обращение к объекту во время компиляции, когда этого объекта даже не существует? Это ж абсурд. Конечно, оно происходит во время выполнения, когда инстансы этих объектов созданы и существуют.
2. Не важно, на что это влияет, когда это верный подход. Лучше процент потерять на производительности, чем поломать инкапсуляцию и полиморфизм и писать говнокод.
3. Да, в 99% нужно использовать её, ибо это нативная для многих языков реализация Принципа подстановки Барбары Лисков из паттернов SOLID.

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

Правильно думаете, многие забивают на это понимание, а потом говнокодят со всякими switch instanceof.

Вообще, в хорошем ООП дизайне, когда вы встречаете стопку поведенческих if'ов, больше 5-7 штук, switch'ей, и так далее, то в этом месте стоит задуматься об использовании диспетчеризации, ибо они, в подавляющем большинстве случаев, заменяемы в пользу более гибкого и адекватного ООП-дизайна. Но, не фанатично всё подряд менять, конечно же =)

Я тоже долго не мог понять.
Подобрал такую аналогию - это как git для сервисов.
Например чтобы развернуть Elasticsearch надо установить яву - это отдельная эпопея, затем прописать репу эластика, сделать apt-get update, apt-get install, прописать в автостарт, установить плагин с русской морфологией, рестартануть эластик.
А можно один раз напистаь докер файл из двух строчек и потом одной командой "docker run yourlogin/elasticsearch" все это запускать на любой машине.

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

Докер - это двойная изоляция. Изоляция того, что лежит внутри контейнера Докера от операционной системы и изоляция операционной системы от того, что лежит внутри Докер. Изоляция подразумевает изоляцию всех файлов, портов, приоритетов.

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

Контейнеры существовали и до Docker. Докер, строго говоря, это всего лишь очень удобный набор инструментов, собранных воедино, для управления контейнерной виртуализацией. Но очень удобный.

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

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

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

Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

Это позволяет гарантировать гораздо большую идентичность среды разработки и среды исполнения.

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

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

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

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

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

Со своими репозиториями на гитхабе работаю через hg (с помощью hg-git). С чужими — через git.

Что тут можно сказать — использовать hg как клиент к гитхабу можно, и интерфейс командной строки у hg поприятнее, чем у git, но много тонкостей: есть штуки в hg, у которых нет аналогов в гите (named branches) и поэтому полноценного преобразования hg <-> git не получается; у hg-git бывают глюки, и он не все фичи поддерживает. Подход этот точно не для человека, который только взялся за системы контроля версий; чтоб его использовать, нужно достаточно хорошо как hg, так и git знать, и работает он хорошо только для несложных репозиториев (у меня там несколько коммитов в месяц, в основном линейные репозитории).

Если хотите размещать репозитории на github, git выучить смысл есть в любом случае.

Опыт нужен. Хотя бы лет 5. В общем, сеньйор даже не столько должен хорошо уметь писать код, сколько видеть риски и принимать решения, которые точно не повредят проекту. Я думаю, С++ программера можно считать сеньйором, когда он способен принимать решения типа:
1. Выбор IDE, компилятора, версии языка.
2. Написать с нуля или взять готовое.
3. Юзать STL\Boost\MFC\ATL\Qt или нет. Если да — что лучше в данном случае и почему.
4. Стоит отрефакторить код или нет.
5. Написать самому\отдать Juniory
и т.д.

Ах да, еще важный признак «сеньйорства» — осознание того факта, что для программиста на С++ не должно быть невозможных вещей. Какой-нибудь там Java или .NET программер может сказать что-то типа «это ограничения платформы.», «программа тут не может кушать меньше вот такого количества памяти», «это перехватить нельзя — код в недрах ОС\платформы». C++ сеньйор должен быть способен докопаться, разобрать и отладить всё — вплоть до системных библиотек, драйверов и BIOSа.

статьи:
www.robocraft.ru/blog/ARM/
mycontroller.ru/
easystm32.ru/
ziblog.ru/category/stm32/
we.easyelectronics.ru/tag/STM32/

форумы:
electronix.ru/forum/
forum.easyelectronics.ru/
caxapa.ru/

отладочные средства:
stm32f3-discovery — наиболее подходящее решение для коптера на основе stm32 (на борту сам микроконтроллер, отладчик, гироскоп, акселерометр с магнитометром-компасом). На эту плату портирован автопилот OpenPilot

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