Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: 6458
Последний выпуск: 19.06.2015

Можно ли детально определить область видимости классов?

13K
06 февраля 2015 года
ftphost
11 / / 10.12.2007
Доброго здоровья!

Пытаюсь разрабатывать архитектуру программы. Допустим есть 4 класса (не наследники, не интерфейсы),

Например:
Engine занимается обработкой физических взаимодействий тел.
Entity - класс персоналий, которые могут совершать действо.
Action - класс действий: любые действия которые могут быть совершены.
Draw - отрисовка интерфейса, вывод графики.

Крутится такая мысль: изменять значения полей класса Entity - может только класс Engine. Остальные классы не должны иметь возможность как либо влиять на класс Entity.

Как можно это дело реализовать? Возможно ли вообще определить каким классам есть доступ к целевый классам, а каким нет? Обычной области видимости не хватает, т.к. все описанные классы пока что находятся в одной сборке. Я подумываю реализовать это через интерфейсы. Entity : MyInterface; Соответственно класс Engine будет обрабатывать только те объекты, которые поддерживают соотвествующий интерфейс.

Может быть я не правильно подхожу к вопросу? Что стоит почитать?
315
06 февраля 2015 года
sadovoya
757 / / 19.11.2005
Цитата:
Крутится такая мысль: изменять значения полей класса 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;
}
321
07 февраля 2015 года
UserNet2008
744 / / 03.04.2010
ftphost на каждом сайте есть , свои CopyPaste так вот sadovoya и есть дать ответ в не куда.
По теме
Цитата:
Крутится такая мысль: изменять значения полей класса Entity - может только класс Engine. Остальные классы не должны иметь возможность как либо влиять на класс Entity.


Класс изменить нельзя, можно только создать новый класс на базе main-class и add свои свойства. Это есть принцип Класса.
Теперъ на сщёт :
friend - это есть видимость ~N~ между субъектами.

315
07 февраля 2015 года
sadovoya
757 / / 19.11.2005
Насчет почитать. Похоже, лучшая книга по проектированию - "Приемы объектно-ориентированного проектирования. Паттерны проектирования." от "Банды Четырех". Примеры, правда на C++ и Smalltalk в ней. Но теория, идеи - универсальны. Можно и другую литературу по паттернам поискать, адаптированную к C#, например.
13K
06 февраля 2015 года
ftphost
11 / / 10.12.2007
спасибо за ответ. а можно ли это как нибудь в c#?
315
06 февраля 2015 года
sadovoya
757 / / 19.11.2005
Прямых аналогов нет. Но, можно сделать так. Какой-нибудь метод Entity в качестве параметра получает объект Engine, считывает с него нужные данные и сам исходя из них меняет свои закрытые поля, запускает методы и т.п.
А так ли нужна эта избирательность доступа? В конце концов, программа может открытые сеттеры Entity использовать только оттуда, откуда вы их вызываете. Не для защиты же от самого себя? Пусть сеттеры Entity вызывает только Engine, но следит за этим правилом программист. Эту логику работы можно описать в комментариях, документации и т.п. Engine может получать в каком-нибудь своем методе по ссылке Entity и настраивать его. Что лучше - так сразу не ясно.
13K
08 февраля 2015 года
ftphost
11 / / 10.12.2007
Спасибо огромное за ответы. Пошел курить мануалы.

Знаете кого-то, кто может ответить? Поделитесь с ним ссылкой.

Ваш ответ

Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог