Методы C # и свойства: исключения могут возникать

Question

Я создал библиотечный класс CircuitController, который связывается со схемой управления через последовательный порт.

public class CircuitController
{
   // Enumerations.
   public enum Sensors { Sensor1, Sensor2, ..., Sensor15 };
   ...

   // Fields.
   private SerialPort serialPort;  // Set in constructor.
   private Dictionary<Sensors, Sensor> activeSensorCollection;
   ...

   // Properties.
   public Dictionary<Sensors, Sensor> ActiveSensors
   { get { return this.activeSensorCollection; } }       

   // Methods.
   public void SetSensorUnits(Sensors sensor, String sensorUnits)
   {
      // Creates serial command based off parameters, sends, receives, processes.
   }
   ...

   // Constructors.
   public CircuitController(...)
   {
      ... // Set CircuitController fields including nested classes.
      Sensor sensor1 = new Sensor(a,b,c,d,this);  // Link sensor to this controller instance.
      ... // Add sensors to dictionary.
   }          

   // Nested Classes.
   public class Sensor
   {
      // Fields.
      private CircuitController controller;   
      private String units;
      private Sensors sensorNumber;
      ...

      // Properties.
      public String Units
      {
         get
         {
            return this.controller.GetSensorUnits(this.sensorNumber);
         }
         set
         {
            this.controller.SetSensorUnits(this.sensorNumber, value);
          }
      }
      ...
   }

Итак, вот мои вопросы: Можно ли разрешить пользователю получать / устанавливать настройки датчика через свойства, даже если может быть выдано исключение (например, ошибка последовательной связи)?

String sensor2Units = circuitControllerInstance.ActiveSensors[Sensor2].Units'
circuitControllerInstance.ActiveSensors[Sensor1].Units = "mm";

Я нахожу это намного яснее, чем ...

String sensor2Units = circuitControllerInstance.GetSensorUnits(Sensors.Sensor2);
circuitControllerInstance.SetSensorUnits(Sensors.Sensor1, "mm");

Обратите внимание, что это упрощенные примеры, некоторые из методов Get / Set имеют до 5 параметров, из-за которых многократно вводить текст. : /

Answer 1

Я бы старался на самом деле не делать ничего, когда свойство установлено. Вместо этого пусть все свойства будут установлены в памяти, а затем добавьте метод «Сохранить», который «сохранит» свойства на последовательном устройстве.

Answer 2

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

В некоторых случаях, когда многим атрибутам функции придетсяЧтобы быть установленным сразу, может быть полезно иметь пару методов для копирования состояния объекта в структуру и чтения состояния объекта из структуры.Некоторые люди, кажется, думают, что было бы плохо использовать структуру для таких целей, потому что в таком коде, как:

struct MyPropertyStruct
{
  Rectangle bounds;
  ...
}
...
  MyPropertyStruct myProperties;

  someObject.GetProperties(ref myProperties);
  myProperties.Bounds.Left += 4;

, это не повлияет на someObject, а только на копию свойств, хранящихся в myPropertiesили до тех пор, пока не произойдет «someObject.SetProperties (ref myProperties)».Я бы предложил обратное: если myProperties - это структура, содержащая только типы значений или неизменяемые ссылочные типы, любой компетентный программист будет знать, что по определению типы значений не привязаны ни к чему другому.Напротив, если бы GetProperties должен был возвращать тип класса, программист, смотрящий на код, не мог бы знать, как может повлиять изменение возвращаемого объекта.