4

What are valid reasons NOT to use keywords public, private, protected in php?

The story: I've started a project with a team that actively uses access modifiers in their code (even "public" explicitly) and wants to convince me to do the same. I always find this kind of stuff totally useless in a dynamic language like php, but I realize that my gut feeling is hardly an argument in a technical discussion. Therefore I'm looking for a solid, clear explanation why access modifiers are useless (or even harmful) in php.

I'm aware that some similar topics already exist

however there are several reasons why I'm posting this one

  • I am not asking if I should use "public" or not. I'm already not using it.
  • I am explicitly not interested to hear why access modifiers are good (I know they're bad, I just need an expert to confirm that).
  • If you're about telling me about "best practices" and "principles of OOP", please do not bother.

TIA

Community
  • 1
  • 1
user187291
  • 53,363
  • 19
  • 95
  • 127
  • 8
    Maybe you could elaborate somehwat on the "I know [access modifiers] are bad" part. – Dennis Haarbrink Sep 16 '10 at 10:01
  • 8
    I _know_ they're good, but judging from your question I'm not even bothering to try to persuade you. The _only_ reason not to use access modifiers IMO is if you're still using ancient PHP 4, in which they're non-existent. – Wrikken Sep 16 '10 at 10:06
  • 1
    Access modifiers make sense in Java/C++ and compiled code in general, where they are **enforceable**. In uncompiled scripting languages they can easily be ripped out. Hence they should be considered just decorators, and thus pragmatically could just be implemented as coding convention. (See underscoritis in Python, and pretty much any other scripting language. PHP is pretty alone with its purposeless access decorators.) – mario Sep 16 '10 at 10:07
  • @mario: What is unenforceable about access modifiers in PHP? – Dennis Haarbrink Sep 16 '10 at 10:09
  • @Dennis Haarbrink: the availability of the backspace key. And RUNKIT_ACC_PUBLIC. – mario Sep 16 '10 at 10:13
  • 1
    @mario: What a non-argument. It has nothing to do with enforceability, but with developers not caring to think about *why* that particular attribute/method is private/protected. And don't get me started about runkit... – Dennis Haarbrink Sep 16 '10 at 10:16
  • @stereofrog: Just a sidenode ;) You won't have much success convincing your teammates about the advantage of useful APIs over encapsulation by restrictiveness. The use of syntax-enforced access decorators is often cargo cult driven. – mario Sep 16 '10 at 10:18
  • @Dennis Haarbrink: My point exactly. Internal APIs can be avoided by professionals without syntax toys. Documentation and convention suffices. – mario Sep 16 '10 at 10:20
  • @mario they are not so purposeless if you think that they are just a code convention, then, maybe it is better to have a clear (and standard?) convention other than a lot of different team conventions – Eineki Sep 16 '10 at 10:26
  • 1
    @mario so basically any language that supports monkey patching does not need Visibility? What about the [Reflection API in Java](http://stackoverflow.com/questions/1796055/is-reflection-breaking-the-encapsulation-principle)? [It let's you change visibility](http://stackoverflow.com/questions/3300680/does-reflection-breaks-the-idea-of-private-methods-because-private-methods-can-b). By your argumentation, this means Java doesn't need visibility either. – Gordon Sep 16 '10 at 10:29
  • 3
    This is a terrible question; it presumes an answer, asks for supporting evidence, and explicitly says it will ignore any evidence to the contrary. – EricBoersma Sep 16 '10 at 14:15
  • @Gordon: So you *could* circumvent access restrictions in most languages (Disclaimer: I've not been arguing for it), either by introspection or via pointer arithmetic e.g. in C++. But can we agree that it's objectively simpler in uncompiled code anyways? – mario Sep 16 '10 at 14:31
  • @mario Sure, but all code is "Uncompiled code" at some stage. So what kind of argument is this? Nothing prevents me from changing a member from private to public in the sourcecode. It doesn't matter if the language has to be compiled to run later. – Gordon Sep 16 '10 at 14:49
  • @Gordon Point taken. However the "some stage" usually means "always" for PHP code. Whereas in Java it's quite usual to deal with class files, or even non-FLOSS third party libraries. With the source *always* and *completely* available in PHP, it's way simpler to override restrictions. So instead of syntactic sugar, it might as well be just an explanatory comment or _underscore convention. I agree that a private modifier raises the psychological barrier to break defensive interfaces. But so does a sound development methodology and an useful API design that doesn't tempt you. – mario Sep 16 '10 at 16:30
  • @mario the way you phrase it, it sounds like it's impossible to come up with a sound and useful API design when using Visibility modifiers. That's simply not true. You dont have to have everything public to follow the Open/closed principle. [I agree to favor protected over private](http://stackoverflow.com/questions/2028495/when-do-you-write-a-private-method-versus-protected/2029424#2029424) to discourage direct changes to my classes, but ultimately, if you want to modify them, do so. You are a developer. You hopefully know what you are doing. – Gordon Sep 16 '10 at 17:20
  • @Gordon I don't want this to sound too deragoratory. But it's my impression with a few PHP syntax constructs that they are too easily available. In particular the visibility modifiers take too little conscious effort to add. They are soldomly added AFTER an actual use case arises, but frequently even before the method body or signature is put down. It's my gut feeling that they're used on a so and so basis: let's make a few functions public and the other half not, regardless of interna woes. -Or I've seen too few good cases, but loads of shallow setters and getters around protected attributes. – mario Sep 16 '10 at 20:46
  • 1
    @mario I think it's safe to say that these are subjective reasons. The scenario you describe is perfectly possible in other languages with Visibility too. But just because people use a certain language feature "wrong" does not mean it should be avoided altogether. – Gordon Sep 17 '10 at 06:39
  • I don't get why people here treat `access modifiers` as any kind of security... IT IS NOT THEIR AIM! it is meant to organize your code, and hide stuff the user of your API does not need to know or care about hence can remove the load of him letting him deal with bigger problems. this question could just say 'I try convince my teammates that Classes are Evil!'" and state that there is nothing wrong with Functional/Procedural structures... (which might be valid for certain small scale projects) – Tomer W Aug 01 '15 at 17:58

4 Answers4

10

valid reasons NOT to use keywords public, private, protected in php?

Gordon
  • 312,688
  • 75
  • 539
  • 559
  • 1
    @stereofrog No. I cannot shake the feeling that you are trying to draw me into quibble :) I am pretty sure you know I am refering to controlling access to the encapsulated state, not just the act of grouping related state into objects as such. Also, you said I should not elaborate on OO principles. – Gordon Sep 16 '10 at 10:46
  • 1
    @stereofrog well, what do you want to hear then? Visibility modifiers control access to encapsulated state from the outside and inherited classes, allowing for greater control over your oo design. I take you know that. If you find this a superfluous or pointless thing to do, then be it so. – Gordon Sep 16 '10 at 11:31
  • 1
    Visibility has nothing to do with the programming paradigm. There are lots of FP languages that offer modules instead of objects and visibility for "members" of that modules. Further more, Erlang allows passing of arguments to a module, which resembles a lot the way args are passed to constructors in OO languages. – Ionuț G. Stan Sep 16 '10 at 11:33
  • And I pretty much agree that visibility has not that much to do with encapsulation and information hiding. – Ionuț G. Stan Sep 16 '10 at 11:36
  • @Ionut your arguments about Erlang and other FP languages might be true (no clue), but they are not for PHP. The only paradigm you use visibility modifiers with PHP is when using OOP. I changed the last point to make it more clear. – Gordon Sep 16 '10 at 11:39
8

The private modifier is - imho - vastly overused. The problem with it is that it makes it impossible to extend classes. But more importantly, it is a concept that leads one to write code which is class-oriented, rather then object-oriented.

I have no beef with protected for properties. In fact, I think it should be the only scope used. protected methods are usually a hassle though, as it makes testing harder.

troelskn
  • 115,121
  • 27
  • 131
  • 155
  • I agree on keeping properties `protected` instead of `private`. As for testing private and protected methods, have a look at http://sebastian-bergmann.de/archives/881-Testing-Your-Privates.html – Gordon Sep 16 '10 at 10:51
  • Agreed private should probably never be used (except possibly in hardware device drivers - but does anyone write these in PHP?). But did you really mean us to infer you think 'public' should never be used? – symcbean Sep 16 '10 at 11:47
  • @symcbean Yes, properties should be `protected` - methods `public`. If you need `public` properties, you are dealing with data, not objects. Use an associative array for that. – troelskn Sep 16 '10 at 15:49
  • 1
    A class should use private members and methods unless it has been explicitly designed with extension in mind. It is easier to reason about a class with it's internals marked as private because you do not have to hold the knowledge of each behaviour change introduced by extending classes. If you are extending a class, you should only be morphing it's identity, not it's function. – FantasticJamieBurns Dec 31 '13 at 12:55
  • 1
    Couldn't disagree more. *Inheritance* is what is vastly overused--not the private keyword. – riwalk Oct 24 '15 at 03:14
  • I agree with the two previous comments. Members should be private by default. But it depends on the class size. If your classes are far too big, then inheritance is the only way to reuse parts of a class's functionality. Which makes the problem even worse, because now you cannot refactor the internals of this class anymore. – donquixote May 16 '16 at 21:26
4

mario nailed it (copied from the comments)

Access modifiers make sense in Java/C++ and compiled code in general, where they are enforceable. In uncompiled scripting languages they can easily be ripped out. Hence they should be considered just decorators, and thus pragmatically could just be implemented as coding convention. (See underscoritis in Python, and pretty much any other scripting language. PHP is pretty alone with its purposeless access decorators.)

You won't have much success convincing your teammates about the advantage of useful APIs over encapsulation by restrictiveness. The use of syntax-enforced access decorators is often cargo cult driven.

Community
  • 1
  • 1
user187291
  • 53,363
  • 19
  • 95
  • 127
  • 2
    Indeed. Instead of helping the programmer at compile time, it only makes the program more likely to fail at run time. – Sjoerd Sep 16 '10 at 11:21
  • 1
    Access modifiers enforceable in C++? Since when? As far as I know, you can modify header files and you can always #define private public. Not sure how that changes the ABI for DLLs and static libraries, but it's certainly possible. In theory, you could always decompile Java class files, change private to public, and recompile. So they are not truly enforceable. – luiscubal Sep 16 '10 at 18:15
  • 1
    I don't get why people here treat `access modifiers` as any kind of security... IT IS NOT! it is meant to organize your code, and hide stuff the `user` of your API does not need to know or care about hence can remove the load of him letting him deal with bigger problems. this question could just say 'I try convince my teammates that Classes are Evil!'" and state that there is nothing wrong with Functional/Procedural structures... (which might be valid in certain small scale projects) – Tomer W Aug 01 '15 at 17:55
3

In a dynamic language like PHP, it is assumed that the programmer knows how the code works. That means the programmer knows which methods to call and which should not be called directly.

This is similar to untyped variables: in typed languages each variable is explicitly typed, but in PHP it is assumed that the programmer knows the type of each variable.

Sjoerd
  • 74,049
  • 16
  • 131
  • 175
  • 2
    Which is only valid if every programmer working on it is responsible for the whole codebase. In larger projects, this isn't always the case. – Wrikken Sep 16 '10 at 10:10
  • In a language like PHP is far more important than in a compiled one the use of such modifiers. The programmers can read all the source code and need directions on what methods are usefull for them or just inner mechanics – Eineki Sep 16 '10 at 10:14