Но опять же главное сомнение в том, зачем нужен идентификатор ресурса TextView?
blockquote>Посмотрите на конструктор и параметры.
public ArrayAdapter (Context context, int resource, int textViewResourceId, T[] objects)
Добавлено в уровне API 1 Конструктор
Параметры
context
Текущий контекст.
resource
Идентификатор ресурса для файла макета, содержащий макет, который будет использоваться при создании экземпляров.blockquote>
textViewResourceId
Идентификатор TextView в ресурсе макета, который будет заполнен. объекты для представления вListView
.
android.R.id.text1
относится к идентификатору текста в ресурсе android. Поэтому вам не нужно иметь в своей деятельности.Вот полный список
http://developer.android.com/reference/android/R.id. html
ArrayAdapter
adapter = new ArrayAdapter (this, android.R.layout.simple_list_item_1, android.R.id.text1, values);
this
относится к контексту активности
android.R.layout.simple_list_item_1
simple_list_item_1 - это макет в android.R.layout.
android.R.id.text1
относится к идентификатору ресурса android.
values
- это строковый массив из предоставленной вами ссылкиhttp://developer.android.com/reference /android/R.layout.html
Используйте абстрактное свойство, если у вас нет реализации по умолчанию, и когда производные классы должны его реализовать.
Используйте виртуальное свойство, если у вас есть реализация в базовом классе, но вы хотите разрешить переопределение.
Используйте ключевое слово override
для переопределения члена. Отметьте элемент как sealed override
, если он не должен быть переопределен снова.
Не отмечайте свойство как abstract
или virtual
, если вы не хотите, чтобы он был переопределен.
Используйте ключевое слово new
, чтобы скрыть не абстрактный, не виртуальный элемент (это редко бывает хорошей идеей).
Как определить абстрактные свойства
Я обнаружил, что абстрактные свойства часто встречаются в дизайне, что подразумевает, что они будут иметь специфичную для конкретного типа логику и / или побочные эффекты. Вы в основном говорите: «Вот точка данных, которую должны иметь все подклассы, но я не знаю, как ее реализовать». Однако свойства, которые содержат большое количество логики и / или вызывают побочные эффекты, могут быть нежелательными. Это важное соображение, хотя для него не существует правильного / неправильного способа.
См.:
Лично я обнаружил, что я часто использую абстрактные методы, но абстрактные свойства редко.
Используйте абстракцию, когда все подклассы имеют для реализации метода / свойства. Если нет необходимости в каждом подклассе для его реализации, то не используйте его.
Что касается вашего примера, если SecondName
не требуется для каждого человека, тогда нет необходимости создавать абстрактное свойство в базовом классе. Если, с другой стороны, каждый человек нуждается во втором имени, то делает его абстрактным.
Пример правильного использования абстрактного свойства:
public class Car
{
public abstract string Manufacturer { get; }
}
public class Odyssey : Car
{
public override string Manufacturer
{
get
{
return "Honda";
}
}
}
public class Camry : Car
{
public override string Manufacturer
{
get
{
return "Toyota";
}
}
}
Создание Maker
реферат правильный, потому что у каждого автомобиля есть производитель, и ему необходимо сообщить пользователю, кто этот производитель.
Абстрактные члены - это просто виртуальные участники, которые вы должны переопределить. Вы используете это для чего-то, что должно быть реализовано, но не может быть реализовано в базовом классе.
Если вы хотите создать виртуальное свойство и хотите, чтобы он был переопределен в классе, который наследует ваш класс, тогда вы сделаете его абстрактным свойством.
Если вы, например, имеете класс животных, его способность дышать не удастся раскрыть только из информации о том, что это животное, но это что-то очень важное:
public abstract class Animal {
public abstract bool CanBreathe { get; }
}
Для рыбы и собаки реализация будет другой:
public class Dog : Animal {
public override bool CanBreathe { get { return !IsUnderWater; } }
}
public class Fish : Animal {
public override bool CanBreathe { get { return IsUnderWater; } }
}
Абстрактное свойство будет использоваться там, где вы хотите, чтобы класс всегда отображал свойство, но там, где вы не можете зафиксировать реализацию этого свойства, оставив его до / заставляя наследующий класс делать это.
Вот пример здесь , где абстрактный класс называется Shape
, и он предоставляет абстрактное свойство Area
. Вы не можете реализовать свойство Area
в базовом классе, поскольку формула для области изменится для каждого типа фигуры. Все фигуры имеют некоторую область (так или иначе), поэтому все формы должны раскрывать свойство.
Ваша реализация сама по себе выглядит просто замечательно. Старался думать о разумном примере абстрактного свойства для Human
, но не мог придумать ничего разумного.
Я знаю, что я хочу, чтобы они делали, мне все равно, как они это делают: Интерфейс.
Я знаю, что я хочу, чтобы они делали, мне все равно, как они делают некоторые из это, но у меня есть твердые идеи о том, как они (или, по крайней мере, большинство из них) выполняют другие биты: абстрактный класс.
Я знаю, что я хочу, чтобы они делали, и как большинство из них сделайте это: Конкретный класс с виртуальными членами.
Вы можете иметь другие случаи, такие как, например, абстрактного класса без абстрактных членов (у вас не может быть экземпляра одного, но какая функциональность он предлагает, он предлагает полностью), но они реже и обычно возникают потому, что конкретная иерархия предлагает себя чисто и откровенно для данного проблема.
(Кстати, я бы не подумал о Петре как о человеке, а о каждом пэтере как о человеке, которого, как говорят, называют Питером. код таким образом, но когда вы думаете об этой проблеме, это более уместно, чем обычно).
Peter
должен быть экземпляром подкласса Human
, например. HumansWithTwoNames
– Tim Medora
3 September 2012 в 23:18