Вопросы Теги

Предложения по использованию объекта класса [дубликат]

Вы ищете io::copy : 

use std::io::{self, prelude::*, SeekFrom};

pub fn assemble(mut input: I, mut output: O) -> Result<(), io::Error>
where
    I: Read + Seek,
    O: Write,
{
    // first seek and output "hello"
    input.seek(SeekFrom::Start(5))?;
    io::copy(&mut input.by_ref().take(5), &mut output)?;

    // then output "world"
    input.seek(SeekFrom::Start(0))?;
    io::copy(&mut input.take(5), &mut output)?;

    Ok(())
}

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

  1. write не всегда записывает все, что вы просите!
  2. «Прерванная» запись обычно не fatal.

Он также использует больший размер буфера, но все еще содержит стек.

20
задан Andrew Turner 4 April 2009 в 14:57
поделиться

9 ответов

Анд, я думаю, вы приближаетесь к этому - каламбур НЕ предназначен - с ненужной степенью абстракции. Я думаю, что этот (ИМХО) ненужный уровень абстракции является тем, что вызывает здесь «проблему». Возможно, вы приближаетесь к этому с математического теоретического подхода, когда многие из нас приближаются к этому с подхода «программист, пытающийся решить проблемы». Я считаю, что это различие в подходах вызывает разногласия.

Когда программисты смотрят на практичность и как на самом деле реализуют что-то, есть несколько раз, когда вам нужен какой-то полностью произвольный объект фактический пример которого совершенно не имеет значения. Он просто не может быть нулевым. Пример, который я дал в комментарии к другому сообщению, - это реализация *Set (* == Hash или Concurrent или тип выбора), который обычно выполняется с использованием поддержки *Map и использования Map в качестве набора. Вы часто не можете использовать null как значение Map, поэтому обычно делается попытка использовать статический экземпляр Object как значение, которое будет игнорироваться и никогда не будет использоваться. Однако необходим некоторый ненулевой заполнитель.

Еще одно распространенное использование с ключевым словом synchronized, где требуется некоторое Object для синхронизации, и вы хотите обеспечить что ваш синхронизированный элемент полностью закрыт, чтобы избежать тупиковой ситуации, когда разные классы непреднамеренно синхронизируются с одной и той же блокировкой. Очень распространенная идиома заключается в том, чтобы выделить private final Object для использования в классе как блокировку. Справедливости ради следует отметить, что по сравнению с Java 5 и java.util.concurrent.locks.Lock и связанными дополнениями эта идиома заметно менее применима.

Исторически сложилось так, что на Java было очень полезно иметь Object. Вы могли бы сказать, что с небольшими изменениями в дизайне или с небольшими изменениями API это больше не понадобится. Вы, вероятно, правы в этом.

И да, API мог бы предоставить класс Placeholder, который расширяет Object без добавления чего-либо вообще, для использования в качестве заполнителя для целей, описанных выше , Но - если вы расширяете Object, но ничего не добавляете, каково значение в классе, кроме того, что разрешить Object быть абстрактным? Математически, теоретически, возможно, можно было бы найти значение, но прагматически, какое значение он мог бы добавить для этого?

В программировании есть моменты, когда вам нужен объект, некоторый объект , любой конкретный объект , который не является нулевым, что вы можете сравнить с помощью == и / или .equals(), но вам просто не нужна какая-либо другая функция для этого объекта. Он существует только для того, чтобы служить уникальным идентификатором и в противном случае абсолютно ничего не делает. Object удовлетворяет эту роль отлично и (IMHO) очень чисто.

Я бы предположил, что это является частью причины, по которой Object не был объявлен абстрактным: для него это просто не полезно.

14
ответ дан Eddie 19 August 2018 в 19:47
поделиться
  • 1
    +1, лучший ответ еще. – Michael Myers♦ 3 April 2009 в 21:01
  • 2
    Я считаю, что мгновенный объект допускает идиоматические сбои в понимании программистами ООП как метода моделирования. Если это была ошибка, она теперь используется как функция, и если бы она не была разрешена, изначально лучшие методологии теперь были бы идиоматичны для Java. – Andrew Turner 4 April 2009 в 08:25
  • 3
    +1, потому что, хотя мы можем не согласиться, я по-прежнему согласен с мюйерами. :п – Andrew Turner 4 April 2009 в 08:26
  • 4
    @Ande: Я полностью согласен с тем, что это абстрактная тема Object, достаточно всего лишь нескольких небольших изменений в API, чтобы полностью заменить экземпляр объекта. И все зависит от меня, я бы удалил, что каждый объект в Java также является блокировкой и требует блокировки (или производной) для синхронизации. – Eddie 4 April 2009 в 17:34

Вы никогда не знаете, когда захотите использовать простой объект в качестве заполнителя. Подумайте об этом как о нуле в числовой системе (и null для этого не работает, поскольку null представляет отсутствие данных).

1
ответ дан Alan Daniels 19 August 2018 в 19:47
поделиться
  • 1
    Однако есть примитивы для подсчета. Зачем перетаскивать концепцию объектов в ситуацию, которая не гарантирует их использования? – Andrew Turner 2 April 2009 в 17:29
  • 2
    На начальном этапе у Java не было примитивов (не то, что я думаю, что имеет значение для этого конкретного обсуждения). – TofuBeer 2 April 2009 в 18:49
  • 3
    @Ande: Алан Дэниелс не говорит о подсчете. Он говорит об использовании заполнителя. Примитивы не будут выполнять эту работу, так как, они примитивны. – Eddie 2 April 2009 в 23:22
  • 4
    @Eddie: Заполнитель для чего? в точку? Числа, значения, символы? – Andrew Turner 3 April 2009 в 10:15
  • 5
    @Ande, A (общая) реализация Set ( = некоторый тип Set) заключается в использовании Map и поместить объект в качестве значения, используя клавиши в качестве Set. Вы должны поместить * something в качестве значения, таким образом, Object. Заполнитель. Есть места, где вы не можете использовать null, но должны использовать какой-либо произвольный объект. Заполнитель. – Eddie 3 April 2009 в 20:27

Как объект более оскорбителен, чем null?

Он делает маркер хорошего места (так же как и нуль).

Кроме того, я не думаю, что это будет

Я не говорю, что нуль - лучшая вещь, так как нарезанный хлеб - я прочитал статью на днях с помощью " Изобретатель "обсуждает стоимость / ценность понятия null ... (я даже не думал, что null является изобретательным! Я думаю, кто-то может утверждать, что он изобрел нуль ..), что возможность экземпляра объекта не хуже возможность пропускать null.

2
ответ дан Bill K 19 August 2018 в 19:47
поделиться
  • 1
    Реализация не абстрактного объекта в некоторых смыслах является инстанцированием нулевого значения, но еще хуже, потому что я вижу аргументы для его использования. Это вещь без вещества и способностей, на самом деле, возможно, полезно представлять темную материю, хм. – Andrew Turner 2 April 2009 в 18:24
  • 2
    Я видел, что он много использовал, как простой замок, когда никакой экземпляр объекта не имел смысла. Почему это подчеркивает вас настолько, что может быть лучшим вопросом ... на каждом языке есть так много более вопиющих проблем. – Bill K 2 April 2009 в 18:26
  • 3
    «Я предполагаю, что кто-то может утверждать, что он изобрел ноль». Идея нуля фактически была изобретена. Из Википедии: «Концепция нуля как целого, а не просто символа разделения объясняется Индией, где к IX в. Н.э. практические расчеты проводились с использованием нулевого значения» – Davy8 2 April 2009 в 18:31
  • 4
    @Ande: объект не является нулевым. Это нулевая точка, наименьшая возможная вещь, которую вы можете создать. Это сильно отличается от нуля. Почему это беспокоит вас, что объект может быть создан, когда он явно настолько полезен, чтобы иметь возможность создавать объекты Object? – Eddie 2 April 2009 в 23:21
  • 5
    @Eddie: перечисленные виды использования не исключают, что они применяются к любому другому экземпляру объекта. – Andrew Turner 3 April 2009 в 10:14

Там следует быть причиной для создания абстрактного класса. Один из них - запретить клиентам создавать экземпляр класса и заставлять их использовать только подклассы (по каким-либо причинам). Другое дело, если вы хотите использовать его в качестве интерфейса, предоставляя абстрактные методы, которые должны выполняться подклассами . Вероятно, дизайнеры и Java не видели таких причин, поэтому java.lang.Object остается конкретным.

0
ответ дан Frederik Krautwald 19 August 2018 в 19:47
поделиться

Как всегда, Гува приходит помочь: с помощью http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/base/Optional.html Материал здесь может использоваться для уничтожения экземпляров nulls / Object для «не нулевого заполнителя» из кода.

Здесь есть полностью разделенные вопросы:

  • , почему они не сделали Object abstract?
  • , насколько катастрофа возникает после того, как они решили сделать ее абстрактной в будущей версии?
0
ответ дан gyorgyabraham 19 August 2018 в 19:47
поделиться

Определяет ли объект методы, расширяющие его классы, для реализации? Нет, и поэтому он не должен быть абстрактным.

Концепция абстрактного класса имеет четко определенное значение, которое не относится к объекту.

4
ответ дан Kris 19 August 2018 в 19:47
поделиться
  • 1
    Таким образом, ваш & quot; логически не вытекает из вашего предыдущего утверждения, а понятие абстрактного класса имеет четко определенное значение, которое применяется к объекту. – Andrew Turner 2 April 2009 в 20:51
  • 2
    @Ande: Как вы оцениваете? Объект полезен сам по себе, как показали другие люди. Как вы думаете, что это обязательно должно быть абстрактным? – Eddie 2 April 2009 в 23:09
  • 3
    @Ande: Абстрактный обозначает класс, определение которого является неполным, а для экземпляра класса невозможно создать. Это явно не относится к объекту, даже если создание экземпляров бесполезно. И другие указали случаи, когда это полезно. – Kris 3 April 2009 в 09:25
  • 4
    @Kris: абстрактный должен определить абстракцию; объект должен быть объявлен абстрактным, потому что среда realworld, которую вы пытаетесь концептуализировать, не может создавать необоснованные Материи без Потенциала. – Andrew Turner 3 April 2009 в 10:31

Вы можете создать экземпляр Object для блокировок синхронизации: 

Object lock = new Object();

void someMethod() {
  //safe stuff
  synchronized(lock) {
     //some code avoiding race condition
  }
}

void someOtherMethod() {
  //safe code
  synchronized(lock) {
    //some other stuff avoiding race condition
  }
}
17
ответ дан Michael Myers 19 August 2018 в 19:47
поделиться
  • 1
    Если у вас есть 3 метода в классе, объявленных как синхронизированные, существует только одна блокировка для всех 3 методов, поэтому одновременно запускается только один из этих трех методов. Если у вас есть синхронизированные блоки внутри ваших методов, вы можете использовать более одного объекта в качестве блокировки. – Chochos 2 April 2009 в 17:17
  • 2
    по крайней мере, это было до java.util.concurrent или если вы не застряли в java 1.4 – basszero 2 April 2009 в 17:24
  • 3
    Почему бы не иметь блокировку, которая расширяет объект, если объект был абстрактным? – Andrew Turner 2 April 2009 в 17:26
  • 4
    @Ande: Да, некоторые вещи делают это в любом случае. Например, java.awt.Component имеет «статический класс AWTTreeLock {} & quot; и "статический конечный объект LOCK = новый AWTTreeLock (); & quot; – Michael Myers♦ 2 April 2009 в 17:35
  • 5
    @TofuBeer: Я надеюсь, что кто-то, кто работал над 1.0, опубликует & quot; Oops. & Quot; лол – Andrew Turner 2 April 2009 в 18:32

Я не уверен, что это причина, но она позволяет (или разрешает, поскольку теперь есть лучшие способы сделать это) для объекта, который будет использоваться как блокировка: 

Object lock = new Object();

....


synchronized(lock)
{
}
2
ответ дан TofuBeer 19 August 2018 в 19:47
поделиться
17
ответ дан Michael Myers 31 October 2018 в 05:46
поделиться
Другие вопросы по тегам:

Похожие вопросы: