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
Right now I am having a big amount of constant strings and enums in my project. Since the beginning of it I was using the following approach (pseudo php example code):
class Constants implements iStatuses, iEmailTypes {
}
interface iStatuses {
const STATUS_NEW = 1;
cosnt STATUS_UPDATED =2;
...
}
interface iEmailTypes {
const EMAIL_TYPE_NEW = 1;
const EMAIL_TYPE_UPDATED =2;
...
}
This approach allowed me to get my constants in a following way anywhere in a code, since I included 'Constants' class in the index.php.
$this->sendEmailByType(CONSTANTS::EMAIL_TYPE_NEW);
However, I can totally see downsides of the approach:
Constants class is overloaded with a lots of enums and constants and it is very hard to get right constant. Naming convention helps to solve it, but I don't like this, since it requires additional thinking to identify what constant I need
Constants class is too big and messy
I need to keep tracking of all the interfaces, being implemented by Cosntants class.
Since my project is becoming much more bigger now, and we need to merge it with another project's code, it is required to have class Constants approach changed. However, I got too many dependencies based on that class. How should I re-struct that approach, in order not to break old code that used values of constants class.
Please, share your thoughts and suggestions, how to improve my 'constants' approach, or confirm that it is decently good and I should support it.
Thank you in advance.
Why not just having constant classes for each context. i.e.
class Statuses
{
const STATUS_NEW = 1;
const STATUS_UPDATED =2;
...
}
class EmailTypes
{
const EMAIL_TYPE_NEW = 1;
const EMAIL_TYPE_UPDATED =2;
...
}
Later on when you or other programmers want to contribute to your application they easily can check related constants on the subject they expecting, instead looking into a large pool of constant.
.e.g once looking for a flag around email types I would expect to find it within EmailType:: and if its not there, feel confident to add it in the same 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 8 years ago.
Improve this question
It is a bad way of programming, when i get access to my private/protected class members directly in the class via my getter/setter methods?
Alternative #1
<?php
class A {
private $myVariable;
public function getMyVariable() {
return $this->myVariable;
}
public function doSomething() {
$variable = $this->getMyVariable();
}
}
?>
Alternative #2
<?php
class A {
private $myVariable;
public function doSomething() {
$variable = $this->myVariable;
}
}
?>
Which way do you prefer? I think the first solution is more readable in constrast to the second one. Please let me hear your opinions.
Thanks in advance.
Since you are determined this is not a duplicate, I will copy the points from this response relevant to this case:
Encapsulation of behavior associated with getting or setting the property - this allows additional functionality (like validation) to be added more easily later.
Controlling the lifetime and memory management (disposal) semantics of the property - particularly important in non-managed memory environments (like C++ or Objective-C).
Providing a debugging interception point for when a property changes at runtime - debugging when and where a property changed to a particular value can be quite difficult without this in some languages.
Allowing inheritors to change the semantics of how the property behaves and is exposed by overriding the getter/setter methods.
Maybe you should think in another way: Why do we need getter/setter? They abstract direct access to a field. Even if the Getter does nothing other than setting a value, it can protect you later on. Changing a field to a Getter later is a breaking change, especially in PHP IDEs (badumm). So I think whenever you want to protect a field to prevent vulnerable/buggy code, use getter/setter.
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 heard so many times that use define() to create global constant is a bad solution. But I've never heard why it is so.
And what is the way it should be done instead?
Probably you've read something about not polluting the global namespace. At least that's the biggest reason why should you try to avoid global constants - and variables and functions for that matter. However there are valid use cases where a global definition makes sense.
In most cases though the constant belongs to something. That something being a class it's worth defining the constant within the class.
If you define a constant that has a long prefix (eg. VALIDATOR_EMAIL_PATTERN) that is a sign of a possible class related constant definition (Validator\Email::PATTERN)
Global definitions have more chance to collide thus making parts of your code harder to re use, since two different library could try to define constants with the same name for their our purpose.
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 9 years ago.
Improve this question
When using Object-Oriented programming in PHP is there a simple rule of thumb on what should be made into an object or should you try to make the entire program using object-oriented code. I know this is quite opinion based but I can't seem to find any resources that could answer it for me.
Thanks.
I would suggest to read general oop concepts to get grip on that: http://oopsconcepts.blogspot.de/
What an object should be is largely language independent and whether your function should be an object or not fully depends on the context in what it is used.
Trivial code is usually not improved by making it object oriented.
In a scenario where your function is injected into something and must be replaceable it might make sense to make an object that implements an interface out of it.
Objects (or rather classes) should relate to a specific noun. For example, you might have a class called User, or Product. Functions generally are verbs. So you might have something like Product->Update().
Simple having a collection of unrelated functions in a generic Class does not constitute good OOP design. If the function is simply doing as you've advised, then it shouldn't have its own class.
A fairly standard pattern to follow with the kind of trivial, but global function your are discussing is to add it to a Utilty class.
In principle that is simply a class with public static member methods, that would normally be grouped by relation - exactly as you would a file of functions.
class MyFileUtility
{
public static function FileToArray($filePath) { // do stuff }
public static function ArrayToFile($array, $filePath { //do stuff }
...
}
$array = MyFileUtility::FileToArray('somefile');
Now you will use the methods of the Utility exactly as you would a function, but they are in a class, if it makes you feel better.
There are a couple of benefits:
Auto-loading will work, so long as you have configured it.
IMO You will generally be in a better / safer namespace situation.
If you like typing "::" You are well in :)
_____________ Edit _________________
Here is an explanation of a static Utility class added for clarity.
http://en.wikipedia.org/wiki/Utility_pattern
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
Should I define constant and use it?
OR
Can I use Magic numbers?
I am working in project where I am using Magic number in many places do I want to change it? because I am using more that 1000 Magic number? Is this rite way or I should use constant?
Is there any restriction in the number of constants?
Ex:
Magic numbers:
$common->getDBMessage(25);
Constants:
$common->getDBMessage(ERROR_MESSAGE_INVALID_PHONE);
You can have as many constants as you like. PHP already has a very large number of constants built in.
You might want to consider making them class constants (const within a class) rather than global constants (using define). Having them organised will help you structure your code better and make things easier to work with.
In addition, if some of the constants are related, you might consider using bit-masks for groups of values, so you can specify them together. This will avoid the need to create an additional constant for the combined value.
But all this is just advice for making your life easier; it's not related to whether you can do it or not.
There are no restrictions for constants in PHP - at least, no native restrictions.
It's a matter of good practice - if you'll have 1000 constants with bad naming, this will be difficult to understand by those who will read your code. And - I do not understand why use constants for numbers unless they have model-defined (or application-defined) meaning.
I.e. if you have some service 'FOO' with id=1, then SERVICE_FOO_ID constant with value 1 is normal solution, but if you want to create constant with value 1 for case for($i=1; ...) - that's sounds weird.
The common answer will be, of cause: it's opinion-bases. It's up to you.
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 9 years ago.
Improve this question
I.e. instead of:
const MY_CONST = 0;
he writes:
public static function MY_CONST() { return 0 };
My former colleagues, front-end developers, doing so in JavaScript, because there are no constants, but to do so in PHP? In my opinion, if the language have a constants, you should use them.
I want to send him a link to this question, as my arguments.
Writing method to return always same value is senseless. Of course it is better pratice to use constans. Even when you look at perfomace it's faster when you declare something that you know won't change as constant.
I agree with hakre don't argue with idiots they will bring you to their level and beat with experience.
I read somewhere that in PHP constans are not so fast. You should read this article.
http://planetozh.com/blog/2006/06/php-variables-vs-constants/
In my opinion, if the language have a constants, you should use them.
Sure, that's why they are in. Otherwise it is not a constant. Did he said he needs a constant? If so, tell him there is a PHP manual explaining it in case the language is new to him.
The URLs are http://php.net/const and http://php.net/constants .
Apart from these fundamental and bare things, do not argue with idiots. They live - by the original meaning of the word - in their own world. So you can not get through to them.