2015-04-03 6 views
-2

В настоящее время я работаю над проектом, который заключается в создании простого программного обеспечения подобно cloudShare.Наследование Java (новое для Java)

У нас есть 2 типа пользователей, Basic и Premium. Основные из них имеют только 2 ГБ пространства, а Premium - 5 ГБ.

Основные участники не могут делиться своими документами с другими, но могут получать документы членов Премии.

Когда участник премии разделяет документ с основным членом, доступное пространство базового элемента уменьшается на 50% от всего размера документа, в то время как участники Premium могут теоретически получать бесконечные общие документы, из которых они никогда не будут исчерпаны пространство.

В моем классе CloudManager у меня есть массив пользователей (суперкласс), поэтому я могу сохранить как элементы Premium, так и Basic в одном массиве.

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

Но я не могу использовать метод, поскольку он не существует в суперклассе, только в подклассах. Как я могу обойти это?

+1

добавить «абстрактный» метод к суперклассу. –

+5

Пожалуйста, измените свое название на то, что описывает вашу проблему. В настоящее время он совершенно бесполезен. –

+1

Итак, почему бы не добавить абстрактный метод shareDocument к суперклассу и переопределить его в подклассах? –

ответ

1

Если у всех пользователей есть метод shareDocument, вы должны определить его в классе Users. Вы можете определить его как абстрактный метод, что означает, что вы должны реализовать его во всех подклассах, или вы можете обеспечить реализацию по умолчанию в Users и переопределить его в подклассах.

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

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

0

Вы должны рассмотреть вопрос о перепроектировании пользователя как абстрактного класса. Таким образом, вы можете использовать его для совместного использования методов для нескольких классов. Это будет выглядеть примерно так:

public abstract class User { 
    public User() { 
     //common initialization junk 
    } 

    public abstract Object shareDocument(); 
} 

Теперь все, унаследованного от пользователя может легко переопределить метод shareDocument, а также назвать его.

+0

К сожалению, быстро ответил: P. IDK то, что он возвращает тип, будет так, что я ставлю объект –

0

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

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

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

Смежные вопросы