Финализация методов. Какой в этом смысл?

Чтобы запретить наследование типов и переопределение методов.

Таким образом разработчик, который писал этот тип, намекает, что наследование или переопределение тут будет неправильным подходом к использованию типа. Ну или просто он дебил, что бывает чаще.

Ну вот мне как раз нужно переопределить метод. В нем кэширование происходит и кэшируется не все. Мне, в моей задаче надо кое-что еще докинуть в кэшируемые данные и если раньше я просто переопределял метод то теперь хренушки... Приходится выключить кэширование, потому что из кэша не возвращаются данные которые мне нужны - они тупо туда не попадают (((

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

Это какой-то паблик код, на него можно посмотреть?

http://pastebin.com/2aqJaA5x

Метод showComponentTemplate. Мне он нужен примерно в таком виде:

function ShowComponentTemplate()
	{
		
		if (!$this->__bInited) {
			return null;
		}
		
		ob_start();
		
		if ($this->__template) {
			$this->__template->IncludeTemplate($this->arResult);
		}

		if(is_array($this->arResultCacheKeys)) {
			$arNewResult = array();
			foreach($this->arResultCacheKeys as $key) {
				if(array_key_exists($key, $this->arResult)) {
					$arNewResult[$key] = $this->arResult[$key];
				}
			}
			$this->arResult = $arNewResult;
		}
	

		if(!empty($this->__editButtons)) {
			foreach($this->__editButtons as $button) {
				if($button[0] == 'AddEditAction') {
					$this->AddEditAction($button[1], $button[2], $button[3], $button[4]);
				} else {
					$this->AddDeleteAction($button[1], $button[2], $button[3], $button[4]);
				}
			}
		}

		if(!empty($this->__view)) {
			$this->__template->EndViewTarget();
		}
		
		$html = ob_get_contents(); 
		ob_end_clean();
		
		$arFinalResult['HTML'] = $html;
		$arFinalResult['RESULT'] = $this->arResult;
		$this->arResult = $arFinalResult;

		$this->EndResultCache();
	}

EndResultCache загоняет в кэш $this->arResult, а мне еще выхлоп надо туда же сунуть. Это я правда сейчас прямо здесь написал не сильно думая, просто как пример как это должно выглядеть.

Нет, так сильно повлиять на логику ты теперь не можешь

Ну вот это и удручает (((

Финализация методов. Какой в этом смысл?

Смысл в том, что фиксить метод через наследование есть костыль, например. Но так как править код битрикса тоже не очень, тебе можно посочувствовать :)

А убрать это слово из метода никак? :-)

И что это даст? Мне нужно общее решение, а не правка ядра битрикса. Но даже в частном случае, следующий разраб проапдейтит ядро битрикса, класс заменится на штатный, и получить граблями по лбу? Решение должно быть надстройкой, а не изменением основного кода.

Смысл в том, что фиксить метод через наследование есть костыль, например.

Я понимаю. Раньше такое только для дебага использовал. Но вот жеш понадобилось и тут такие грабли. Обходной путь на самом деле есть но он не очень надежный и только для моих решений, а обобщенного решения не получится выходит (((

И что это даст? Мне нужно общее решение, а не правка ядра битрикса. Но даже в частном случае, следующий разраб проапдейтит ядро битрикса, класс заменится на штатный, и получить граблями по лбу? Решение должно быть надстройкой, а не изменением основного кода.

Прикрути свои костыли в виде запуска sed после каждого обновления ядра bitrix.

мой уютный пхп катится в сраную джаву :(

И что это даст? Мне нужно общее решение, а не правка ядра битрикса.

Одна из множества причин, по которым я категорически отказываюсь от заказов, связанных с использованием Битрикса :)

Агругируй @ проксируй

без финальных классов/методов нельзя реализовать immutable объекты. в некоторых случаях нужно чтобы наследник не забыл вызвать parent метод, тогда делают реализацию финальной и добавляют абстрактную не финальную заглушку для переопределения. любая возможность языка приведет к тому, что найдется идиот и воспользуется ей не по назначению.

Например, в целях того, чтобы было проще делать апгрейды между версиями платформы. А то вот понабегут умельцев рыться в чужом коде, а потом при обновлении с 1.0.0 на 1.0.1 все встает колом. Разраб как бы намякивает тебе: ЭТОТ КОД РУКАМИ НЕ ТРОГАТЬ, брысь отсюда.

Анонимус правильно подсказывает.

Ну и как бы вопрос сводится вот к чему - это что за случай такой, для которого необходимо запретить переопределения метода?

Разработчики не могут гарантировать правильное кэширование определяемых позднее данных при наследовании. Что тут неясного?

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

Разработчики не могут гарантировать правильное кэширование определяемых позднее данных при наследовании.

Прекрасно. Дайте мне гарантировать.

Сейчас я уперся в класс, который разрабы на радостях переписали с финализированными методами и теперь не знаю что мне делать...

Внезапно, классы можно не только наследовать, но и вкладывать.

Яростно плюсую.

Проблемы декораторов в том, что они могу работать с паблик интерфейсом типа и это все работает только, если нужно добавить функциональности к существующей реализации не меняя ее, а ТСу надо более сильное вмешательство в логику.