Может ли быть дело в разных gorw-factor-ах списков? На примере с растом создавать массив как Vec::with_capacity(num_tasks) вместо Vec::new(). Хотя может и сам компилятор это отлавливает и оптимизирует.
Как раз таки на практике они и отличаются. Методы — динамические, ассоциативные функции — статические (static говорит само за себя).
Ваш пример был бы актуален для Rust, так там, методы — просто синтаксический сахар, на деле простые функции, принимающие первым аргументом ссылку на объект, и можно вызывать как
object.do_something()
так и
Object::do_something(&object)
Плюс в тоже время можно переопределить как и простую функцию так и метод, у интерфейся (трейта). В Java же все сильно отличается.
Помню как многие говорили, что в Java использование static методов — это зло, приветствуется только пацанский ООП. Я пытался докопаться, почему так, и приходил к тому, что проблема лишь в ограничениях языка, ведь в java не получится переопределить static метод или замокать его. Но я так и не встретил ни одного Java знатока, который бы первым делом признался, что это не функциональный подход плох, а сама реализация.
Может ли быть дело в разных gorw-factor-ах списков? На примере с растом создавать массив как
Vec::with_capacity(num_tasks)вместоVec::new(). Хотя может и сам компилятор это отлавливает и оптимизирует.Как раз таки на практике они и отличаются. Методы — динамические, ассоциативные функции — статические (static говорит само за себя).
Ваш пример был бы актуален для Rust, так там, методы — просто синтаксический сахар, на деле простые функции, принимающие первым аргументом ссылку на объект, и можно вызывать как
так и
Плюс в тоже время можно переопределить как и простую функцию так и метод, у интерфейся (трейта). В Java же все сильно отличается.