Sergey Zhuk has written up a post to his site that wonders if the factory method violates the open/closed principle, a part of the SOLID set of principles for software development.

Consider an application that provides some statistics reports. Reports are present in different formats: JSON for API, HTML for viewing in a browser and pdf for printing on the paper. It has StatisticsController that receives a required format from the request and returns a formatted report. The logic for choosing a formatting strategy is hidden behind the factory.

He works through a code example of using the factory pattern to create this functionality, generating the fomatter from behind the factory. He then talks about adding a new formatter for CSVs and the update to the factory that would come with it. It's this last change he's wondering about as the Open/Closed principle states that objects should be open for extension but not modification. While the answer is technically "yes" he explains that the purpose of the factory is to abstract the logic away so you only have to deal with one type of thing rather than making it yourself every time.

According to Open-Closed Principle the “correct” solution would be to create a new factory with the same interface. That said, adherence to this principle should always be weighed against other design principles like KISS and YAGNI.

Brandon Savage talks about the "cardinal sin" of working with object inheritance in PHP applications - adding public methods to a class that extends/implements another.

I know I’ve committed this sin, and you probably have too. The sin of which I speak is a grave one, and it violates several well known and established principles of object oriented application development. What is this sin of which I speak? It is none other than the addition of new public methods to an object that extends or implements abstract class or application interface, in violation of both the Liskov Substitution Principle and the Dependency Inversion Principle.

He talks some about the Liskov Substitution Principle first, pointing out that adding those new methods makes the new object non-replaceable as the Liskov principle requires. As far as the Dependency Inversion Principle, the practice breaks it because you'd be depending on those new methods as concrete, not abstracted from the parent. He makes a few recommendations as far as ways to prevent violating these principles including using multiple interfaces or creating multiple abstract classes for different public APIs.

From DashExamples.com there's a quick post on how you can set up your application to notify you on content security policy violations and store them back on he server side for later review.

When somebody violates your CSP rules, there is a great feature that can setup for supporting browsers to send back the violations to your server to be saved, processed or whatever. This is a great feature because you can stop a possibly malicious piece of code from executing and learn which scripts may have vulnerabilities in your code.

The reports as delivered by the browser back to your server according to your site's policy setup. They're sent back as a JSON string that is easily parsed and stored. The post shows you a sample database table structure (storing things like request, headers, blocked location and IP address) and the PHP to handle the incoming post. For more about the CSP reports, see Mozilla's example on their Developer section.