Меня часто спрашивают мои слушатели, на какой версии ОС windows на мобильных устройствах может работать мобильная платформа и мобильный клиент платформы 1С: Предприятие 8. Это наглядная демонстрация и ссылки на официальные источники информации, позволяющие получить ответ на данный вопрос. Если у Вас есть коммерческая платформа, Вы можете ее смело использовать. Если Вас смущает веб-сервер Apache, и Вы хотите использовать IIS из состава Windows, это возможно. Но данный ролик это не весть курс а лишь одно практическое занятие. Если человек приходит на первый урок в первом классе и ему вываливают программу обучения даже не за 10 лет а за неделю, у него отпадет всякое желание осваивать данный материал. Не пытайтесь получить ответы на все свои вопросы из данного ролика, а то, что после ролика у Вас появятся дополнительные вопросы, это и есть успех учебного процесса. Желаю Вам успешного освоения данной информации, и наработки практики.
вы говорите что без базовой математической подготовки и знаний основных моментов тут никуда. а что посоветуете перед вашим курсом изучить? что бы всё это понимать.
Перечитал Роберта Мартина. Специально, чтобы убедиться в том, что я правильно понимаю Принцип Отркытоти / Закрытости (OCP). . Так, вот, этот принцип не совсем про Классы и Интерфейсы, наследование и реализацию, и уж тем более, не про «замочки» на классах. Это все, конечно правильно, но, это все частные способы вносить изменения в код, который, кстати, не обязательно соответствует OCP. И применение к нему описанных техник изменения сохранит это свойство кода. . OCP о том, что следуя SRP мы также должны учитывать, что отдельные подзадачи могут иметь разные решения и выделять соответствующие абстракции, защищая этим самым решение общей задачи от изменений, и делая такое решение открытым для расширения. Т.е. OCP — это про декомпозицию кода. Именно, следуя OCP мы должны выделить наши зависимости, т.е. проанализировать, какие подзадачи могут иметь альтернативные решения, оценить вероятность такого измнения, что в свою очередь позволит не плодить лишнии абстракции. . На простом примере: Мы делаем функцию сортировку и используем в алгоритме простую конструкцию: a < b, чтобы понять надо ли нам поменять элементы местами или нет. Мы находимся в рамках SRP (т.е. наш алгоритм имеет одного Актора, решает одну задачу). Но, если нам надо будет реализовать сортировку уже по возрастанию (убыванию), то нам надо будет менять алгоритм, чего собственно мы и хотим избежать. . Так вот OCP говорит нам о том, что наш алгоритм сортировки должен абстрагироваться от реализации отношения порядка (что помимо всего прочего позволит абстрагироваться еще и по типу данных элементов коллекции). . Видео из объяснения OCP вылилось в расказ про DIP, где зависимости нам уже даны. OCP — про выявление зависимостей и создание абстракций. . На 9:20 Сергей дает пример Клиентского класса и Серверного класса, и говорит о том, что это нарушает OCP потому, что мы не можем расширить их взаимодействие. И здесь очень опасная и хитрая ошибка, которая заключается в том, что нам не надо расширять это взаимодействие. Нам надо расширить функциональность, а не взаимодействие отдельных двух компонентов. . В заключении, перефразирую Кота Матроскина: — чтобы инвертировать что-нибудь «ненужное», сначала надо абстрагироваться по этому «ненужному», а мы об этом в видео не говорим…
Не ожидал от тебя конечно…
Кстати, всем советую @evg_shop
.
Так, вот, этот принцип не совсем про Классы и Интерфейсы, наследование и реализацию, и уж тем более, не про «замочки» на классах. Это все, конечно правильно, но, это все частные способы вносить изменения в код, который, кстати, не обязательно соответствует OCP. И применение к нему описанных техник изменения сохранит это свойство кода.
.
OCP о том, что следуя SRP мы также должны учитывать, что отдельные подзадачи могут иметь разные решения и выделять соответствующие абстракции, защищая этим самым решение общей задачи от изменений, и делая такое решение открытым для расширения. Т.е. OCP — это про декомпозицию кода. Именно, следуя OCP мы должны выделить наши зависимости, т.е. проанализировать, какие подзадачи могут иметь альтернативные решения, оценить вероятность такого измнения, что в свою очередь позволит не плодить лишнии абстракции.
.
На простом примере: Мы делаем функцию сортировку и используем в алгоритме простую конструкцию: a < b, чтобы понять надо ли нам поменять элементы местами или нет. Мы находимся в рамках SRP (т.е. наш алгоритм имеет одного Актора, решает одну задачу). Но, если нам надо будет реализовать сортировку уже по возрастанию (убыванию), то нам надо будет менять алгоритм, чего собственно мы и хотим избежать.
.
Так вот OCP говорит нам о том, что наш алгоритм сортировки должен абстрагироваться от реализации отношения порядка (что помимо всего прочего позволит абстрагироваться еще и по типу данных элементов коллекции).
.
Видео из объяснения OCP вылилось в расказ про DIP, где зависимости нам уже даны. OCP — про выявление зависимостей и создание абстракций.
.
На 9:20 Сергей дает пример Клиентского класса и Серверного класса, и говорит о том, что это нарушает OCP потому, что мы не можем расширить их взаимодействие. И здесь очень опасная и хитрая ошибка, которая заключается в том, что нам не надо расширять это взаимодействие. Нам надо расширить функциональность, а не взаимодействие отдельных двух компонентов.
.
В заключении, перефразирую Кота Матроскина:
— чтобы инвертировать что-нибудь «ненужное», сначала надо абстрагироваться по этому «ненужному», а мы об этом в видео не говорим…
Разработчики под Godot: смеются