2014-02-13 3 views
0

У меня есть некоторые мысли о совместном использовании объектов.Обмен данными между объектами, свойствами связывания

  • Позволяет определить класс C со свойствами p1, p2 (позволяет думать, что она неизменна).
  • Позволяет иметь некоторые объекты Х и Y класса C.
  • Позволяет создать своего рода «контейнер» G для объектов класса C. «контейнер» G обладает свойством GP1.
  • Позволяет добавить объект X в "контейнер" G и "связывают" X.p1 с G.gp1 значение. (Bind действительно говорит, что, когда объект X пытается получить значение свойств p1 он получает значение GP1.)
  • Давайте добавим объект Y в контейнер G и «связывают» Y.p1 с G.gp1 значение.

Как вы думаете, это простая вещь для людей.

Единственная идея, о которой я думаю, это создать интерфейс для p1, p2 доступ к собственности. Затем реализуйте интерфейс в Класс C (нет общих данных) и Класс GC (с данными контейнера). А затем украсьте объекты, чтобы добавить методы.

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

Вопрос: Как создать операцию связывания типа для каждого объекта? (без внедрения DSL, используя C-производные langauges: java, C#, C++, php, ...)

+0

Вы можете быть заинтересованы в HTTP: // ан .wikipedia.org/wiki/Law_of_Demeter –

+0

Благодарим вас за ссылку. – user1759572

+0

В чем смысл иметь поле в классе и возвращать с помощью другого поля в другом классе? Это очень опасная конструкция. – Gangnus

ответ

0

И где проблема? И для чего нужен p2?

static class G{ 
    int gp1; 
} 
static class C{ 
    int p1,p2; 
    G provider; 
    C(G provider){ 
     provider=this.provider; 
    } 
    int getP1(){ 
     return provider.gp1; 
    } 
} 
static class X extends C{ 
    X(G provider){ 
     super(provider); 
    } 
} 
static class Y extends C{ 
    Y(G provider){ 
     super(provider); 
    } 
} 

Духовность может быть универсальной, только если мы предоставим провайдера по ее интерфейсу. Но вы не хотите его использовать. Универсальное решение без интерфейсов здесь невозможно.

interface IProvider{ 
    int getGp1(); 
} 
static class G implements IProvider{ 
    private int gp1; 
    int getGp1(){return gp1}; 
} 
static class C{ 
    int p1,p2; 
    IProvider provider; 
    C(IProvider provider){ 
     provider=this.provider; 
    } 
    int getP1(){ 
     return provider.gp1; 
    } 
} 
static class X extends C{ 
    X(G provider){ 
     super(provider); 
    } 
} 
static class Y extends C{ 
    Y(G provider){ 
     super(provider); 
    } 
} 

И, пожалуйста, обратите внимание, что наличие поля в классе и возвращение к геттеру другого поля в другом классе очень не-интуитивное и опасное сооружение

+0

Проблема в том, что X и Y построены для конкретного контейнера и не могут использоваться без него. Поэтому, чтобы создать универсальный объект, вам нужно создать больше классов, и это то, чего я не хочу. – user1759572

+0

@ user1759572 Он может быть универсальным только в том случае, если мы предоставим провайдера по его интерфейсу. Но вы не хотите его использовать. Универсальное решение без интерфейсов здесь невозможно. – Gangnus

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