Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Access to private methods #7

Open
andreas-c opened this issue Jun 5, 2012 · 1 comment
Open

Access to private methods #7

andreas-c opened this issue Jun 5, 2012 · 1 comment

Comments

@andreas-c
Copy link

Hi Bastian,

first of all, thanks for your interesing presentation at the PHP UG Cologne last week.
Regarding the user group's discussion that night I'd like to share my point of view, too.

Short version: yes, if it's possible there should certainly be a way to make private methods accessible.

There are at least two important scenarios where this makes sense:

  1. CCN reduction
    As a use case grows, i.e. more and more scenarios are added, the number of independent execution paths usually grows, too. This is also known as the CCN (cyclomatic complexity number, http://en.wikipedia.org/wiki/Cyclomatic_Complexity_Number): Each if, switch, etc in your code increases complexity.
    Theoretically, it's OK to have a CCN of 100 - as long as you are willing to write (and maintain) 100 Test Cases for that one single function :-).

However, in the real world noone would want that, so this kind of thing is considered code smell anti-pattern "long method". A common solution for that problem is refactoring, namely refactoring pattern "extract method".
As a result the once big function will be split up into several small ones, all of which will preferably have a handy CCN of < 10. Then testing will be possible and fun again.
And as there is usually no reason to make these small functions more visible than private a testing helper like proxy-object would be really helpful if it supported private methods, too.

  1. Comments
    Another reason to extract small methods can once again be found in Martin Fowler's classic book on refactoring:
    "When you feel the need to write a comment, first try to refactor the code so that any comment becomes superflouus."

So we often extract small - and mostly private methods - with verbose names to achieve this.

Thanks again for your cool tool!
Looking forward to seeing in Cologne soon.

Andreas Czakaj
IT Director
Pixelpark AG

@lapistano
Copy link
Owner

Hey Andreas,
thx for the extensive feedback and for your interest in the project.

As far as the method extraction I agree with you to solve the 'long method' code smell by extracting other methods but I do not agree that these usually are set to private. Many times I am able to identify more general methods which could be extracted to a whatever helper class and then they will be public again.

Nevertheless proxy-object one purpose is to support you while getting rid of legacy code and ensuring the correct behavior of your application after the refactoring. So as I already said at the UG meeting I will enhance the library by the possibility to expose private methods as well.

I'll keep you posted.
Bastian

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants