Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Stitcher.io:
Service locator: an anti-pattern
Aug 20, 2018 @ 12:47:01

On his site Brendt has shared some of his thoughts about why he sees the service locator design pattern as an anti-pattern and harmful to your overall application.

As a Laravel developer, I'm confronted daily with the service locator pattern. Every facade call and several helper functions are built upon it.

[...] During a discussion with my colleagues, I found it difficult to put into words what exactly is wrong with grabbing things out of the container - a service locator - so I decided to write my thoughts down, with an example. [...] I want to highlight three problems with this approach, directly caused by the use of a service locator.

He goes through a list of where he sees the use of the service locator functionality causing problems including:

  • getting runtime instead of compile-time errors
  • obfuscation of actual functionality
  • increased cognitive load

He ends the post with a quick suggestion on how to solve the issue: use actual dependency injection instead of "magic" locators.

tagged: servicelocator designpattern antipattern opinion error obfuscation cognitive

Link: https://www.stitcher.io/blog/service-locator-anti-pattern

Justin Silverton's Blog:
protecting your PHP code
Mar 27, 2006 @ 07:32:16

Some PHP developers out there are very protective of their code for one reason or another. Sometimes it's a matter of their hard work, slaving over a keyboard for hours and hours to get it exactly right. Then there's the other reason - money. Of course, no matter what your situation, a new post from Justin Silverton might help you narrow down the encoder software field a bit.

A client of mine approached me today and was interested in releasing a PHP based product, but didn't want his source code to be viewed, in plaintext, by the people purchasing it (mainly because competitors can could easily just purchase a copy and integrate his source code into their product). So, I researched the different options available to protect source code.

He includes his suggestions on "what doesn't work" (encoders that can be broken by sites like phprecovery.com) and "what works" - code obfuscation. His personal favorite in this department is POBS, a simple application that alters your code by changing function names/variable names and obscuring the code by modifying the structure of the code (adding/removing newlines, stripping spaces, etc).

tagged: protecting obfuscation encoder protecting obfuscation encoder

Link:

Justin Silverton's Blog:
protecting your PHP code
Mar 27, 2006 @ 07:32:16

Some PHP developers out there are very protective of their code for one reason or another. Sometimes it's a matter of their hard work, slaving over a keyboard for hours and hours to get it exactly right. Then there's the other reason - money. Of course, no matter what your situation, a new post from Justin Silverton might help you narrow down the encoder software field a bit.

A client of mine approached me today and was interested in releasing a PHP based product, but didn't want his source code to be viewed, in plaintext, by the people purchasing it (mainly because competitors can could easily just purchase a copy and integrate his source code into their product). So, I researched the different options available to protect source code.

He includes his suggestions on "what doesn't work" (encoders that can be broken by sites like phprecovery.com) and "what works" - code obfuscation. His personal favorite in this department is POBS, a simple application that alters your code by changing function names/variable names and obscuring the code by modifying the structure of the code (adding/removing newlines, stripping spaces, etc).

tagged: protecting obfuscation encoder protecting obfuscation encoder

Link: