Как ограничить вызов метода владельцем объекта?

Question

[Pe3oHaHc]

Добрый день! Я пишу небольшой фреймворк на Java, основанный на акторной модели и обеспечивающий простое взаимодействие потоков.

У меня возникла необычная проблема! Мне нужно чтобы некоторый метод объекта мог быть вызван только из его объекта-контейнера.

Суть вот в чем: у меня есть объект Event (событие). На событие, с помощью метода subscribe() могут подписываться другие персонажи (потоки), когда событие возникает, все эти персонажи получают об этом уведомление. Т.е. метод subscribe() должен быть открыт для всех персонажей программы (для всех потоков). С этим проблем нет — это решает модификатор public.
В свою очередь, метод Event.addReaction() добавляет к событию реакцию, которая должна быть незамедлительно выполнена персонажем-владельцем события. Доступ к этому методу должен иметь только владелец события, т.к. нельзя чтобы персонажи реагировали на чужие события никак иначе кроме после получения сообщения.

Вот кусок утрированного кода:

class Person
{
   Event mItDone = new Event();

   public Person()
   {
       mItDone.subscribe(AnotherPerson);       //AnotherPerson получит сообщение при наступлении события

       mItDone.addReaction(new myReaction());    //myReaction будет выполнено сразу при наступлении события
   }

   private void eventOccurs()
   {
       mItDone.fire();                //Запускает событие (fire не должен быть доступен ни для кого кроме этого экземпляра Person
   }

   class myReaction extends Reaction
   {
      react()
      {
           //Реакция этого персонажа на событие mIdDone;
      }
   }
}

Вот и получается, что мне для правильного функционирования объекта класса Event нужно чтобы методы addReaction() и fire() были доступны только для того объекта, в котором он содержится. Помог бы какой-нибудь специальный модификатор доступа, но таких нет(

Есть мысли?

Answer 1

[mayorovp]

Вариант первый — минимальная защита от индуса:

class Event {
  public void subscribe(...) {}
}

class OwnedEvent extends Event {
  public void fire(...) {}
  public void addReaction(...) {}
}

Владелец события создает объект класса OwnedEvent, но перед передачей его другим объектам приводит к Event. При попытке приведения события обратно — больно бить по рукам.

Вариант второй — максимальная защита от индуса, но с повышенным расходом памяти.

class Event {
  public void subscribe(...) {}

  public static class Owner {
    private final Event event = new Event();

    public void fire(...) {}
    public void addReaction(...) {}

    public Event getEvent() { return event; }
  }
}

Смысл в том, что при таком подходе класс Event.Owner должен иметь доступ к приватным полям класса Event, чем и можно воспользоваться.

PS на Java не писал ничего уже 4 года, могу накосячить с синтаксисом. Надеюсь, это не помешает пониманию написанного.

Comments

[Pe3oHaHc]

Второй вариант несколько неясен, но первый вариант мне нравится. Можно сделать OwnedEvent приватным для владельца классом, что предотвратит создание объектов этого класса вне него. Спасибо! Это шикарно)

[mayorovp]

Делать EventOwner приватным я бы не советовал, потому что тогда событиями сможет обладать только человек, но не чайник. А у чайника могут быть свои события. Лучше все-таки постараться понять второй вариант, или оставить EventOwner публичным.

[sigod]

Что-то не очень понятно, как вы собираетесь получать доступ к не статичному Event из статичного подкласса? Да, приватное поле с Event я вижу, но в таком случае у вас на всю систему будет не более одного владельца событий.

[mayorovp]

Обратите внимание: приватное поле event не является статическим.

[Pe3oHaHc]

Мм, минут пятнадцать глядел на второй пример. Либо что-то не правильно либо я торможу) Я не могу понять как должны применяться объекты этих классов. В классе-владельце события я должен создавать публичный объект Event и приватный Event.Owner? Может тогда следует сделать Owner внутренним классом вместо статического?

class Event
{
   public void subscribe(...){}

   public class ForOwner
   {
      fire(...){}
      addReaction(...){}
   }
}

Если так, то это менее кривой способ чем все остальные) Попробую его.

[mayorovp]

Вот так (модифицировал ваш код):

class Person
{
   private final Event.Owner mItDone = new Event.Owner();

   public Person()
   {
       mItDone.addReaction(new myReaction());    //myReaction будет выполнено сразу при наступлении события
   }

   private void eventOccurs()
   {
       mItDone.fire();                //Запускает событие
   }

   public Event getEvent()
   {
      return mItDone.getEvent(); // Предоставляем другим классам возможность подписаться на событие.
   }
}

[mayorovp]

А делать класс Owner внутренним нельзя, поскольку тогда любой сможет создать нового Ownerа для события.
Есть вариант сделать внутренним класс Event, по отношению к Ownerу, но они мне кажется не таким красивым.

[sigod]

mayorovp, да, вы правы. Запутался со статичным подклассом в классе. Плюс за идею.

[Pe3oHaHc]

Мм, да, получается без интерфейса вроде HasEvents все равно не обойтись, т.к. надо чтобы у всех имеющих события классов был в наличии метод getEvent(). Это грустно(

Я тут подумал, можно пойти другим путём. Я могу обеспечить проверку на доступ в том случае, если объекты Event будут знать в каком объекте они находятся, а методы addReaction() и fire() будут знать из какого объекта они вызываются. И если если среда не позволяет предоставить им эту информацию на этапе компиляции можно сделать это на этапе выполнения. Получится что-то вроде:

class Event
{
   private Object mContainer;

   public Event(Object container) { mContainer = container; }

   public void fire(Object caller) { /*проверить что mContainer равно caller. Если что - кинуть исключение. */ }
   public void addReaction(Reaction reaction) { /* проверить где содержится reaction и какого типа mContainer и действовать соответственно.*/ }
}
class Reaction
{
   Object mContainer;   

   public Reaction(Object container) { mContainer = container; }
   public abstract void react(...);
}

С такой схемой придется условиться передавать this в конструкторы Event, Reaction и в метод fire(), чтобы дать Event'у нужную информацию. Это не идеально, но близко к тому что я хотел. Да, конечно, вместо this можно передать что-то другое и в этом случае всё пойдет коту под хвост, но подумав я понял что этот вариант меня устраивает так как я пишу этот фреймворк в основном для того чтобы обкатать новые понятия и если я и буду пускать его в продакшн так только как часть чего-то большего. Так что мне важнее удобство пользования и минимализация возможных ошибок. Спасибо, без вас было бы сложнее)

[mayorovp]

Мм, да, получается без интерфейса вроде HasEvents все равно не обойтись, т.к. надо чтобы у всех имеющих события классов был в наличии метод getEvent().

Вы что-то странное придумали, и теперь решаете несуществующую проблему.

У вас же не стоит задачи «подписаться на все события произвольного объекта»? Вместо этого у вас стоит задача «подписаться на конкретное событие объекта класса Person». Интерфейс тут не нужен, разве что вы собираетесь подписываться на события из файла конфигурации.

А тот вариант, который придумали вы — ерунда. Никто не помешает индусу передать person вместо this в качестве аргумента.

[Pe3oHaHc]

Ок, а когда у Person множество событий? Делать для каждого из них метод получения события + объект внутри?
Насчет моего варианта повторюсь, для меня главное удобство использования. Проблема для меня была не в том чтобы сделать максимальную защиту от индуса, а чтобы позволить мне быстро и просто создавать события у различных объектов и быстро и просто на них подписываться. И загвоздка была в том, что я сам, а не индус, мог подписать на событие то и тех, кого подписывать нельзя, и, естественно, не заметить это. А потом долго и трудно искать почему у меня потоки вмешиваются в работу друг друга и портят результаты. Тот вариант, что предложил я, мою проблему решает :) Возможно я недостаточно ясно изложил свои пожелания вначале, за что прошу прощения. Я в первый раз прибег к помощи подобного ресурса и еще не научен правильно излагать проблему. Но я исправлюсь, надеюсь :)

[sigod]

Удобство говорите? А как быть если код возвращает Object, который на деле может быть Person, а может и не быть? Как код может подписаться на события этого объекта? Если конечно объект способен создавать события.

[Pe3oHaHc]

Мм, объект может содержать события. Но динамически создавать их не может никто. А в случае Object я использую instanceof чтобы проверить является ли объект Person'ом или нет.
Вообще поддержка событий не помешала бы языку. В C#, например, есть такая. Будь она и в джаве — не пришлось бы так мучаться.

[Pe3oHaHc]

Хотя я кажется вас не правильно понял… что вы имеете ввиду под «код может подписаться на события» и «код возвращает Object»? Какой объект вы имеете ввиду под «кодом»?

[sigod]

А в случае Object я использую instanceof чтобы проверить является ли объект Person'ом или нет.

Что вы будете делать, если у вас есть object неизвестного типа, а вам нужно подписаться на его события?

[Pe3oHaHc]

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

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

Если же это объект, то мне надо убедиться, что нет попытки добавить к его событию реакцию персонажа — это привело бы к вмешательству в личное пространство персонажа. Однако, если подписаться на событие объекта пытается другой объект (не персонаж), позволять ему это.

Answer 2

[sigod]

Если я верно понял, вы не хотите чтобы другие объекты могли вызвать mItDone.addReaction() у Person? Тогда почему не пометить mItDone как private, а в Person сделать интерфейс, для сторонних объектов, для подписки?

Comments

[Pe3oHaHc]

Да, я хочу именно этого. Надо чтобы методы addReaction() и fire() мог вызвать только владелец объекта-события.
То что вы предлагаете почти что подходит. Но есть еще один нюанс. Объект типа Event может присутствовать не только у класса Person. Он так же может быть у любого объекта в системе. И реализовывать в каждом объекте лишний интерфейс будет неудобно. К тому же я не хочу ограничивать доступ к событиям т.к. это усложнит синтаксис работы с ними.

[sigod]

Такой интерфейс можно сделать через наследование.

Создайте базовый класс, например, EventEmitter. В нем создайте необходимые методы: subscribe отметьте как public, а addReaction и fire — protected.

После этого отнаследуйте Person от EventEmitter: public class Person extends EventEmitter.

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

Справедливости ради, стоит заметить, что классы находящиеся в одном пакете с EventEmitter все равно смогут вызывать скрытые методы. Ибо в Java нельзя одновременно разрешить доступ для sub-классов и запретить для пакета: access control.

[Pe3oHaHc]

Нехорошо наследовать то, чем объект не является. Person это всё таки «человек» и он мог бы наследоваться от, например, класса Human. К тому же события может содержать любой объект и если он уже от чего-то унаследован эта схема рушится. Но в целом мысль правильная. Всё это решается с помощью интерфейса. Только вот выглядеть это всё будет совсем не лаконично(

[sigod]

Тогда сделайте EventEmitter интерфейсом, напишите базовую реализацию — BaseEventEmitter, от которой и наследуйте когда можно. Когда нельзя — имплементируйте интерфейс EventEmitter.

[Pe3oHaHc]

Этот вариант сработает, не спорю. Но он довольно трудоемок. Придется вводить идентификаторы событий, наследовать все корневые объекты от базового класса, реализовывать каждый раз вручную интерфейс там где не получилось унаследовать базовый класс. Слишком много мороки) К тому же, если появится еще что-то подобное событиям, то применить эту схему еще раз не получится — придется доставать костыли. Я попробую способ с внутренним классом, но спасибо за попытку)

Answer 3

[Tully]

Мне кажется тут некоторое смешение понятий. Модификаторы private/public нужны в момент написания кода, для того чтобы проверить что программисты правильно понимают задачи.
В рантайме они не нужны. Пометить как-то в момент написания классов инстансы этих классов при помощи ключевых слов нельзя.
Если нужно отличать инстансы Person друг от друга (например, чтобы один отреагировал на событие, а остальные нет) заведи в этом классе поле с уникальным идентификатором и проверяй в рантайме права доступа на их основе.

Comments

[Pe3oHaHc]

Хорошо, права доступа между персонажами я могу распределить. Я могу проверять в методе тот ли поток, который создавал событие, пытается выполнить эти методы. Но всё равно остается проблема с объектами, которые не являются персонажами. Например, электрический чайник имеет событие «вода вскипела». Это событие может инициировать только чайник, но «подписаться» и следить за ним может любой человек в комнате. И получается что чайник имеет полный доступ к событию, а люди в комнате могут только подписаться на событие.
Всё это можно реализовать через интерфейсы, но это будет очень неудобно в пользовании. Я бы очень хотел чтобы для работы с событием было достаточно лишь добавить его в класс. Хотя я начинаю подозревать что такое невозможно(

Answer 4

[Alexey Kamchatkin]

сделайте интерфейс Event, с методами addReaction(),fire(), далее делаете классы наследуемые от Person и реализующие интерфейс Event. Получается классы реализуюшие Event будут иметь эти методы а те кто нет — нет. если правильно понял. Также посмотрите паттерн Observer.

Comments

[Pe3oHaHc]

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

Answer 5

[sigod]

(ответ был удален)

Answer 6

[relgames]

Почему бы не упростить до:

class Person {
   private void eventOccurs()    {
       react();
       AnotherPerson.react();
   }

   private react()  {
           //Реакция этого персонажа на событие mIdDone;
    }
}

Ну или если так уж хочется через события:

public interface Event {
    void subscribe(Actor a);
}

public interface FullEvent extends Event {
    void fire();
    void addReaction(...)
}

public class Person {
    private final FullEvent fullEvent = new FullEventImpl();

    public getEvent() {
        return new Event() { // Теперь никак нельзя вызвать fire() - ни через приведение типов, ни через рефлексию. 
            @Override
            public subscribe(Actor a) {
                fullEvent.subscribe(a);
            }
        }
    }
    ....
}

UPD выше привели похожее решение.

Comments

[Pe3oHaHc]

Повторюсь, события могут содержать не только персонажи, но и объекты. В этом случае ваш вариант предполагает написание множества повторяющегося кода.