I was trying to use array_walk_recursive for something, and wanted to use one of the class' methods as the call back, so trying:
array_walk_recursive($TAINTED, "$this->encode()");
and variations thereof all failed. I eventually settled for:
array_walk_recursive($TAINTED, 'className::encode');
which works, but I've read on here that calling class methods in a static fashion like this is often considered poor practice. Or is this one of those situations where it's necessary?
So, is this the right way to go about it, or is there a way to put in the callback function without having to fall back on using it as a static class method?
array_walk_recursive($TAINTED, array($this, 'encode'));
I know this thread is older but by reading your words "calling class methods in a static fashion like this is often considered poor practice" I have to say that static functions are a good practice when used for the right task. Frameworks like Laravel and Symphony shows the true potential of static methods.
Anyways when you aren't afraid of using static methods you can call your method using self instead of specifying the class name that might change during development process.
array_walk_recursive($TAINTED, 'self::encode');
Related
I'm writing a bunch of generic-but-related functions to be used by different objects. I want to group the functions, but am not sure if I should put them in a class or simply a flat library file.
Treating them like a class doesn't seem right, as there is no one kind of object that will use them and such a class containing all these functions may not necessarily have any properties.
Treating them as a flat library file seems too simple, for lack of a better word.
What is the best practice for this?
Check out namespaces:
http://www.php.net/manual/en/language.namespaces.rationale.php
Wrapping them in a useless class is a workaround implementation of the concept of a namespace. This concept allows you to avoid collisions with other functions in large projects or plugin/module type deployments.
EDIT
Stuck with PHP 5.2?
There's nothing wrong with using a separate file(s) to organize utility functions. Just be sure to document them with comments so you don't end up with bunchafunctions.php, a 20,000 file of procedural code of dubious purpose.
There's also nothing wrong with prefixes. Using prefixes is another way to organize like-purpose functions, but be sure to avoid these "pseudo-namespaces" already reserved by the language. Specifically, "__" is reserved as a prefix by PHP [reference]. To be extra careful, you can also wrap your function declarations in function_exists checks, if you're concerned about conflicting functions from other libraries:
if (!function_exists('myFunction')) {
function myFunction() {
//code
}
}
You can also re-consider your object structure, maybe these utility functions would be more appropriate as methods in a base class that all the other objects can extend. Take a look at inheritance: http://www.php.net/manual/en/language.oop5.inheritance.php. The base class pattern is a common and very useful one:
abstract class baseObject {
protected function doSomething () {
print 'foo bar';
}
public function getSomething () {
return 'bar foo';
}
}
class foo extends baseObject {
public function bar () {
$this->doSomething();
}
}
$myObject = new foo();
$myObject->bar();
echo $myObject->getSomething();
You can experiment with the above code here: http://codepad.org/neRtgkcQ
I would usually stick them in a class anyway and mark the methods static. You might call it a static class, even though PHP actually has no such thing (you can't put the static keyword in front of a class). It's still better than having the functions globally because you avoid possible naming conflicts. The class becomes a sort of namespace, but PHP also has its own namespace which may be better suited to your purpose.
You might even find later that there are indeed properties you can add, even if they too are static, such as lazy-loaded helper objects, cached information, etc.
I'd use classes with static methods in such case:
class Tools {
static public function myMethod() {
return 1*1;
}
}
echo Tools::myMethod();
EDIT
As already mentioned by Chris and yes123: if the hoster already runs PHP 5.3+, you should consider using namespace. I'd recommend a read of Matthew Weier O'Phinney's article Why PHP Namespaces Matter, if you're not sure if it's worth switching to namespaces.
EDIT
Even though the ones generalizing usage of static methods as "bad practice" or "nonsense" did not explain why they consider it to be as such - which imo would've been more constructive - they still made me rethinking and rereading.
The typical arguments will be, that static methods can create dependencies and because of that can make unit testing and class renaming impossible.
If unit testing isn't used at all (maybe programming for home/personal use, or low-budget projects, where no one is willing to pay the extra costs of unit testing implementations) this argument becomes obsolete, of course.
Even if unit testing is used, creation of static methods dependencies can be avoided by using $var::myMethod(). So you still could use mocks and rename the class...
Nevertheless I came to the conclusion that my answer is way too generalized.
I think I better should've wrote: It depends.
As this most likely would result in an open ended debate of pros and cons of all the different solutions technically possible, and of dozens of possible scenarios and environments, I'm not willing going into this.
I upvoted Chris' answer now. It already covers most technical possibilities and should serve you well.
Treating them as a class does give you the benefit of a namespace, though you could achieve the same thing by prefixing them like PHP does with the array_* functions. Since you don't have any properties, that basically implies that all your methods are static (as Class::method()). This isn't an uncommon practice in Java.
By using a class, you also have the ability, if necessary, to inherit from a parent class or interface. An example of this might be class constants defined for error codes your functions might return.
EDIT: If PHP 5.3+ is available, the Namespace feature is ideal. However, PHP versions still lag in a lot of hosts and servers, especially those running enterprise-stable Linux distributions.
I've seen it a few different ways, all have their warts but all worked for the particular project in which they were utilized.
one file with all of the functions
one file with each function as its own class
one massive utilities class with all of the methods
one utils.php file that includes files in utils folder with each
function in its own file
Yes, it's OK formally... As any class is methods + properties. But when you pack in class just some functions -- it`s become not ideal OOP. If you have bunch of functions, that groupped, but not used some class variables -- it' seems, that you have somewhere a design problem.
My current feeling here is "Huston, we have a problem".
If you use exactly functions, there one reason to wrap them in static class - autoloader.
Of course, it creates high coupling, and it's may to be bad for testing (not always), but... Simple functions are not better than static class in this case :) Same high coupling, etc.
In ideal OOP architecture, all functions will be methods of some objects. It's just utopia, but we should to build architecture as close as we can to ideal.
Writing a bunch of "generic-but-related" functions is usually bad idea. Most likely you don't see problem clear enough to create proper objects.
It is bad idea not because it is "not ideal OOP". It is not OOP at all.
"The base class pattern" brought by Chris is another bad idea - google for: "favor composition over inheritance".
"beeing extra careful" with function_exists('myFunction') is not but idea. It is a nightmare.
This kind of code is currently avoided even in modern javascript...
A word before my question to say I am pretty new to OOP in PHP, and I'm very grateful to the site, and you all for reading - and sometimes answering beautifully (as you can see here or here, or even here) and helping big time my late (sort of) improvement dealing with classes.
All my previous questions lead me today to this one:
In a class extending PDOStatement, how can I trigger a default action each time one of the parent public methods is called?
I can do this:
class genc_query extends PDOStatement{
public function rowCount(){
$this->myDefaultAction();
return parent::rowCount();
}
}
But as I need to change in the same way almost all of the native methods, I wonder if there's no way to trigger a function like __call() as if these methods were private (as it's not possible to make them private).
as it's not possible to make them private
Indeed, this seems to be the case.
ReflectionMethod can let you change the accessibility of a method, but it seems that it either doesn't work on internal methods (i.e. not user-defined) or it won't set public methods to protected/private. It seems designed to make protected/private methods public instead.
It looks like your copy-and-paste boilerplate inside each method is going to be necessary. Besides __sleep and __wakeup, there are only about three dozen methods, so it should only take you a few minutes.
For the sake of clear code, extend every method (means: overwrite and call parent::method() there), that you wants to have additional behaviour. Else there will be some day, where you or someone else may get really confused on what happens there.
I've got a few functions that deal with cookies. Would it be a horrible idea to group them by moving them to a class of their own and use them as static methods?
Functions:
function cookie_get(){}
function cookie_set(){}
function cookie_delete(){}
Static methods:
class cookie
{
static function get(){}
static function set(){}
static function delete(){}
}
It would be a great idea, provided you are fully aware of the caveats involved. This is known as the Utility Pattern:
Good candidates for utility classes
are convenience methods that can be
grouped together functionally.
It's actually good practice to organize functions like that. A modern alternative would be to use a namespace.
Yes, that would be a horrible idea because static methods are hard to test and mock. Why not just create a real Cookie class that you can configure at runtime with those methods as regular methods.
If you just want to group those functions into a package, you can just as well use Namespaces.
Edit: Since you brought it up in the comments: yes, for any testing purposes regular functions are as untestable as statics. So your initial situation is as "horrible" as changing it to use a static class. Even the pseudo namespace is not giving you any advantage, because you already applied that to your regular functions as well. cookie_get is as good or bad as Cookie::get.
That would be a great way of organising your code, but why use static functions, just make a class for the required functionality.
Or as said above use namespaces, but I'm not particularly familiar with the pros/cons of them.
$cookie->get() is nicer to work with than cookie_get() in my opinion
I just want to tell you that I am newbie to OOP and it is quite hard to me, but here is my code:
class functions
{
function safe_query($string)
{
$string = mysql_escape_string(htmlspecialchars($string));
return $string;
}
}
class info
{
public $text;
function infos($value)
{
echo functions::safe_query($value);
}
}
Is there any way to make this sentence : echo functions::safe_query($value); prettier? I can use extends, than I could write echo $this->safe_query($value);, but is it a best way? Thank you.
edit: and maybe I even can to not use class functions and just make separate file of functions and include that?
Yes, just define your function outside of a class definition.
function safe_query($string){
return mysql_escape_string(htmlspecialchars($string));
}
Then call it like this
safe_query($string);
Using a functional class is perfectly fine, but it may not the best way to design your application.
For instance, you might have a generic 'string' or 'data' class with static methods like this (implementation missing, obviously):
class strfunc{
public static function truncate($string, $chars);
public static function find_prefix($array);
public static function strip_prefix($string);
public static function to_slug($string); #strtolower + preg_replace
etc.
}
The point of a class like this is to provide you with a collection of generic, algorithmic solutions that you will reuse in different parts of your application. Declaring methods like these as static obviates their functional nature, and means they aren't attached to any particular set of data.
On the other hand, some behaviors, like escaping data for a query, are more specific to a particular set of data. It would probably be more appropriate to write something like this, in that case:
class db_wrapper{
public function __construct($params); #connect to db
public function escape($string);
public function query($sql);
public function get_results();
}
In this case, you can see that all of the methods are related to a database object. You might later use this object as part of another object that needs to access the database.
The essence of OOP is to keep both the data and its relevant behavior (methods) in one place, called an object. Having behavior and data in the same place makes it easier to control data by making sure that the behavior attached to the data is the only behavior allowed to change it (this is called encapsulation).
Further, having the data and behavior in one place means that you can easily pass that object (data and behavior) around to different parts of your application, increasing code reuse. This takes the form of composition and inheritance.
If you're interested in a book, The Object-Oriented Thought Process makes for a decent read. Or you can check out the free Building Skills in Object-Oriented Design from SO's S.Lott. (Tip: PHP syntax is more similar to Java than Python.)
Functions outside a class litter the global namespace, and it's an open invitation to slide back to procedural programming. Since you're moving to the OOP mindset, functions::safe_query($value); is definitely prettier (and cleaner) than a function declared outside a class. refrain from using define() too. but having a functions class that's a mix of unrelated methods isn't the best approach either.
Is there any way to make this sentence
: echo functions::safe_query($value);
prettier?
Not really. IMO having a functions class serves no purpose, simply make it a global function (if it's not part of a more logical class, such as Database) so you can do safe_query($value); instead.
and maybe I even can to not use class
functions and just make separate file
of functions and include that?
Create files for logical blocks of code, not for what type of code it is. Don't create a file for "functions", create a file for "database related code".
Starting with OOP can be a real challenge. One of the things I did was looking at how things were done in the Zend Framework. Not only read the manual (http://www.framework.zend.com/manual/en/zend.filter.input.html, but also look at the source code. It will take some effort but it pays of.
Looking at the context of your question and the code example you posted, I would advice you to look at some basic patterns, including a simple form of MVC, and the principles they are based upon.
(This is not an interface: I simply omitted the method bodies)
class _ {
protected $_data = array();
function __construct($data);
function set($name, $value);
function get($name);
function __set($name, $value);
function __get($name); //aliases for their respective non-magic methods.
# and some other generic methods
}
Essentially it's a class that provides a magical object-oriented reusable access layer to some data. I've considered DataLayer, DataObject and some others; I'd like to hear some suggestions from someone who's more terminologically savvy.
How about Dave ;)
Seriously though, what about DataAccess
Without knowing how the class is used and what data it's meant to wrap, it's hard to name it. "Wraps some data in magic OOP" is so generic that a meaningful class name is difficult.
If it's for sitting between the controller and the database, you could call it ActiveRecord.
If it really is just for providing some OOP syntactic sugar to an array(), you could simply use the built-in StdClass.
Failing that, given that the only purpose of the class seems to be to wrap an array, I'd be tempted to call it ArrayWrapper.
There's a class like that in Magento. Well, it's got a lot more stuff in it, but the philosophy is the same: add some magic method goodness to the rest of your classes via inheritance. They named it Varien_Object, Varien being the name of the company.
I've also got something like this in a custom framework I've helped build. It's just called Base.
I guess what I'm trying to say is... no matter what you call it, it wont help people understand what it does until they go through the code. Don't worry about it too much, by the time you're done it'll be buried so deep in your app that the only people that find it will be the kind that can grok what it does fairly quickly anyway
You could call it AccessLayer.
It really resembles KeyPairValue and if you with to make it more specialized in defining how Get would find its entries say using a Hash() function, then it's a Hashtable.
class KeyPairValue
class Hashtable
Now the question is why? Most SDKs would offer such data structures?
Try to use existing structures and not re-invent them.