Можно ли детально определить область видимости классов?
Доброго здоровья!
Пытаюсь разрабатывать архитектуру программы. Допустим есть 4 класса (не наследники, не интерфейсы),
Например:
Engine занимается обработкой физических взаимодействий тел.
Entity - класс персоналий, которые могут совершать действо.
Action - класс действий: любые действия которые могут быть совершены.
Draw - отрисовка интерфейса, вывод графики.
Крутится такая мысль: изменять значения полей класса Entity - может только класс Engine. Остальные классы не должны иметь возможность как либо влиять на класс Entity.
Как можно это дело реализовать? Возможно ли вообще определить каким классам есть доступ к целевый классам, а каким нет? Обычной области видимости не хватает, т.к. все описанные классы пока что находятся в одной сборке. Я подумываю реализовать это через интерфейсы. Entity : MyInterface; Соответственно класс Engine будет обрабатывать только те объекты, которые поддерживают соотвествующий интерфейс.
Может быть я не правильно подхожу к вопросу? Что стоит почитать?
Пытаюсь разрабатывать архитектуру программы. Допустим есть 4 класса (не наследники, не интерфейсы),
Например:
Engine занимается обработкой физических взаимодействий тел.
Entity - класс персоналий, которые могут совершать действо.
Action - класс действий: любые действия которые могут быть совершены.
Draw - отрисовка интерфейса, вывод графики.
Крутится такая мысль: изменять значения полей класса Entity - может только класс Engine. Остальные классы не должны иметь возможность как либо влиять на класс Entity.
Как можно это дело реализовать? Возможно ли вообще определить каким классам есть доступ к целевый классам, а каким нет? Обычной области видимости не хватает, т.к. все описанные классы пока что находятся в одной сборке. Я подумываю реализовать это через интерфейсы. Entity : MyInterface; Соответственно класс Engine будет обрабатывать только те объекты, которые поддерживают соотвествующий интерфейс.
Может быть я не правильно подхожу к вопросу? Что стоит почитать?
Крутится такая мысль: изменять значения полей класса Entity - может только класс Engine. Остальные классы не должны иметь возможность как либо влиять на класс Entity.
Как можно это дело реализовать?
Как можно это дело реализовать?
Например, используя дружественный класс:
Код:
#include <iostream>
class Entity {
public:
Entity():a(0) {};
int get_a() {
return a;
}
private:
int a;
friend class Engine;
};
class Engine {
public:
void set_Entity_a(Entity& e, int n) {
e.a = n;
}
};
int main() {
Entity e;
Engine eng;
eng.set_Entity_a(e,15);
std::cout << e.get_a() << std::endl;
return 0;
}
class Entity {
public:
Entity():a(0) {};
int get_a() {
return a;
}
private:
int a;
friend class Engine;
};
class Engine {
public:
void set_Entity_a(Entity& e, int n) {
e.a = n;
}
};
int main() {
Entity e;
Engine eng;
eng.set_Entity_a(e,15);
std::cout << e.get_a() << std::endl;
return 0;
}
ftphost на каждом сайте есть , свои CopyPaste так вот sadovoya и есть дать ответ в не куда.
По теме
По теме
Крутится такая мысль: изменять значения полей класса Entity - может только класс Engine. Остальные классы не должны иметь возможность как либо влиять на класс Entity.
Класс изменить нельзя, можно только создать новый класс на базе main-class и add свои свойства. Это есть принцип Класса.
Теперъ на сщёт :
friend - это есть видимость ~N~ между субъектами.
Насчет почитать. Похоже, лучшая книга по проектированию - "Приемы объектно-ориентированного проектирования. Паттерны проектирования." от "Банды Четырех". Примеры, правда на C++ и Smalltalk в ней. Но теория, идеи - универсальны. Можно и другую литературу по паттернам поискать, адаптированную к C#, например.
спасибо за ответ. а можно ли это как нибудь в c#?
Прямых аналогов нет. Но, можно сделать так. Какой-нибудь метод Entity в качестве параметра получает объект Engine, считывает с него нужные данные и сам исходя из них меняет свои закрытые поля, запускает методы и т.п.
А так ли нужна эта избирательность доступа? В конце концов, программа может открытые сеттеры Entity использовать только оттуда, откуда вы их вызываете. Не для защиты же от самого себя? Пусть сеттеры Entity вызывает только Engine, но следит за этим правилом программист. Эту логику работы можно описать в комментариях, документации и т.п. Engine может получать в каком-нибудь своем методе по ссылке Entity и настраивать его. Что лучше - так сразу не ясно.
А так ли нужна эта избирательность доступа? В конце концов, программа может открытые сеттеры Entity использовать только оттуда, откуда вы их вызываете. Не для защиты же от самого себя? Пусть сеттеры Entity вызывает только Engine, но следит за этим правилом программист. Эту логику работы можно описать в комментариях, документации и т.п. Engine может получать в каком-нибудь своем методе по ссылке Entity и настраивать его. Что лучше - так сразу не ясно.
Спасибо огромное за ответы. Пошел курить мануалы.