Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have been trying to wrap my head around this for days now, and yet no answer.
I am currently building a website and I have some set of functions I have built. I later began to refactor them and put related function in a class, but at some point I got confused on whether some related function should also be grouped. From then I began to question myself that although PHP string functions are related why are they not grouped together as a class.
So what are other good reasons to classify a function?
And when are we not to classify some functions?
Note: I know a php String Class exist.
So what are other good reasons to classify a function? making a class of methods instead of a group of functions is not as much about grouping them together because they are related, as it is about scope, encapsulation, and instantiation.
when a method is in a class the developer has control over visibility and accessibility. This is also a consideration for the properties of the object.
unlike a group of functions, you can instantiate a class and define values for all of its properties and run its methods as allowed, and then do it again and again while each prior instantiation persists if you like. An example would be a game with a gun that shoots projectiles, each projectile may be an instantiation of the projectile class with its properties being position, velocity etc... each bullet has its own set of properties. There are an unlimited number of examples, many in common use.
I do not group functions into a class because of similarity of the functions, but due to functionality required of the class.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm using Laravel 5 and I need to add some immutable values (constants) to be able to make use of them in controllers mostly (maybe in views too). Question is: What's the best approach?
I've been reading and 90% of approaches suggest to use a constants.php and Config.get(), but I don't like this because (I think) a constant is not a config value. I mean, it's not supposed to be changed. In other frameworks, I like to use models or other lib class to define values related to the entity I'm working on, Eg.: I need a constant for cache time in users, then User::CACHE_1_DAY = '86400' (silly example btw).
I would recommend adding a new class containing Helper methods, and bind that class to the application in your AppServiceProvider.
Finally inside that class, place getter methods for the constants.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Read a lot of posts about storing sessions inside database but no one seems to provide proper information.Then i came across this post and i found it to be very helpful.
http://culttt.com/2013/02/04/how-to-save-php-sessions-to-a-database/
Now what i don't understand with these posts is that they are taking a class named Database which contain certain functions in order to make session class work i.e. to store sessions inside database.
Question : My question to you all is if it is possible please provide me with that database class even it means creating one own database class file.Just to make sure all the functions that the session class is looking inside database class are found and working.
Codepad:http://codepad.org/mtvT3XXB
That article you cite has horrible issues with wording (example: "...we instantiate a copy of the database class...", which is just plain nonsense). But the basic thing behind such "database" class simply is to keep things generic for the reader, which makes sense.
To interact with a database you need some routines for things like connection handling, query execution and preparation and the like. These routines are typically implemented as methods of a class. Such a class is what the author refers to. He does not name a specific one since they are more or less exchangeable.
You don't actually have to implement your own class, you can use one of those already provided. A short overview is given in the php documentation (which you should read!):
http://php.net/manual/en/set.mysqlinfo.php
I suggest you pick the mysqli connector and go through a few tutorials to learn what it does and how to use it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am building a MVC application in PHP, and am creating a Form class to generate a form that you can add elements to. Should I use static methods to generate the form, such as Form::generate(...) or in my view class where I declare variables to be used in a view file, should I instantiate the class and use it like $form->generate(...)? I have heard using static methods are bad because of testing, but I don't know. Thanks!
Beside the problem that PHPUnit doesn't support static mocks, the more obvious problem is that of loose coupling and dependency injection. It's completely fine if you have state-independent methods, but to strictly define those methods with the static keyword creates a hard dependency on the classname behind the double colon operator. (In fact, it's that hard dependency that makes the PHPUnit problem so tricky.)
I would agree that static methods have rather fallen out of favour except in certain applications such as:
Facade pattern, where the static methods hide a more complex API http://en.wikipedia.org/wiki/Facade_pattern
Factory pattern, where the static methods are responsible for creating and configuring object instances http://en.wikipedia.org/wiki/Factory_method_pattern
Utility type functions where the class is used almost like a namespace to group together related functions, but the functions themselves are basically procedural (examples could include string, date or price formatting functions)
I would start by creating one Form class that represents your form, and if necessary adding a factory helper which generates an instance of your form.
You might like to take a look at the Symfony form builder, their approach is elegant:
http://symfony.com/doc/current/book/forms.html#building-the-form
That depends, generally static methods wont maintain state, or in other words, you can't use dynamic properties within that class, or instantiate the class ( obviously ).
If you are using them as an OOP way of doing functions it should be fine, in fact I think Laravel uses a lot of them.
http://laravel.com/docs/quick
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
Just a quick question:
When looking to Controller.php:
What's the underlying coding convention for property-names? I always thought, that properties, which reference a object starts with a uppercase letter, whereas basic properties, referencing booleans/strings/ints, starts with a lowercase letter.
But, in Controller.php, there are:
public $request; // referencing an instance of a CakeRequest object
public $View; // referencing an instance of a View
So, where's the difference?
The general rule regarding variable and property casing is:
Normal variables should start with a lowercase letter, and should be written in camelBack in case of multiple words. Variables containing objects should start with a capital letter
As such your understanding is correct.
There are however some inconsistencies for/from:
Backwards-compatibility
Multiple developers, some more consistent than others
Mistakes =)
The reason they differ is changing opinion over time I guess. When CakePHP had relatively few objects internally it made sense to call them out with CamelCase names. However, over time we've added more objects, and in some cases like request wanted to avoid potential issues with userland code that may make Request. On top of these is the need to not break compatibility needlessly.
My current thinking is that framework internal objects, or non-userland objects will be camelBacked, while userland objects like Tables, Components, Tasks, Helpers etc are CamelCased.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm building an Authentification library that's going to have around 45+ methods for dealing with user related stuff. However I've been wondering if it's actually recommendable to keep everything on a single file.
Is there a benefit on splitting my class into several subclasses and load them when needed?
I can always for example split the class into "mandatory" elements and the elements that only registered users need...
For example:
Mandatory Methods:
$user->is_logged()
$user->login()
$user->register()
Methods for Register...
Methods for logged-in user.
It just depends on how you want to be including the class file(s) in your pages. If you want one simply include() statement for every page, then keep it all in one file. Unless your library is HUGE, the overhead from the other classes shouldn't be too much.
If you do it the other way, you'll simply be including different files based on the status of the session of the client.
Personally, I'd split them up as it's easier to edit them that way, but it's totally up to you.
I'd go with the class/sub-class option.
You could then use a factory to return the correct type of user object based on the current URL or by simply specifying the desired type of user object if your particular setup doesn't lend itself to this.