Программное самоубийство

[Жека]

Здравствуйте.

Упрощённая модель "убивающего" себя объекта (субъекта-человека), программная реализация.

Делюсь размышлениями. Желающим пнуть по возможности поставлю блок.

Итак.
Допустим, есть желающий покончить с собой. Однако, покончить нужно таким образом, чтобы не оставить следов.

Где он? В какой-то глобальной хеш-таблице или векторе (допустим).

У него есть "метод" Free() или Release(), который освобождает все занимаемые им ресурсы.
И этот метод может быть вызван в момент самоубийства.
Теперь бы только удалиться из вектора! Как это сделать?

Не лучший вариант (это Java-код):

public void Release()
{
    data = null;
    RemoveFromGlobalList(this);
}

А что за функция RemoveFromGlobalList()?
приходит на ум такой её вид:

public static void RemoveFromGlobalList(CObject obj)
{
    CResourceManager.RemoveFromList(obj);
    
    //или через экземпляр
    //resMng.RemoveFromList(obj);
}

Но откуда объекту знать о существовании менеджера? ну есть откуда, например передавать ссылку на него в конструктор объекта. Всегда ли это уместно? Думаю, что нет. Это похоже на "плохой" стиль программирования. (хотя спорная вещь)

А что же остаётся? Вполне естественным представляется такое взаимодействие с менеджером объектов (который имеет ту самую хеш-таблицу), при котором он заведует удалением извне.

И происходить всё может в методах обновления, вот так:

для объекта:

public int Update()
{
    if(subState == SUBSTATE_FULL_DEPRESS || IsLifeTheShit() == true)
    {
        boolean rez = fnTryToDieSomehow();
        if(rez == true)
        {
            Release();
            return STATE_DEAD;
        }
    }
    return 0;
}

public void Release()
{
    data = null;    
}

для менеджера:

public int Update()
{
    int rez;
    CObject obj;
    for(int k=0;k<objCount;++k)
    {
        obj = vectorObjs.elementAt(k);
        rez = obj.Update();
        if(rez == CObject.STATE_DEAD)
        {
            //obj.Release(); //можно тут освобождать память
            vectorObjs.removeElementAt(k);
        }
    }
    return 0;
}

Кстати, "data = null;" убивает указатель на данные, а сами данные живут до вызова System.gc(); (его аналога)
А какой интервал вызова жизненного коллектора? может статься, что не мгновенный.

Ещё: коллектор удаляет те объекты, на которые больше нет ссылок. А на нашего самоубийцу такое распространяется-нет?

например:

man = new CObject();
man.SetName("Женя");
man.SetParents(papa, mama);
man.SetFriend(man1790897);
man24.SetFriend(man); ////ВНИМАНИЕ! ссылка на чувака у man24

и тут ещё:

public void SetParents(CObject pp, CObject mm)
{
    papa = pp;
    mama = mm;
    pp.SetChild(this); //ВНИМАНИЕ! ссылка на чувака у папы
    mm.SetChild(this); //ВНИМАНИЕ! ссылка на чувака у мамы    
}

Конечно, менеджер объектов может занулить все ссылки на суицидника, однако на практике этого не происходит, часто остаётся "память".

Мораль сей басни такова: самоубийца может лишь освободить занимаемые им ресурсы, однако исчезнуть совсем - нет, и это уже решается на уровне менеджера объектов.

вот обновлённый апдэйт:

public int Update()
{
    int rez;
    CObject obj;
    for(int k=0;k<objCount;++k)
    {
        obj = vectorObjs.elementAt(k);
        rez = obj.Update();
        if(rez == CObject.STATE_DEAD)
        {
            if(obj.GetExperience() >= MIN_EXP_FOR_RELEASE)
                vectorObjs.removeElementAt(k);
            else
                RecreateObject(obj);
        }
    }
    return 0;
}

ПС: видимая связь между моей подписью и этой статьёй отсутствует.

До свидания.

[Randomize]

Интересно

1) reference counter форева
2) в случае если убийство описано в методе интерфейсного класса то удаление из менеджера нельзя сделать по логике вещей (хотя физически можно, только это говнокод), ибо мы пишем просто структуру для хранения данных и методы работы с ней
3) удаление надо описывать в классе который имеет возможность работать с манагером
4) хороший тон удалять через манагер, без самоубийств, тогда не нарушается архитектура зависимостей

для некоторых вещей я считерил, к примеру для ресурсов игры бывает такая ситуация что огромную текстуру загрузят, потом откажутся от её использования, а через 4 секунды опять загрузят, делаем чтобы менеджер тоже получал reference на объект, тогда если все откажутся от объекта то всё равно будет один reference - сам манагер, он по этому и определяет нужна кому-то текстура или нет, и когда от неё отказались, сколько времени стоила загрузка и стоит ли выгружать тогда

[Жека]

Сообщение от jimon

1) reference counter форева

Как он поможет субъекту самоудалиться?

Сообщение от jimon

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

Вот это я не понял.

Сообщение от jimon

3) удаление надо описывать в классе который имеет возможность работать с манагером

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

Сообщение от jimon

4) хороший тон удалять через манагер, без самоубийств, тогда не нарушается архитектура зависимостей

Как раз эту мысль я и принёс в массы в статье.