#java #object #interface #permissions
#java #объект #интерфейс #разрешения
Вопрос:
Несколько дней назад я получил задание создать (любительскую) модель моего университетского курса и системы управления студентами (просто базовая программа, без графического интерфейса). Мне удалось создать почти все, кроме одной части — разрешения. Я понятия не имею, с чего даже начать это. Итак, в классе Course есть множество методов, но каждый из них должен работать по-разному. Например, если студент хочет записаться на курс, срок регистрации которого истек, он может записаться, только если профессор добавит его вручную. Я настроил метод, который проверяет даты и возвращает ошибку, если учащийся пытается зарегистрироваться слишком поздно. Но, если бы object professor захотел вызвать этот метод, он мог бы «переопределить правила». Мой профессор сказал мне подумать об использовании интерфейсов, но я уже некоторое время бьюсь головой о стену и до сих пор понятия не имею, как использовать интерфейсы для установки разрешений.
РЕДАКТИРОВАТЬ: мои извинения, я забыл вопрос. Каков наилучший способ в Java создавать разрешения и управлять ими. Если это интерфейс, как именно я мог бы использовать интерфейс для этого?
Ответ №1:
Возможно, вам потребуется предоставить дополнительную информацию о том, как система узнает, кто выполняет каждый метод в вашей системе. Я предполагаю, что вы передаете пользовательский объект, который представляет, кто вызывает метод (есть и другие способы, но это иллюстрирует суть, не говоря о множестве архитектур, которые вы могли бы использовать или не могли бы использовать / нуждаться).
public class Course {
public void enroll( User user, Student student ) {
if( user.hasPermission( Permission.OVERRIDE_COURSE_RULES ) ) {
add( student );
} else if( hasEnrollmentDatePassed() ) {
throw new CourseException( "Enrollment date has passed." );
} else if( isClassFull() ) {
throw new CourseException( "Course is full" );
} else {
add( student );
}
}
}
Несколько моментов, на которые следует обратить внимание: Пользователь не зависит от профессора, студента и т.д. Пользователь может быть конкретным классом или интерфейсом, который реализует профессор, студент и т.д. Вы не хотите привязывать свою систему разрешений к профессору и студенту, потому что ваши сопоставления разрешений не могут измениться, если вы это сделаете. Это означает, что если позже вы захотите разрешить, скажем, аспиранту переопределять правила добавления студентов, вы не сможете изменить эти сопоставления разрешений без изменения кода. Поэтому всегда используйте «глаголы» или действия для разрешений. Сопоставьте набор разрешений пользователю, затем не проверяйте, чтобы типы пользователей использовали эти глаголы для включения функциональности.
Ответ №2:
Что, если бы у вас был интерфейс с методом
public void studentEnroll(Student s);
и другой интерфейс на процессорах может получить доступ, который является
public void professorEnroll(Student s);
Существует так много способов, которыми вы могли бы это сделать. Я предлагаю вам подумать о том, каким было бы самое простое решение.
Ответ №3:
У вас мог бы быть дизайн, подобный:
class Course
{
public void enroll(Person actionGenerator, Student student)
{
if ( actionGenerator instanceof Professor )
{
//bypass verification
}
else
{
}
}
}
interface Person
{
/*....*/
}
class Student implements Person
{
public void registerStudent(Course c)
{
c.enroll(this,this);
}
}
class Professor implements Person
{
public void registerStudent(Course c, Student s)
{
c.enroll(this,s);
}
}
Ответ №4:
Я обнаружил, что люди часто путают классы / участников внутри системы с людьми / участниками вне системы: они скажут, что «Мы не можем доверять классу Student хранение остатка денежных средств студента, потому что мы не можем доверять это (людям) студентам; они могут солгать!» Помните: Вы управляете кодом, который вы помещаете в класс Student, и тем, что он делает. Фактические учащиеся не программируют экземпляры, которые их представляют. То же самое для класса Professor.
Итак, вообще говоря, вы устанавливаете безопасность и разрешения на основе процесса, который вы разрабатываете. IE: как вы определяете и используете методы ваших классов.
Вашей системе необходимо знать, записывается ли учащийся в класс напрямую, или его записывает преподаватель класса. Обычно это подразумевает, что система должна знать, является ли пользователь, вошедший в систему в данный момент, студентом или профессором. Возможно, имеет смысл предоставить преподавателям разные экраны, которые вызывают разные методы.
В производственном коде я бы, вероятно, использовал локальное хранилище потоков для отслеживания разрешений текущего пользователя. Но это, вероятно, многовато для студенческого задания.
Честно говоря, я не понимаю, как внедрение интерфейсов Java помогло бы. Вероятно, помогло бы тщательное обдумывание интерфейсов (методов), которые вы используете, и когда вы их используете.