Вложенные классы - это ужасно

сабж

По мне так один хрен.

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

> Какие соображения нужно принять во внимание, выбирая между вариантами (Scala)

Видимость методов, полей, объектов, классов и типов.

Scala — это ужасно

Сабж.

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

Это достигается интерфейсами и фабриками, а не вложенными классами.

И ими тоже

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

orly?

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

Я тоже не люблю вложенные классы. Разве что анонимные иногда полезны.

+1

Вот где, оказывается, неосиляторы затаились.

вложенные классы не нужны. Какое неосиляторство?

Чем меньше зависимостей между классами, тем на мой взгляд лучше.
Представь, что тебе надо будет расширить твою «книгу». Страницы не обязательно являются частью книги. А как ты будешь работать со страницей, если у тебя она намертво зашита в книгу? Строить костыли? Или переписывать, называя это модным словом «рефакторинг»?

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

вложенные классы не нужны.

Строго говоря, никакие не нужны. Но в рамках ООП вложенные классы - вещь очень даже нужная.

Да, я видел мастеров, которые создавали с десяток-другой вложенных классов на пару сотен строк каждый

Это проблемы мастеров, но не вложенных классов. Объявления можно выносить за пределы.

Как сделать так, чтобы только конкретный класс мог создавать объекты определённого типа?

Как сделать так, чтобы только конкретный класс мог создавать объекты определённого типа?

Друзьяшек завести

Зачем?

Псевдокод

// 2 варианта и оба похожи но это не то что пишет ТС. То что пишет ТС - ужасно имхо
// Вариант 1
// служебный класс для хранения промежутчных результатов 
// но тк он не экспортируется и не возвращается {_parse} то его никто не видит
type ParseRet {
  String ret
  Int p  
}

export _parse(String s) {
  ...
  return parseRet.ret
}

// Вариант 2
fn _do(Array data) {
  // заместо тупла
  // такой гразный трюк нужен редко и желательно его избегать
  type IntAndFloat {
    Int i
    Float f  
  }
  
  data
    ._map(fn(Float f){ return IntAndFloat(){f: f, i: f._floor()} })
}