Шаблон дизайна для класса с более чем 100 свойствами - PullRequest
22 голосов
/ 27 октября 2009

Какой совет / предложения / руководство вы бы дали для разработки класса, который имеет более 100 свойств?

Фон

  • Класс описывает счет-фактуру. Счет может иметь более 100 атрибутов, описывающих его, то есть дату, сумму, код и т. Д. *
  • Система, в которую мы отправляем счет-фактуру, использует каждый из 100 атрибутов и представляется как единое целое (в отличие от разных частей, представляемых в разное время).
  • Атрибуты, описывающие счет-фактуру, являются обязательными в рамках бизнес-процесса. Бизнес-процесс не может быть изменен.

Предложения

  • Что другие сделали, когда столкнулись с разработкой класса, который имеет 100 атрибутов? т.е. создать класс с каждым из 100 свойств?
  • Как-нибудь разбить его (если да, то как)?
  • Или это достаточно нормальное явление в вашем опыте?

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

Ответы [ 17 ]

1 голос
/ 28 октября 2009

Похоже, что для конечного результата вам нужно создать объект счета с примерно 100 свойствами. У вас есть 100 таких свойств в каждом случае? Может быть, вы захотите фабрику, класс, который будет производить счет-фактуру с меньшим набором параметров. Для каждого сценария может быть добавлен другой метод фабрики, в котором релевантные поля счета-фактуры актуальны.

1 голос
/ 28 октября 2009

Вы не должны руководствоваться исключительно эстетическими соображениями.

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

Если нет реальной ценности в составлении этого объекта из частей, что именно получается, скрывая его функцию и назначение?

Это будут веские причины:

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

2 - у вас есть другие системы, которые могут использовать различные подмножества полей этого объекта. Здесь повторное использование является мотивирующим фактором.

3 - Существует очень реальная возможность для системы выставления счетов следующего поколения, основанной на более рациональном дизайне. Здесь расширяемость и эволюция системы являются мотивирующим фактором.

Если ни одно из этих соображений не применимо в вашем случае, тогда какой смысл?

0 голосов
/ 28 октября 2009

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

удачи :) 1003 *

0 голосов
/ 28 октября 2009

Если у сущности есть сто уникальных атрибутов, то правильный выбор - один класс с сотней свойств.

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

Счет из учебника (то есть слишком упрощенный, непригодный для использования в реальном мире) будет выглядеть так: -

 class invoice:
    int id;
    address shipto_address;
    address billing_address;
    order_date date;
    ship_date date;
    .
    .
    . 
    line_item invoice_line[999];

  class line_item;
    int item_no.
    int product_id;
    amt unit_price;
    int qty;
    amt item_cost;
    .
    .
    .

Так что я удивлен, что у вас там нет хотя бы массива line_items.

Привыкай к этому! В деловом мире организация может легко иметь сотни, а иногда и тысячи уникальных атрибутов.

0 голосов
/ 27 октября 2009

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

0 голосов
/ 28 октября 2009

словарь? почему нет, но не обязательно. Я вижу тег C #, ваш язык имеет отражение, хорошо для вас. У меня было несколько слишком больших классов, подобных этому, в моем коде Python, и рефлексия очень помогает:

for attName in 'attr1', 'attr2', ..... (10 other attributes):
    setattr( self, attName, process_attribute( getattr( self, attName ))

Если вы хотите преобразовать 10 строковых членов из некоторой кодировки в UNICODE, некоторые другие строковые члены не следует трогать, вы хотите применить некоторую числовую обработку к другим членам ... преобразовать типы ... -клейка большого количества кода в любое время для чистоты.

0 голосов
/ 28 октября 2009

Вы можете попробовать LINQ, он автоматически выберет для вас свойства. Если все поля распределены по нескольким таблицам, и вы можете создать представление и перетащить представление в дизайнер.

...