Как лучше организовать класс с большим количеством полей?

Question

В настоящее время я внедряю что-то похожее на внутрибольничную больницу, где врачи могут видеть информацию о своих пациентах.

В настоящее время у меня МНОГО информации о каждом клиенте: его полное имя, дата рождения,группа крови, где он живет, какие у него болезни и т. д.

Моя первая попытка была в форме:

class Client {
    private string fullName;
    private Date dateOfBirth;
    ...

    public Get/Set FullName()
    public Get/Set DateOfBirth()
    ...
}

, которая в основном объединяет все в одном классе.

Через некоторое время я решил, что, возможно, мне следует объединить похожие концепции в более общую.Например, я могу инкапсулировать userName и password в одну и ту же концепцию - например, LoginInfo.

1. При этом я должен предоставить все методы получения / установки наКлиентский класс, который делегирует работу правильным внутренним понятиям, или я должен просто поместить получатели для самих понятий?Первый подход мог бы защитить внешний мир от реализации класса Client, но тогда, возможно, мы бы не выиграли так много, имея все эти внутренние концепции.
2. Если бы код вне класса Client даже знал разныевиды концепций, которые будут использоваться внутри него?
3. Любые другие идеи / подходы?

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

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

Answer 1

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

Что еще нужно учитывать: какие данные будут передаваться пациентам? Если вы сохраняете данные о семейной истории болезни, должны ли эти данные передаваться братьям и сестрам? Если это так, то инкапсуляция этих данных в свой собственный объект сэкономит вам массу времени при копировании / синхронизации.

Это не единственные соображения при анализе ваших данных. Но они определенно являются частью головоломки.

Answer 2

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

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