как разработать классы - PullRequest
Новая
       9

как разработать классы

0 голосов
/ 08 марта 2011

Я использую LINQ to SQL, 3.5 Framework, и я хотел бы знать, что является лучшим способом для разработки классов.Возьмем очень простой пример User таблицы.
Если у меня есть таблица пользователей с 3 различными ролями: Клиент, Администратор, Кассир.Я бы сказал, что мне нужно создать 3 класса для каждой роли.Например, customer.cs ...

Вопрос:
1) Поскольку в Linq .dbml уже автоматически сгенерирован пользователь из моей таблицы пользователей, все свойства уже предопределены, нужно ли мне создавать пользователя?.cs класс, который будет унаследован 3 от роли классов выше?Это потому, что я не могу добавить дубликаты свойств в файл User.cs, например, Public string Name {get;set;} не удастся, потому что в .dbml уже есть вызов свойства Name.

2) Этот вопрос, я думаю, будет очень простым.... но я нахожу это полезным, если я могу знать правильный ответ.Как я должен оставить свою функциональность в правильном классе?e.g. PrintYearlyReport(), CheckStaffSalary(), ModifySale(), UpdateGovernmentTax() .... все эти функции находятся в роли администратора.Это будет очень читабельно, если у нас будет admin.PrintYearlyReport(), admin.ModifySale() ... Однако, если мы будем хранить все функции администратора в файле Admin.cs, то этот файл будет очень очень огромным !!!Для ООП нам нужны такие классы, как, например, Sale.cs, Payment.cs, Invoice.cs.Если мы разделим все эти функции на разные классы, у нас больше не будет элегантного способа вызова admin.PrintYearlyReport () больше ..

Ответы [ 3 ]

0 голосов
/ 08 марта 2011

Давайте будем проще. Обычно лучший ответ самый простой. Вам нужно иметь более одного класса? Может быть, может быть нет. Если различия между ролями просты в одном ряду, то зачем создавать подклассы? Я обычно начинаю с одного класса, так как поведение лучше определено, и вы можете четко различать подклассы, чем создавать их. С учетом сказанного вы должны подумать о том, как вы хотите, чтобы ваши объекты выглядели, и под этим я подразумеваю, какие зависимости вы будете создавать и какие функции будут использоваться совместно. Состав против наследования Когда я думаю о пользователях и ролях, я думаю: у пользователя есть роль x, а не у пользователя роль x, потому что роли могут меняться. Общие функциональные возможности и свойства должны быть в базовом классе. Возможно, вы можете поместить свои правила доступа в класс, который живет внутри пользователя: 

User{
    Name
    Role
    Rules{ }
}

Так что вы можете сказать 

if(user123.Rules.CanPrint())
{
Print();
}

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

0 голосов
/ 08 марта 2011

Вы можете добавить стереотип к диаграмме своего класса и получать живые аннотации постоянства в своем коде Java.Если вы используете Hibernate, то из своего кода вы можете получить свою базу данных.Не нужно создавать объектную модель UML и другую модель для вашей базы данных.Это то, что я делаю, и это действительно здорово! *

Работает только с Java, а не с c #

0 голосов
/ 08 марта 2011

  1. Вы можете создать подклассы класса User, то есть Customer, Admin и Cashier, а затем указать правильный класс в зависимости от роли пользователя.Иногда мы проектируем, создавая методы, подобные User.IsInRole или User.HasAccessTo, которые вы можете вызывать, чтобы проверить, могут ли они получить доступ или использовать определенные функции.но все равно держите их в одном классе, используя partial классы.Если вы определите public partial class Admin, вы можете определить класс Admin в любом количестве отдельных файлов, и все свойства будут добавлены вместе при построении проекта.

...