Как обрабатывать несколько типов объектов при создании нового типа

Question

Было поручено написать программное обеспечение для отслеживания активов ... Хотите попробовать сделать это правильно. Поэтому я подумал, что у многих активов есть общие поля. Например, у компьютера есть модель и производитель, которые есть у мобильного телефона.

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

Например,

public abstract class Asset {
private string manufacturer;

    public string Manufacturer { get; set; }
    //more common fields
}

    public class Computer : Asset {
    private string OS;
    public strin OS { get; set; }
    //more fields pertinent to a PC, but inherit those public properties of Asset base
    }

    public class Phone : Asset {
    //etc etc
    }

Но у меня есть 2 проблемы:

1) Если у меня есть веб-форма, в которой просят кого-то добавить актив, я хочу дать ему возможность выбрать радиоблок типа создаваемого им актива. Что-то с эффектом:

Что вы создаете

[] компьютер

[] телефон

[] монитор

[OK] [ОТМЕНА]

И они выбрали бы один, но я не хочу заканчивать с кодом как этот:

псевдокод:

select case(RadioButtonControl.Text)
 {
  case "Computer": Computer c = new Computer(args);
                   break;
  case "Phone": Phone p = new Phone(args);
                break;
  ....
 }

Это может стать уродливым ....

Проблема 2) Я хочу сохранить эту информацию в одной таблице базы данных с полем TypeID, чтобы при вставке в базу данных это значение становилось идентификатором строки (различает ли это компьютер, монитор, телефон и т. д.). Должно ли это поле typeid быть объявлено внутри базового абстрактного класса как некое перечисление?

Спасибо

Answer 1

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

Прямо сейчас вы, похоже, подходите к этому как к объектно-ориентированной программе с базой данных в качестве резервного хранилища (так сказать).Я бы перевернул это: это база данных с внешним интерфейсом, которая (или, по крайней мере, может быть) объектно-ориентированной.

Опять же, если у вас нет действительно специфических и необычных потребностей в отслеживании ваших активов, шансыэто то, что вы не должны делать это вообще.Буквально десятки совершенно разумных пакетов отслеживания активов уже есть на рынке.Если ваши потребности на самом деле не слишком необычны, переосмысление этого конкретного колеса не принесет многого.

Редактировать: я не собираюсь советовать вообще не использовать ООП внутри самого приложения.Напротив, MVC (например) работает довольно хорошо, и я почти наверняка использовал бы его для почти любой задачи, подобной этой.

Там, где я бы избегал ООП, было бы в дизайне данныххранитсяЗдесь вы получите гораздо больше пользы от использования чего-то вроде базы данных на основе SQL через что-то вроде OLE DB, ODBC или JDBC.

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

Edit2: Что касается времени использования(или не использовать) наследование, одна подсказка (хотя я признаю, что это не более того) состоит в том, чтобы взглянуть на поведения и на то, отражает ли рассматриваемая вами иерархия поведение, которое важно для вашей программы,В некоторых случаях данные, с которыми вы работаете, являются относительно «активными» в программе - то есть поведение самой программы вращается вокруг поведения данных.В таком случае имеет смысл (или, по крайней мере, может иметь смысл) иметь относительно тесную связь между данными и кодом.

Однако в других случаях поведениеКод относительно не зависит от данных.Я бы сказал, что такое отслеживание активов.Для программы отслеживания активов не имеет большого значения (если таковое имеется) реальная разница, является ли текущий элемент телефоном, радио или автомобилем.Есть несколько (обычно гораздо более широких) классов, которые вы могли бы пожелать принять во внимание - по крайней мере, для довольно большого числа предприятий важно, считаются ли активы "недвижимостью", "оборудованием", "офисом".расходные материалы "и т. д. Эти классификации приводят к различиям в таких вещах, как отслеживание актива, уплата налогов и т. д.

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

Один из способов подвести итог - подумать, может ли программа разумно работать с данными, для которых она на самом деле не быларазработан.Для отслеживания активов практически нет шансов, что вы можете (или захотите) создать класс для каждого типа объекта, который кто-то может решить отслеживать.С самого начала вам нужно планировать тот факт, что он будет использоваться для всех видов данных, которые вы явно не учли в первоначальном проекте.Скорее всего, для большинства элементов вам необходимо разработать свой код, чтобы можно было просто передавать данные, не зная (или не заботясь) о большинстве содержимого.

Моделирование данных в вашем коде имеет смысл, прежде всего, когда / если программе действительно необходимо знать точные свойства данных, и она не может разумно функционировать без нее.