Смысл указания класса, как final?

[_vampiro_]

Смысл указания класса, как final?

Новая версия Пыха рулит безбожно, и тут не поспорить. Вроде "понимаю" смысл всего пока, но это слово ставит меня в тупик. Зачем? Какова может быть практическая ценность от объявления класса финальным?

ООПшники, поделитесь мыслёй!

Чтобы "случайно" его не пронаследовать? Или такие классы меньше места жрут в оперативке... ?

 

[ТопольМ]

и чтобы "случайно"
и чтобы "намеренно"
а насчет оперативки - никакой разницы

 

[Гравицапа]

гугль нынче не рулит?

 

[_vampiro_]

ТопольМ
можно любой пример применения? Разумный... желательно.

class myCMS {}? Как защиту от копирования? ))

-~{}~ 30.06.06 13:40:

Гравицапа
гугль рулит всегда. Я понимаю - какой будет эффект. Не понимаю - где и когда такой эффект может понадобится.

-~{}~ 30.06.06 13:41:

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

 

[ТопольМ]

_vampiro_
практическая ценность очевидна
например:
есть коммерческая библиотека с классами, закодированная зендом и опубликованы только интерфейсы всех этих классов
одевидно что при использовании этой библиотеки найдутся люди, которые захотят "дополнить/изменить" поведение какого-либо класса, чего, напротив, очень не хотят разработчики этой библиотеки
и тут им на выручку приходит final!

 

[Gorynych]

_vampiro_

да очень просто - не дать возможность породить новый класс с переопределенными методами и нарушить какие-то концептуально-архитектурные связи и зависимости.Фактически, это удобный фиксинг состояния некоторой ветки в иерархии классов.

например, у меня есть класс, отвечающий за окружение сеанса. Логично, что он реализован через шаблон класса-одиночки (Singleton) и я хочу инкапсулировать в него всю работу с сеансовыми переменными и окружением.

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

поэтому я его финализирую.

 

[_vampiro_]

<?php

//----------------------- zend encoded begin
interface iPublic {
    public function MakeSecretKey($key);

    public function is_Dinner();
}

final class Microsoft_protected implements iPublic  {

      public function MakeSecretKey($key){
        return $key*2;
    }

    public function is_Dinner(){
        if (date('H')=='1') return true;
    }
}
//----------------------- zend encoded end.

//-- hm...
class Rusian_OS {

    public function MakeSecretKey($key){
        $Microsoft = new Microsoft_protected();
        return $Microsoft->MakeSecretKey($key);
    }

    public function is_Dinner(){
        return true;
    }
}

$OS = new Rusian_OS();
echo $OS->MakeSecretKey(2);
if ($OS->is_Dinner()) die('GO HOME!!!');

 

[svetasmirnova]

ТопольМ
Не приходит: это легко обойти агрегацией.
_vampiro_
final class DSN {}
фабрики, и в Java API можно посмотреть где ещё final используется (http://java.sun.com)

 

[_vampiro_]

svetasmirnova
про DSN не понял в виду оттсутствия опыта.
Про фабрики... Я еще не сильно в теме Паттернов, можно пример?

Я представляю, что это метод, возвращающий объект. Что мешает заюзать parent::fabric()? в потомке. Может мой потомок хочет проставлять специфические свойства для вновьсозданного объекта? Например, для тех же мыльников - кодировку.

 

[ТопольМ]

svetasmirnova

ТопольМ
Не приходит: это легко обойти агрегацией.

я имел ввиду финальный класс
агрегирующий класс не будет наследником финального класса

-~{}~ 30.06.06 14:25:

Может мой потомок хочет проставлять специфические свойства для вновьсозданного объекта?

Если не хочешь использовать final - не используй
Все на усмотрение разработчика

 

[svetasmirnova]

ТопольМ
>агрегирующий класс не будет наследником финального класса
Конечно не будет, но как сымитровать наследование показал _vampiro_ выше
_vampiro_
>про DSN не понял в виду оттсутствия опыта.
Data Source Name для коннекта с базой. Подобный пример подробно Gorynych расписал.
>Я еще не сильно в теме Паттернов, можно пример?
И в поиске полно тем, и в факе наверняка есть. Да:

class factory {
public function getFoo() {
return new Foo();
}
}

>Может мой потомок хочет проставлять специфические свойства для вновьсозданного объекта?
А вот чтоб неповадно было
На самом деле именно для того, чтобы потомок не изменял специфические свойства родителя.

 

[_vampiro_]

то есть фактически final - это что-то навроде комментария для себя (и других), что этот класс доделан, отлажен, и расширять его не требуется? Практического функционала (скорость создания объекта в памяти, и т.д.) оно не несет.

Вроде понял. Спасибо.

 

[StUV]

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

зы: (с) перефразированный Б.Страуструп - только он более кратко и красиво сказал - точно не помню...
=)