Private methods in Controller in MVC project - php

Question

is it OK if I have private methods in the controller in a MVC project? I mean, is it a good practice?
Here is what I mean:
I have a method settings in my User controller which is for changing emails and passwords.
public function settings($settings)
{
/**
* Check if the user is logged in
*/
$auth = new Authenticate($this->user_type);
if(!$auth->isUser())
{
redirect(SITE_ADDR.'/public/home');
}
switch ($settings)
{
default:
error_404();
break;
case "email":
self::change_email();
break;
case "password":
self::change_password();
break;
}
}
And as you can see the switch in this method is calling other methods from the same class which are private. The reason for this is because I don't want someone to manually modify the URL and access the methods and then get all kinds of errors like this: http://localhost/MVC/public/user/change_email
The correct urls have the following structure: http://localhost/MVC/public/user/settings/email.
Currently there are 2 private methods - for changing email and password but I plan on having more - adding profile details (like real name, description, etc.), possibly connecting facebook or other social media accounts, etc. I don't want my settings method to be too long.
So what do you think, is this a good idea?

Answer 1

It is perfectly fine in any OO context to have private methods. Visibility modifiers like protected and private serve to keep your code modular and encapsulated. They prevent that other code is written against it, that some other code outside the class would call those methods. The point of that is that you have more control over what calls what and that you have more confidence to refactor code later on without being unsure about whether you need to keep a certain method around in order to not break other code. A private method can only be called from within the same class, which greatly reduces the amount of code you need to check if you ever rewrite that method.
How that relates to publicly callable URLs is an entirely separate issue. I'd argue that visibility modifiers shouldn't be your primary method of distinguishing between a method exposed as HTTP endpoint and an internal implementation detail. Visibility modifiers are for control over your code coupling, HTTP endpoints should be defined by configuration separately from that. That many frameworks use visibility modifiers as convenience "security" feature for implicitly mapped HTTP endpoints isn't necessarily a good pattern.
Write good OO code in whatever way necessary; if it makes sense to separate some code into a method which doesn't need to be public, then by all means go for a private method.
Configure how URLs map to class methods in some sensible manner.
Don't necessarily conflate those two completely separate things.

Answer 2

Yes, this is an ok practice to follow, as long as the project calls for it

Answer 3

In most cases it is probably a bad practice, as controllers should use services to share logic, and receive those services using dependency injection, which isn't inherent to the MVC pattern, but most recent MVC frameworks use it.
When your controller is only making calls to services and not doing lots of low level logic itself then there really isn't a lot to gain from creating shortcut private methods on your controller to those services or their actions.
Though it does seem preferable to just duplicating all the code everywhere, especially if there are lots of lines of code.
But if you're having that much logic in your controllers it is probably a sign that you should be moving some things to service classes.