дженерики параметров типа в интерфейсах и конкретных классах

Я создаю что-то подобное, и меня поразило использование дженериков в java.

Идея: Producer производит что-то типа T, а consumers содержит объекты-команды, объекты-команды содержат разные посредники. Медиаторы содержат объекты типа Subject и обновляют значения типа T.

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

Определения интерфейсов:

Сочинение:

  1. IObserver

  2. ISubject, который содержит объект типа T и IObserver.

  3. IMmediator содержит объекты типа ISubject и типа T.

  4. ICommand содержит объекты типа IMediator и типа T.

  5. IProducerConsumer содержит объекты типа T и ICommand.

Есть несколько конкретных объектов для соответствующих интерфейсов. Я определил такие интерфейсы:

public interface IObserver<T>
public interface ISubject<T,O extends IObserver<T>>

Круто до сих пор. Но теперь начались проблемы.

public interface IMediator<T,S extends ISubject<T,O>, O extends IObserver<T>>

Компилятор заставляет меня сделать это. Я имею в виду O extends IObserver<T> как указано выше. Итак, я сделал вывод, что не могу определить, как показано ниже

public interface IMediator<T,S extends ISubject<T,O extends IObserver<T>> >

Я пришел к выводу: это определение параметра внутреннего типа не должно быть расширено, как указано выше. Итак, наконец-то доволен публичным интерфейсом IMediator<T,S extends ISubject<T,O>, O extends IObserver<T>> Теперь в ICommand начался бардак public interface ICommand <T,M extends IMediator<T, ?, ?>>,

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

public interface ICommand <T,M extends IMediator<T, S, o>, S extends ISubject<T, IObserver<T>>,O extends IObserver<T>>

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

Мои вопросы:

  1. Верен ли мой вывод, как в определении ICommand.

  2. Как интерпретировать приведенные выше тематические исследования.

  3. Каковы наилучшие определения, если я хочу вставить T и должен иметь возможность получить и поставить.

  4. Каковы правила и отношения определений параметров типа в интерфейсе и реализованных классах.

Пожалуйста, объясни ?


java inheritance generics type-parameter
person Curious    schedule 03.04.2014    source источник
comment
public interface ICommand<T, M extends IMediator<T, S, O>, S extends ISubject<T, O>, O extends IObserver<T>> работает. Но на самом деле: обычно такое большое количество параметров типа не требуется. Поскольку это очень вымышленно, я не могу сказать вам прямо сейчас, как уменьшить параметры типа. Может еще раз поясните требования (более понятно)?   -  person Seelenvirtuose    schedule 03.04.2014
comment
Ok. Пожалуйста, определите интерфейсы, как показано ниже: Производитель производит что-то типа T, а потребители содержат объекты команд, которые обновляют значения до соответствующего объекта команды, объекты команд содержат разные посредники. Медиаторы содержат объекты типа Subject и обновляют значения типа T.   -  person Curious    schedule 03.04.2014
comment
Хорошо, я увидел, что вы отредактировали структуру своего поста (теперь она более читабельна). Но я все еще не видел всей картины. Не могли бы вы описать роли и назначение каждого из ваших интерфейсов? Кроме того, вы упомянули продукт и потребителя в своем небольшом описании идеи. Но потом вы сказали про интерфейс IPProducerConsumer. Как это подходит? Я действительно готов помочь вам понять этот (вымышленный) сценарий, но я все еще борюсь с требованиями.   -  person Seelenvirtuose    schedule 03.04.2014
comment
Хорошо, забудьте о вышесказанном. Есть 4 класса A,B,C,D и соответствующие интерфейсы. Давайте рассмотрим такие интерфейсы, как IA, IB, IC и ID. Составление следующим образом: IA содержит объекты типа T, IB содержит объекты типа T и составляет объекты A и их подтипы, затем C содержит объекты типа T и B и их подтипы и то же самое. для D. Как сделать все это как generic типы для интерфейсов, а также для конкретных классов. Избегайте использования подстановочных знаков без ограничений. Спасибо за разговор.   -  person Curious    schedule 03.04.2014
comment
Я просто пытаюсь понять состав, интерфейс и конкретные классы универсальных типов, предоставляя компилятору больше информации без особых выводов. Просто исследование.   -  person Curious    schedule 03.04.2014
comment
Для меня это слишком запутанно, не имея представления о том, о чем занятия. Развитие касается поведения, а не только структуры. Извините, я не могу вам помочь, я думаю.   -  person Seelenvirtuose    schedule 03.04.2014

Ответы (1)


arrow_upward
1
arrow_downward

Универсальные шаблоны со связанными параметрами (без подстановочных знаков)

  • Is my inference correct as in ICommand definition?

    No. Two reasons
    1. You have written a small 'o' while passing it to Mediator. (I guess it's just a typing mistake.)
    2. Вы передали IObserver<T> вместо O в ISubject, что определенно вызвало бы несоответствие привязки параметра.

Правильная версия:

interface ICommand<T, M extends IMediator<T, S, O>, S extends ISubject<T, O>, O extends IObserver<T>>
  • How to interpret the above case studies?

    1. The first thing you'd need to understand that you have one unknown type T and five interfaces.
    2. Таким образом, у вас будет всего шесть конкретных типов, которые должны постепенно включаться в объявления интерфейса. (Вы явно просили не беспокоиться о обосновании дизайна.)
    3. Если вы запишете их в правильном порядке, это станет намного более управляемым.

Объявления интерфейса:

interface IObserver<T>

interface ISubject<T, O extends IObserver<T>>

interface IMediator<T, O extends IObserver<T>, S extends ISubject<T,O>>

interface ICommand<T, O extends IObserver<T>, S extends ISubject<T, O>, 
                   M extends IMediator<T, O, S>>

interface IProducerConsumer<T, O extends IObserver<T>, S extends ISubject<T, O>,
                   M extends IMediator<T, O, S>, C extends ICommand<T, O, S, M>>
  • What are the best defintions assuming that I want to insert T and must able to get and put?

    1. If you want to get and put object of type T, what you probably need is bunch of interfaces which take only one parameter T. Generics will enforce that all would be compatible as T will be replaced by same type everywhere.
    2. Ваша текущая система слишком жесткая. В реальном сценарии у вас никогда не будет так много реализаций этих интерфейсов (если вы не повторно реализуете facebook в java), чтобы у вас было много возможных комбинаций реализаций, и вы хотите обеспечить совместимость.
    3. Обобщения обеспечивают безопасность типов, применяя ограничения, которые хороши. Но не стоит ставить ограничения только потому, что вы можете их поставить. Вы теряете гибкость, читабельность и ремонтопригодность своего кода.
    4. Вы должны добавлять границы только тогда, когда они вам нужны. Они не должны влиять на дизайн каким-либо образом до того, как контракты между интерфейсами будут решены.

Возможно, достаточный способ:

interface IObserver<T>

interface ISubject<T>

interface IMediator<T>

interface ICommand<T>

interface IProducerConsumer<T>
  • What is the rules and relations of the type parameter definitions in interface and implemented classes?

    1. The only relation between type parameters in interfaces and implementing class that I can think of is that implementing class has to provide a type to replace the generic type parameter.
    2. В некоторых случаях этот тип снова может быть универсальным типом, и в этом случае ответственность за предоставление конкретного типа передается коду с использованием ссылки на класс или другого класса, который расширяет этот класс. Он может быть даже рекурсивным!
    3. Правила не написаны на языке, вместо этого вы применяете все правила к этому механизму, когда вы связываете любой параметр типа. Итак, пока вы предоставляете тип, который соответствует всем вашим правилам, все в порядке.
    4. Больше правил означает более надежные, но менее гибкие/удобочитаемые. Так что делайте торговлю с умом.

Два простых случая:

// General way
private class ProductObserver implements IObserver<Product> { }

private ProductObserver productObserver;

// Aspect oriented way
private class LoggerObserver<T> implements IObserver<T> { }

private LoggerObserver<Product> loggerObserver;

Надеюсь, это поможет.
Удачи.

person Tanmay Patil    schedule 04.04.2014
comment
Привет, Танмай, так хорошо объяснил и попал в точку, что я действительно хочу понять. Я не могу перестать благодарить вас. Я знаю, что моя цель здесь не в чистом дизайне с применением принципов сплоченности/связывания/внедрения взаимозависимостей и т. д., даже если это выглядит так. Здесь мое намерение заключается в том, как работают несоответствия Bound, сокрытие переменных в контексте композиции и наследования. Одна вещь, которую я получил здесь, чего мы не можем найти в книгах или онлайн-материалах, - это использование определения параметра типа в универсальных типах интерфейса и, более конкретно, при определении конкретных классов. Анджелина Лангер действительно проницательна. Спасибо. - person Curious; 04.04.2014
comment
Рад узнать, что это помогло. - person Tanmay Patil; 04.04.2014