Возможно я немного запутанно написал, чем мог ввести в заблуждение. Так что постараюсь прояснить этот момент. Интерфейс, по-сути, это публичная морда класса, или подсистемы, т.е., грубо говоря, набор методов, с которыми взаимодействует внешняя среда.
Термин "контракт" же я применяю по отношению к функционалу, который должен быть реализован в классе для того, чтобы иметь возможность включить определенный трейт, т.е. необходимый для его правильного функционирования.
Тут существует принципиальная разница! Несложно придумать пример когда пересечение интерфейса и контракта будет пусто.
Так оно и есть. Чтобы в полной мере прочувствовать это, достаточно посмотреть любую более-менее приличную кандидатскую диссертацию. Недавно листал одну на тему оценки стоимости опционов: полторы странички введения и пятьдесят страниц дифференциальных уравнений, причем очень специфических, со всякими функциями Бесселя и т.п. И как бы, если ты не являешься специалистом в данной сфере науки, очень сложно разобраться что к чему… да что уж там, даже если являешься — очень сложно разобраться.
Занятно! Слышал много хорошего (как и немного плохого) о Scala, но никак руки не доходили.
А касательно «модной фишечки», слышал в одном докладе занимательную аналогию: PHP — язык-пират, он крадет у других языков и присваивает себе. И смешно и грустно.
Если подойти к вопросу строго, то трейты в PHP не охватывают полностью понятие «примесь». Трейт PHP это, скажем так, статическая примесь, которая применяется по отношению к классу. Но мы также можем реализовать механизм «подмешивания» по отношению к объектам, т.е. в рантайме, и тут тоже мы имеем дело с примесью, но это уже не будет трейт.
В целом, конечно, да: и трейты, и примеси, и модули — это об одном и том же, однако есть нюансы.
Ну, можно и не называть. Однако называть все же удобнее, тогда текст читать проще ;) Если Вас конкретно слово «контракт» не устраивает, предложите более подходящую альтернативу.
Не вижу противоречий. Просто в Ruby примеси это, грубо говоря, модули; в PHP — это типажи. Однако примесь, это на мой взгляд, более широкое понятие, т.е., типажи это примеси, но не все примеси — типажи. Я же хотел привести наиболее конкретное и практичное сравнение.
Ну, в принципе то, о чем я написал это не Rocket Science, и на откровение не претендует. Похожая концепция уже давно есть в Ruby, только называется по-другому (модули). Правда, на мой взгляд, у типажей перед модулями есть одно преимущество — можно явно объявить контракт.
Касательно стандартов проектирования это конечно вопрос открытый, но хорошие примеры использования можно найти в Ruby on Rails.
Если Вы обратите внимание, мой ответ был не к предложенному Вами решению. Я просто прокомментировал Ваше категоричное высказывание относительно использования хеширования для решения задачи, имея в виду, что не все так однозначно.
Касательно той же асимптотики, если уж на то пошло, то разница между O(n) и O(n log n) почти незаметна, если Вы не работаете с системами реального времени. Например ln (1 000 000) =~ 13. Можете построить графики и убедиться, что n*log n ведет себя почти линейно.
Касательно String.hashCode(), если я не ошибаюсь, уже при 30 000 элементов вероятность коллизии будет около 10%. Это не так уж и мало, чтобы игнорировать.
Можно, конечно, придумывать что-нибудь кустарное, а можно свести задачу к выделению компонент связности графа — главное тут ребра правильно расставить. Т.к. ребер будет не более чем 4*<кол-во клеток> (вроде бы), то решаться она будет за O(<кол-во клеток>) = O(cols*rows).
Если не сортировать, то проверка вхождения в список каждого слова будет за O(n), для n слов сложность будет O(n^2).
Если сначала отсортировать, например, HeapSort'ом, Timsort'ом или даже QSort'ом (в случае, если данные не подобраны специально, чтобы нагнуть QSort), то сортировка за O(n*logn) + слияние за O(n), итого O(n*logn), а это гораздо лучше, чем O(n^2).
Вот картинка (обратите внимание, что шкала логарифмическая; с равномерной шкалой уже при n=100 Вы увидите только один график n^2):
Рассмотрите чуть более далекую перспективу, чем первый месяц-два работы над проектом. Со временем время на ручное обновление БД при деплое приложения, или приведение тестовой БД в актуальное состояние будет занимать гораздо больше времени, чем Вы секономите при написании миграции (опять же, через пару недель написание миграции занимает не больше времени, чем соответствующии инструкции SQL).
Это я уже не говорю о том, что при «ручном» версионировании БД практически невозможно использование CI для Вашего проекта. Да и в целом, автоматизация процесса — дело благое, в идеале нужно добиться, чтобы можно было развернуть проект одной командой в консоли.
К тому же, закладываясь на то, что «проект делаю сам, зачем мне лишние трудности», Вы обрекаете себя на гораздо большие проблемы, когда, в случае успеха Вашего проекта, команда неминуемо пополнится новыми людьми.
Интерфейс, по-сути, это публичная морда класса, или подсистемы, т.е., грубо говоря, набор методов, с которыми взаимодействует внешняя среда.
Термин "контракт" же я применяю по отношению к функционалу, который должен быть реализован в классе для того, чтобы иметь возможность включить определенный трейт, т.е. необходимый для его правильного функционирования.
Тут существует принципиальная разница! Несложно придумать пример когда пересечение интерфейса и контракта будет пусто.
А касательно «модной фишечки», слышал в одном докладе занимательную аналогию: PHP — язык-пират, он крадет у других языков и присваивает себе. И смешно и грустно.
В целом, конечно, да: и трейты, и примеси, и модули — это об одном и том же, однако есть нюансы.
Касательно стандартов проектирования это конечно вопрос открытый, но хорошие примеры использования можно найти в Ruby on Rails.
Касательно той же асимптотики, если уж на то пошло, то разница между O(n) и O(n log n) почти незаметна, если Вы не работаете с системами реального времени. Например ln (1 000 000) =~ 13. Можете построить графики и убедиться, что n*log n ведет себя почти линейно.
Касательно String.hashCode(), если я не ошибаюсь, уже при 30 000 элементов вероятность коллизии будет около 10%. Это не так уж и мало, чтобы игнорировать.
К тому же нельзя забывать, что O — это не только асимптотика, но и константа, а константа может быть очень большой.
Если сначала отсортировать, например, HeapSort'ом, Timsort'ом или даже QSort'ом (в случае, если данные не подобраны специально, чтобы нагнуть QSort), то сортировка за O(n*logn) + слияние за O(n), итого O(n*logn), а это гораздо лучше, чем O(n^2).
Вот картинка (обратите внимание, что шкала логарифмическая; с равномерной шкалой уже при n=100 Вы увидите только один график n^2):
Это я уже не говорю о том, что при «ручном» версионировании БД практически невозможно использование CI для Вашего проекта. Да и в целом, автоматизация процесса — дело благое, в идеале нужно добиться, чтобы можно было развернуть проект одной командой в консоли.
К тому же, закладываясь на то, что «проект делаю сам, зачем мне лишние трудности», Вы обрекаете себя на гораздо большие проблемы, когда, в случае успеха Вашего проекта, команда неминуемо пополнится новыми людьми.