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 7 years ago.
Improve this question
Basically I'm building a website that need a html like template called from the folder using their file name.
Should I use a enum/constant class or should I just call them straight to their filename?
Example:
abstract class ViewTemplate
{
const ORDER_HISTORY = 'order_history_template.html';
const PURCHASE_HISTORY = 'purchase_history_template.html';
//etc...
}
Is this kind of class necessary and do they hog a lot of resources if I call the class when I have a lot of template?
Since the filename is a unique identifier - unless you expect the file names to change in the future (which isn't likely, and even if it happens refactoring is simple) there is no point to it.
You already have a unique identifier for a file you're loading. The only benefit of passing an enumeration with properties here is type-safety but you're only calling it once anyway so a typo could happen in one place anyway.
So overall it's redundant.
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 2 years ago.
Improve this question
I read somewhere that defining constants with PHP's define function like so:
define('BASE_PATH','/var/www/html/example/');
is better and more secure than storing the same variable data inside a globals variable like so:
$_GLOBALS['BASE_PATH'] = '/var/www/html/example/';
Could somebody please explain the difference, which is better in which scenarios, and why?
I've just read here:
PHP Manual - The 'define' function
That the 'define' function can cause unwanted oddities.
a) What are the security implications of both?
b) How does PHP manage and store each of the variable's data in physical memory?
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 6 years ago.
Improve this question
While Looking into a PHP Plugin i saw a line ,
$this->banks[0] = new Population();
It seems like they are declaring a object in a array variable. What is the use of it?
For what you described, it seems they're using a common pattern called Singleton that is useful in the way that you have all objects and their states accessible from only one common object.
It all depends on how the PHP plugin works.
The advantage of using a class instead of the array allows you to create function for a better data manipulation (e.g. a population class could have a function getPersonByName or getPersonsByAge which makes it easier instead of making a new loop each time.
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 8 years ago.
Improve this question
I have a huge php class with very long code in it. This make the file is big with lots of coding and hard to maintain. Is there anyway that I can split the class into a few files for easier maintaining?
Thank you.
It depends on whether or not you can split the class in to subclasses.
What I mean is that you should ask yourself "does this method apply to this class or would it belong to a subclass?"
For example,
Class Animal
- dog_bark()
dog_bark() could be moved to a class named Dog, and the method renamed to bark()
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.