Почему Scala содержит статические элементы внутри класса?

Ответ 1

Я также разместил этот вопрос в группе пользователей scala google group и Bill Venners, один из авторов ответа "Программирование в scala" имел некоторые идеи.

Взгляните на это: https://groups.google.com/d/msg/scala-user/5jZZrJADbsc/6vZJgi42TIMJ и https://groups.google.com/d/msg/scala-user/5jZZrJADbsc/oTrLFtwGjpEJ

Вот выдержка:

Я думаю, что один цель заключалась просто в том, чтобы быть проще, имея каждое значение как объект, каждая операция вызывает вызов метода. Статичность и примитивы Java особые случаи, что делает язык более "сложным" в некоторых чувство.

Но другой большой, я думаю, должен иметь что-то, что можно сопоставить Java statics в scala (потому что scala нужна какая-то конструкция, которая отображается для Java-статики для взаимодействия), но это выгодно для OO наследование/полиморфизм. Объекты Singleton являются реальными объектами. Они могут расширять суперкласс или микс в чертах и ​​проходить как таковой, но они также "статичны" по своей природе. Это оказывается очень удобным в практика.

Также взгляните на это интервью с Мартином Одерским (прокрутите вниз до объектно-ориентированных инноваций в разделе scala) http://www.artima.com/scalazine/articles/goals_of_scala.html

Вот выдержка:

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

Подводя итог:

С точки зрения функционального программирования статические члены обычно считаются плохими (см. этот post Гиладом Брача - отцом дженериков java. делать с побочными эффектами из-за глобального состояния). Но scala должен был найти способ взаимодействия с Java (поэтому он должен был поддерживать статику) и минимизировать (хотя и не полностью избегать) глобальные состояния, созданные из-за статики, scala решили изолировать их в сопутствующие объекты.

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

Ответ 2

O в OO означает "объект", а не класс. Объектно-ориентированный - это все объекты или экземпляры (если вы предпочитаете)

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

Scala, с другой стороны, является объектно-ориентированным. Это гораздо больше, чем Java, которые особенно старались вести себя как С++, чтобы привлечь разработчиков с этого языка.

Это хак, изобретенный С++, который стремился преодолеть миры процедурного и OO-программирования и должен был быть обратно совместим с C. Он также признал примитивы по тем же причинам.

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

Относительно того, почему это важно для действительно OO, я собираюсь бесстыдно копировать и вставлять этот фрагмент из Bill Venners в список рассылки:

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

Не мог бы лучше сказать себя!

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

По моему опыту вы склонны использовать эту способность гораздо больше, чем вы изначально думали, особенно после того, как вы использовали Scala какое-то время.

Ответ 3

Это то, что появляется у меня в голове, когда я думаю о том, как статика может усложнить ситуацию:

1) Наследование, а также полиморфизм потребуют специальных правил. Вот пример:

// This is Java
public class A {
  public static int f() {
    return 10;
  }
}

public class B extends A {
  public static int f() {
    return 5;
  }
}

public class Main {
  public static void main(String[] args) {
    A a = new A();
    System.out.println(a.f());
    B b = new B();
    System.out.println(b.f());
    A ba = new B();
    System.out.println(ba.f());
   }
}

Если вы на 100% уверены в том, что распечатывается, хорошо для вас. Остальные из нас могут надежно полагаться на мощные инструменты, такие как аннотация @Override, которая, конечно же, необязательна и дружественная "Статический метод f() из типа A должен быть доступен статическим способом" предупреждение. Это приводит нас к

2) "Статический путь" доступа к материалу - это дополнительное специальное правило, которое усложняет ситуацию.

3) Статические члены не могут быть абстрактными. Наверное, у тебя не может быть всего, верно?

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

Ответ 4

Истинно, статический член не существует, НО, возможно связать одноэлементный объект с каждым классом:

class MyClass {
}

object MyClass {
}

для получения аналогичных результатов

Ответ 5

Объектно-ориентированное программирование - это все объекты и его состояния (не касаясь состояния полного и безгосударственного объекта). Im пытается подчеркнуть "Static не принадлежит объектам". Статические поля не могут использоваться для представления состояния объекта, поэтому его рационально отделять от объектов.