I made the same logic change for AdministratorApplication. @dgrammatiko I guess many of these code was implemented by yourself, so it would be great if you could review/test this PR. Thanks !

I made the same logic change for AdministratorApplication.

@joomdonation Are title and description of this PR still right after that change?

@richard67 I updated the title to reflect the additional change

Thanks, maybe we can complete the optimization and move the
CMSApplication::getTemplate() to CMSApplication::initialiseTemplate()
and the new code fore
SiteApplication::getTemplate() to CMSApplication::getTemplate()

// this code should be the same for all 3 Applications
if (!\is_object($this->template)) {
    $this->initialiseTemplate();
}

if ($params) {
    return $this->template;
}

return $this->template->template;

Remove SiteApplication::getTemplate() because it's in CMSApplication::getTemplate() now
Remove AdministratorApplication::getTemplate() because it's in CMSApplication::getTemplate() now
Remove ApiApplication::getTemplate() because it's in CMSApplication::getTemplate() now

if 3rd Party extensions extend the CMSApplication they would have already overridden getTemplate() or will still get the same "system" template as before.

Or do I miss something?

Nice idea. Thanks @HLeithner

if 3rd Party extensions extend the CMSApplication they would have already overridden getTemplate() or will still get the same "system" template as before.

We do not have to worry about this one. The CMSApplication initialiseTemplate method will still set the template to system like before, so there is no backward incompatible change here. If we want, we can even use same logic for Installation application. Let me know if you want me to do that or we should leave Installation app as how it is.

Yes of course, I missed the installer but yes that should also use the new method.

@AlterBrains @dgrammatiko it's a rearrange not a refactoring, if you like to change this please create own PR so they can be tested in an isolated way, thanks.

Thanks @AlterBrains @dgrammatiko for your review and suggested changes. I applied all the suggestions which I find safe to be included in this PR. For other details, while I agree with most it, I don't want to include in this PR to avoid too much details changes, which makes it harder for maintainers/release managers to review. It can always be improved later in a separate PR

@AlterBrains About your suggestions about making the methods protected, not private: The reason I have it private because I think the logic in these methods really suitable for SiteApplication (getTemplates for example, call model to get site template style, so I don't think a class which extends SiteApplication will need to re-use it). Having methods as protected make it more flexible, allow custom code to extends it, but it also hold us back if we want to improve it in the future due to backward compatible promise. The method findTemplate for example, it is just an utility method and maybe have it as a member of SiteApplication for now, maybe in the future, we can introduce a new class (TemplateHelper or TemplateService..., something like that) to replace that, and having the method as private allow us to safe to remove.... I will ask Harald about it, but for now, I will keep these methods as private.

@joomdonation Many thanks for applying the changes, I am sure that we should add even small improvements with each PR to keep the code modern and efficient, but not just apply simple refactoring. There are not so many developers and PRs are not merged fast.
Agree, moving template logic into a separate utility service sounds great, but it's really time-cost effort right now. I still dislike private and final statements in open source code, along with implicit class name requirements, but we can leave with this class for now.