Timeline for PHP ImageMagick Image Processing Class
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 26, 2014 at 10:41 | comment | added | Elias Van Ootegem |
Those are the solid principles in a nutshell: they really are common sense: S: A class does 1 thing, nothing more, nothing less. O: Derived classes should do that same 1 thing, but can build on the base class to better fit a particular situation. They don't add unrelated functionality. L: The base class defines the contract. If method X expects an instance of class A, then so does the child. The child obeys the parent. I: An interface enforces methods that relate to just 1 feature. D: whatever the class needs to work is handed to it: a class does not manage its dependencies
|
|
| Jun 26, 2014 at 10:35 | comment | added | Elias Van Ootegem |
Interface segregation: basically, this is the single responsability principle, applied to interfaces. Data objects can use interfaces like ArrayAccess or Traversable, but they should do so explicitly. Don't create a general DataObjectInterface that implements Traversable and a custom interface that deals with serialization. Each interface tells one thing, and has 1 function. Dependency inversion: If a class requires DB connectivity to work, its job is to work with a DB connection, not to connect to the DB. That connection should be provided to the class by the caller
|
|
| Jun 26, 2014 at 10:32 | comment | added | Elias Van Ootegem | @ZougenMoriver: Don't focus on the CS-jargon. The SOLID principles are plain and simple common-sense guidelines. A class is one block of code, it does one job: Single Responsability. A class, because it has 1 job, can be extended to do the same job in a specific context/case/project, but it should not be extendable in a way that it can be used for another type of task. Substitution: if a base class expects an argument of a certain type, that guarantees that all code in the base class can deal with that type. Child classes aren't allowed to modify this behaviour (contract/interface) | |
| Jun 26, 2014 at 10:02 | comment | added | Josh Harrison | Thanks again for the help. I look forward to hearing more about correct error handing, but a quick glance at the SOLID principles seems way over my experience level at this point in time! :) | |
| Jun 13, 2014 at 7:04 | comment | added | Elias Van Ootegem |
@ZougenMoriver: PS -> use type-hints. I've noticed your constructor now expects an instance of AirConfig. Great. But perhaps consider changing the signature to better reflect this: public function __construct( AirConfig $airConf). That way, the code will fail if the user passes anything else than an instance of AirConfig to the constructor, forcing the users' code to address the issue ASAP
|
|
| Jun 13, 2014 at 7:00 | comment | added | Elias Van Ootegem |
@ZougenMoriver: You're welcome. Keeping the error method, and airEnabled is perfectly fine. However, the SOLID principles (especially the Single Responsibility Principle) dictates that this class should throw an exception of a particular (self-made) class, which is handled by a custom handler, that would handle the exception by logging the error, and generating the error image. That way, this class' only job is to create images - ie it has only 1 responsibility. I'll have a look at the github repo and expand on this a little in the days to come, though
|
|
| Jun 12, 2014 at 15:55 | vote | accept | Josh Harrison | ||
| Jun 12, 2014 at 15:54 | comment | added | Josh Harrison |
Thank you so much for your constructive and helpful comments. I've actioned most of your suggestions. However I'll keep the airEnabled check near the beginning, as some front end devs here may inherit this code and don't have ImageMagick, and need to disable the script whilst still seeing the original images. Also, the error method I have kept, as it writes to an error log and displays an error image too. I think that's better than a fatal exception, which wouldn't show up in pages when the images are requested through an img tag rather than directly.
|
|
| Jun 12, 2014 at 12:58 | history | answered | Elias Van Ootegem | CC BY-SA 3.0 |