Pull to refresh
57
0.5
Михаил @michael_v89

Программист

Send message

он как раз и рассказывает, что привычное объяснение "по- бернулли" - это просто затянувшийся многолетний обман

И? Какой из этого вывод?
Он там не говорит, что уравнение Бернулли неправильное, и его вообще нигде не надо применять. Он говорит, что его не надо применять конкретно в этом случае.

где тоже всё не очень корректно показано

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

и непонятно что при этом доказывается

Ну я почему-то понял, что там доказывается. Там все довольно понятно объяснено.

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

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

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

убегающей теневой стороны крыла

Я не знаю, что такое "убегающая теневая сторона". На видео стороны крыла никуда не убегают. Если вы имеете в виду верхнюю часть, то там молекулы бьются в крыло под более острым углом и под меньшей скоростью, а также их количество меньше. А снизу 2 линии дыма сливаются в одну. Наверно и воздух, в котором они находятся, уплотняется.

КАКИМ ИМЕННО МЕХАНИЗМОМ создается эта разница давлений над и под крылом?

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

Вот тут есть видео с дымом, которое показывает как движется воздух и как что ударяется в крыло с разных сторон. Также можно почитать описание к видео на YouTube.

К чему такой вопрос вообще ?

Да человек считает, что теплового движения молекул нет, а они просто статично лежат друг на друге. Вот и выискивает якобы несоответствия общепринятых теорий. Объяснения, что он понимает термины не так, как понимают другие люди, он не воспринимает.

Или например считает, что раз Солнце притягивает Луну в 2 раза сильнее чем Земля, то Луна должна была давно улететь на Солнце. Объяснения, что Солнце притягивает еще и Землю в 100 раз сильнее, чем Луну, и она на него падает вместе с Луной, игнорирует.

В написанных примерах, это не часть библиотеки

Так разговор то был про внешние библиотеки. Вы же сами процитировали это предложение. Именно в этом и проблема с описанием исключений в интерфейсах.

код точно знает какое исключение будет при работе с хранилищем

Так нам это знание бесполезно. Я и так знаю, что любое исключение при работе с интерфейсом хранилища можно считать StoreException. Я могу ловить просто Throwable, результат будет тот же самый. Точно знать надо конкретные исключения, например когда мы хотим задать конкретную обработку именно для NetworkException. А если любое исключение это StoreException, то в какой ситуации это полезнее, чем просто Throwable?

задача разбираться с внутренними исключениями библиотек лежит на обертках этих библиотек - в примерах это AbstractStorage/LocalStorage/FtpStorage

Нет, LocalStorage и FtpStorage это функциональность сторонней библиотеки. Именно за этим мы ее и подключаем. Они реализуют один интерфейс. Вы говорите, что авторы этой библиотеки должны в этом интерфейсе указывать только StoreException. А это может быть не всегда быть удобно, часто нам нужно обработать конкретные ошибки, которые может выдавать конкретная реализация.

Там где catch (NetworkException $t) можно ретраить, уведомлять

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

и уровнем выше делать getPrevious()

Ну а тогда зачем нам StoreException, какая от него польза? Тогда вышележащий код будет знать про исключения зависимостей, а вы говорите, что не должен, из-за чего и надо делать StoreException. Также в этом случае в интерфейсе не задокументировано, что может быть в getPrevious(), что ничем не отличается от исходной ситуации, которую мы хотели исправить.

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

Естественно. В одной логике при NetworkException нам надо повторить операцию, в другой не надо, в третьей надо положить в очередь и повторить позже.

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

Ну вот у вас есть драйвер локальной файловой системы и драйвер FTP. Второй может выбрасывать NetworkException, а первый нет. Что во что надо кастить? При этом вызывающий код по NetworkException может попробовать повторить операцию, а по AccessDeniedException в этом нет смысла.

Легче писать тесты замокав эти интерфейсы.

Класс мокается точно так же, как и интерфейс.

очень просто на основе контракта, описанного в интерфейсе, подменить реализацию на новую

Ну а почему нельзя это сделать когда у вас действительно появится новая реализация? Зачем надо делать это заранее и постоянно поддерживать?

Позволяет разрабатывать отталкиваясь от интерфейса.

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

С интерфейсом не работает функция IDE "Go to definition", приходится постоянно еще раз нажимать сочетание для "Go to implementation", чтобы перейти к реализации. Еще при изменениях сигнатуры методов надо в интерфейсе тоже обновлять. Это усложнение поддержки, а не упрощение.

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

Если в месте использования класса по какой-то причине не подходит его реализация, его легко заменить другой.

Ну а зачем вам для другой реализации тот же интерфейс? Интерфейс нужен когда для разных реализаций нужно гарантировать одинаковое поведение, например для драйверов базы данных или файловых систем. А когда сервис используется в специфичной логике в одном месте, там интерфейс не нужен. Новая реализация может иметь публичные методы, более подходящие для конкретной логики, нет необходимости придерживаться интерфейса, который был придуман в начале проекта.

Чем меньше методов в интерфейсе, тем лучше.

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

Вот есть у меня какая-то библиотека для HTTP запросов, они сделали себе MyHttpClient\NameAwareInterface, и что, я должен в бизнес-логике использовать зависимость от MyHttpClient? А если нет, у меня будет 2 интерфейса NameAwareInterface, а может и 10, фиг поймешь где какой использовать.

Интерфейс должен описывать методы управления и взаимодействия. Принципы группировки методов в интерфейс такие же, как и группировки методов в класс.

В интерфейсах указываем какие exception могут быть выброшены

Говорят, это пробовали в Java, и решили, что это была ошибка.
Драйвер локальной файловой системы не может выбрасывать NetworkException, а драйвер Amazon S3 может. Что в интерфейсе писать?

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

Если аргументов много - значит метод выполняет слишком много действий

Нет, не значит.

Класс меньше ~150 строк, метод меньше ~30 строк. Это значительно упрощает чтение кода.

Нет, не упрощает. Я читаю не просто так, а чтобы понять логику. Если она разбросана по разным местам, то понимать ее сложнее. Разбивать надо по логическим границам, а не по количеству.

По умолчанию указываем final для классов. Такое правило позволяет избежать проблем с наследованием и поощряет использование композиции.

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

Соблюдаем закон Деметры
$this->clientDecorator->send();

Использовать декоратор только для уменьшения стрелочек это в корне неверный подход. От того, что вы добавили обертку, программисту, который читает этот код, понятнее не стало. Теперь ему еще надо разбираться, как эта обертка работает.

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

Декоратор можно использовать например для добавления логики, когда нет возможности поменять реализацию. В коде своего проекта как правило не нужны.

Ну так если отрицательных чисел нет, то и не было необходимости приводить в пример именно i, можно было и про -1 сказать) Я предположил, что раз вы привели i, то считаете отрицательные числа более реалистичными, чем i.

А вообще например заряды протона и электрона отличаются знаком, что выражается в разном поведении в электрическом поле. И про массу разговор идет в контексте аналогии с зарядами.

То. Я не сказал, что изменение скорости влияет на искривление. Ускорение это изменение скорости. Оно заметно невооруженным глазом, даже если предмет падает с небольшого расстояния. В первую секунду предмет длиной 4.9 метра проходит 4.9 метра, во вторую 4.9*3 метра. Расстояние увеличилось в 3 раза, а его наблюдаемые размеры не изменились в 3 раза. Никаким искривлением линии равномерного движения нельзя достичь такого эффекта. Я сказал, что если бы пространство было искривлено, то и размеры тел менялись бы соответственно, то есть в 3 раза на второй секунде. Релятивистское изменение размеров тут ни при чем.

Просто для скоростей в окружающем вас мире это изменение незначительно.

Ну так я об этом и говорю. Изменение длины незначительно, а изменение скорости значительно. Значит наблюдаемое изменение скорости не связано с искривлением пространства.

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

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

Так оно должно соответствовать наблюдаемому ускорению. Тело длиной 1 метр равномерно прошло 1 метр в собственной системе координат. Его дальняя точка перешла в позицию, где была ближняя. Для наблюдателя снаружи длина тела не меняется, а позиции точек не совпадают, для наблюдателя оно прошло больше собственной длины. Значит предположение об искривлении пространства неправильное. Наверно можно сказать, что искривляется только время.

Я не понимаю, почему отрицательная масса обязательно должна лететь навстречу. Все наши формулы сделаны для положительной массы. Если отрицательная масса существует, возможно какие-то формулы надо будет скорректировать. Вполне может быть так, что знак массы влияет только на поведение в гравитационном поле, а при разгоне она ведет себя аналогично обычной массе.

Если оператор Гамильтона становится отрицательно-определëнным

Ну так откуда вы знаете, что там действительно должна быть масса со знаком, может Вселенная устроена так, что там должен быть модуль. Примерно как sqrt(m^2).

а длиной i см - это как

Так i само по себе это не число, а операция поворота. Поэтому нельзя сказать, что есть отрезок длиной в 1 поворот, как и нельзя сказать, что есть отрезок длиной в 1 умножение.

На числовой плоскости есть только положительные длины и положительные углы поворота.
Если рассматривать число на числовой плоскости 1i^1, то в его записи задана длина 1. Запись (0+1i) это сложение 2 векторов (0i^0 + 1i^1), у одного длина 0, у другого 1.

Можно конечно представить, что это число на числовой плоскости задает какую-то длину, но тогда такой вектор такой длины из точки 0 будет лежать не на этой плоскости, а будет уходить в 3 измерение. Или можно сказать, куда-то вглубь точки 0.

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

Вообще, мне кажется, если бы само пространство было искривлено, то и размеры тел менялись бы соответственно.

Ну как это не соответствует, ей соответствуют любые повороты. Так же как положительным числам соответствует количество любых предметов. i это просто половина минуса. Если мы считаем, что отрицательным числам что-то соответствует в физическом мире, то и числам с i соответствует.

1
23 ...

Information

Rating
1,498-th
Location
Россия
Registered
Activity