Неизменный объектный шаблон в C# - что Вы думаете? [закрытый]
Это WORKS ..
Помните, что в первый раз, когда вы напечатаете передаваемое значение, вы получите нуль, вы можете использовать его после загрузки Windows, то же самое для всего, что вы хотите кодировать для любого другого компонента.
Первый контроллер
try { Stage st = new Stage(); FXMLLoader loader = new FXMLLoader(getClass().getResource("/com/inty360/free/form/MainOnline.fxml")); Parent sceneMain = loader.load(); MainOnlineController controller = loader.<MainOnlineController>getController(); controller.initVariable(99L); Scene scene = new Scene(sceneMain); st.setScene(scene); st.setMaximized(true); st.setTitle("My App"); st.show(); } catch (IOException ex) { Logger.getLogger(LoginController.class.getName()).log(Level.SEVERE, null, ex); }Другой контроллер
public void initVariable(Long id_usuario){ this.id_usuario = id_usuario; label_usuario_nombre.setText(id_usuario.toString()); }
11 ответов
Для получения информации второй подход называют "неизменностью фруктового мороженого".
у Eric Lippert есть ряд записей в блоге на неизменности, запускающейся здесь . Я все еще справляюсь с CTP (C# 4.0), но выглядит интересным, что дополнительный / именованные параметры (к .ctor) могли бы сделать здесь (когда отображено на полях только для чтения)... [обновление: я вел блог на этом здесь ]
Для получения информации, я, вероятно, не сделал бы те методы virtual - мы, вероятно, не хотим способности подклассов сделать ее незамораживаемой. Если бы Вы хотите, чтобы они были в состоянии добавить дополнительный код, я предложил бы что-то как:
[public|protected] void Freeze()
{
if(!frozen)
{
frozen = true;
OnFrozen();
}
}
protected virtual void OnFrozen() {} // subclass can add code here.
Также - AOP (такой как PostSharp) мог бы быть жизнеспособным вариантом для добавления всех тех ThrowIfFrozen () проверки.
(извинения, если я изменил терминологию / имена методов - ТАК не остается на исходном посту, видимом при создании ответов)
Мне не нравится идея способности изменить объект от изменяемого до неизменного состояния, такой, кажется, побеждает точку дизайна мне. Когда необходимо сделать это? Только объекты, которые представляют ЗНАЧЕНИЯ, должны быть неизменны
Вот новое видео на Канале 9, где Anders Hejlsberg от 36:30 в интервью начинает говорить о неизменности в C#. Он дает очень хороший вариант использования для неизменности фруктового мороженого и объясняет, как это - что-то, что Вы в настоящее время обязаны реализовывать сами. Это была музыка к моим ушам, слыша, что он говорит, что это стоит думать о лучшей поддержке создания неизменных графов объектов в будущих версиях Эксперта по C#
Просто подсказка для упрощения свойств элемента: Используйте автоматические свойства с private set и постарайтесь не явно объявлять поле данных. например,
public class SampleElement {
public SampleElement(Guid id, string name) {
Id = id;
Name = name;
}
public Guid Id {
get; private set;
}
public string Name {
get; private set;
}
}
Подробно останавливаясь на точке @Cory Foy и @Charles Bretana, где существует различие между объектами и значениями. Принимая во внимание, что объекты значения должны всегда быть неизменными, я действительно не думаю, что объект должен быть в состоянии заморозить себя или позволить себе быть замороженными произвольно в кодовой базе. Это имеет действительно неприятный запах к нему, и я волнуюсь, что могло стать трудным разыскать, где точно объект был заморожен, и почему это было заморожено, и то, что между вызовами к объекту это могло изменить состояние от таявшего до замороженного.
, Который не должен говорить, что иногда Вы хотите дать (изменяемый) объект чему-то и гарантировать его, не будет измененным.
Так, вместо того, чтобы заморозить сам объект, другая возможность состоит в том, чтобы скопировать семантику ReadOnlyCollection< T>
List<int> list = new List<int> { 1, 2, 3};
ReadOnlyCollection<int> readOnlyList = list.AsReadOnly();
Ваш объект может принять участие как изменяемое, когда этому нужен он, и затем быть неизменным, когда Вы требуете, чтобы он был.
Примечание это ReadOnlyCollection< T> также реализует ICollection< T>, который имеет Add( T item) метод в интерфейсе. Однако существует также bool IsReadOnly { get; } определены в интерфейсе так, чтобы потребители могли проверить прежде, чем назвать метод, который выдаст исключение.
различие - то, что Вы не можете только установить IsReadOnly на ложь. Набор или или не только для чтения, и это никогда не изменяется в течение времени жизни набора.
было бы хорошо во время иметь правильность константы, которую C++ дает Вам во время компиляции, но это начинает иметь свой собственный набор проблем, и я - довольный C#, не идет туда.
<час>ICloneable - я думал, что просто вернусь к следующему:
не реализуют ICloneable
, не используют ICloneable в общедоступных API
Brad Abrams - Руководство по проектированию, Управляемый код и Платформа.NET
Система. Строка является хорошим примером неизменного класса с методами set и видоизменяющимися методами, только что каждый метод видоизменения возвращает новый экземпляр.
(Относительно) новая парадигма Разработки программного обеспечения под названием Доменный Управляемый дизайн, делает различие между объектами объекта и объектами значения.
Объекты Объекта определяются как что-либо, что должно отобразиться на кнопочный объект в персистентном хранилище данных, как сотрудник, или клиент или счет, и т.д...., где изменение свойств объекта подразумевает, что необходимо сохранить изменение в хранилище данных где-нибудь и существование нескольких экземпляров класса с тем же "ключом" imnplies потребность синхронизировать их, или скоординировать их персистентность к хранилищу данных так, чтобы один экземпляр' изменения не перезаписывал другие. Изменение свойств объекта объекта подразумевает изменение чего-то об объекте - не изменение, КОТОРЫЕ возражают, что Вы ссылаетесь...
otoh объектов Значения, объекты, которые можно считать неизменными, чья утилита определяется строго их значениями свойств, и для которого несколько экземпляров, не должны быть скоординированы всегда... как адреса, или номера телефона или колеса на автомобиле, или буквы в документе... эти вещи полностью определяются их свойствами... верхний регистр ',' объектом в текстовом редакторе можно обменяться прозрачно с любым другим верхним регистром объект всюду по документу, Вам не нужен ключ для различения его от всех других, 'A В этом смысле это неизменно, потому что при изменении его на 'B' (точно так же, как, меняя струну номера телефона в объекте номера телефона, Вы не изменяете данные, связанные с некоторым изменяемым объектом, Вы переключаетесь от одного значения до другого... так же, как, когда Вы изменяете значение строки...
Вы все еще имеете дело с состоянием, и таким образом можете все еще быть укушены, если Ваши объекты параллелизируются прежде чем быть сделанным неизменным.
А более функциональный путь мог бы состоять в том, чтобы возвратить новый экземпляр объекта с каждым методом set. Или создайте изменяемый объект и передачу это в конструктору.
После моего начального дискомфорта о том, что я должен был создать новое System.Drawing.Point на каждой модификации, я полностью охватил понятие несколько лет назад. На самом деле я теперь создаю каждое поле как readonly по умолчанию и только изменяю его, чтобы быть изменяемым, если существует неопровержимый довод †“, который существует удивительно редко.
я не забочусь очень о проблемах свинчивания резьбы, хотя (я редко использую код, где это релевантно). Я просто нахожу его очень, намного лучше из-за семантической выразительности. Неизменность является самым воплощением интерфейса, который трудно использовать неправильно.
Другая опция состояла бы в том, чтобы создать некоторый класс Разработчика.
Для примера, в Java (и C# и много других языков) Строка неизменна. Если Вы хотите сделать несколько операций для создания Строки, Вы используете StringBuilder. Это изменяемо, и затем как только Вы сделаны, у Вас есть он, возвращают Вам заключительный Строковый объект. С тех пор это неизменно.
Вы могли сделать что-то подобное для своих других классов. У Вас есть свой неизменный Элемент, и затем ElementBuilder. Весь разработчик сделал бы, сохранить опции, которые Вы устанавливаете, тогда при завершении его, это создает и возвращает неизменный Элемент.
Это - немного больше кода, но я думаю, что это более чисто, чем наличие методов set на классе, это, как предполагается, неизменно.
Два других варианта решения вашей конкретной проблемы, которые не обсуждались:
Создайте свой собственный десериализатор, который может вызывать установщик частных свойств. Хотя на начальном этапе создание десериализатора потребует гораздо больше усилий, он делает все чище. Компилятор не даст вам даже попытаться вызвать сеттеры, и код в ваших классах будет легче читать.
Поместите конструктор в каждый класс, который принимает XElement (или какой-либо другой вариант объектной модели XML) и заполняет себя от него. Очевидно, что по мере увеличения числа классов это решение быстро становится менее желательным.