I know there are a couple of similar questions here in StackOverflow like this question.
Why is overriding method parameters a violation of strict standards in PHP? For instance:
class Foo
{
public function bar(Array $bar){}
}
class Baz extends Foo
{
public function bar($bar) {}
}
Strict standards: Declaration of Baz::bar() should be compatible with that of Foo::bar()
In other OOP programming languages you can. Why is it bad in PHP?
Background: You asked for a "simple explanation" which suggests:
Short No-Jargon Answer:
Long No-Jargon Answer:
Procedural vs OOP is just one aspect of a fundamental issue of computer programming: how to make your code easy to understand and a piece of cake to professionally maintain. You can actually write "Procedural" code that follows some of the principles of OOP, so the two are not necessarily opposites.
Your understanding will really grow once you learn other object-oriented programming languages, among which, PHP is a "new kid on the block".
Here is a quick overview of what you will learn as you build experience:
You can write PHP source code that does useful tasks
You can organize useful tasks into "chunks" of code
You can think of "chunks" of code independently of the individual files where they are saved
Sometimes those "chunks" of code will behave differently based on parameters you pass in
Chunks of code that accept parameters are called "Functions"
Functions can be "chunked" together, and there are different ways of doing this:
OOP is a special way of "chunking" Functions together into a "Class"
A Class is just another level of "chunking" code together so that you can treat it as a unified whole
A Class can be thought of as a "chunking" of methods and properties
A Class is useful because it allows you to organize your code at a very high level in a way that makes it easy for you to understand, use, and maintain.
When someone has written a lot of functions, and organized them into a lot of Classes, and gotten those to work together in some cool way, they package the whole thing together and call it a "Framework".
A Framework is just the next-highest level of "chunking" (including coding style and conventions) that one or more people agree on because they like the way the code is organized and it suits their working style, preferences, values, plans for world domination, etc.
In a lot of scenarios, procedural programming is just fine. Using OO for the sake of using it is useless, especially if you're just going to end up with POD objects (plain-old-data).
The power of OO comes mainly from inheritance and polymorphism. If you use classes, but never use either of those two concepts, you probably don't need to be using a class in the first place.
One of the nicest places IMO that OO shines in, is allowing you to get rid of switch-on-type code. Consider:
function drive($the_car){
switch($the_car){
case 'ferrari':
$all_cars->run_ferrari_code();
break;
case 'mazerati':
$all_cars->run_mazerati_code();
break;
case 'bentley':
$all_cars->run_bentley_code();
break;
}
}
with its OO alternative:
function drive($the_car){
$the_car->drive();
}
Polymorphism will allow the proper type of "driving" to happen, based on runtime information.
Notes on polymorphism:
The second example here has some premisses: That is that all car classes will either extend an abstract class or implement an interface.
Both allow you to force extending or implementing classes to define a specific function, such as drive(). This is very powerful as it allows you to drive() all cars without having to know which one you're driving; that is because they're extending an abstract class containing the drive() method or implementing an interface forcing the drive() method to be defined.
So as long as you make sure that all your specific cars either extend the abstract class car or implement an interface such as canBeDriven (both of which must declare the drive() method) you can just call the drive() method on an object which you know is a car (but not what type of car) without fear of it not being defined, as PHP will throw fatal errors at you until you define those methods in your specific car classes.
re your comment, sounds like you need a root web context object that you reference the other objects from:
$ctx = WebContext::get();
$ctx->session->get('x');
$ctx->input->get('y');
$ctx->identity->valid;
etc... this is how most web frameworks do it.
$session would need to be defined, then referenced in the included file:
// If a global variable:
global $session;
$session->get('x');
// If a member of Core:
$this->session->get('x');
yes you can do that, probably you'll want require instead of require_once, and the paths would need to be based on the current working directory or an absolute path
try adding error_reporting(E_ALL) to see if any notices are happening...
With ip2long() it's easy to convert your addresses to numbers. After this, you just have to check if the number is in range:
if ($ip <= $high_ip && $low_ip <= $ip) {
echo "in range";
}
In OOP, SOLID stands for Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion.
Liskov substitution principle states that, in a computer program, if Bar is a subtype of Foo, then objects of type Foo may be replaced with objects of type Bar without altering any of the desirable properties of that program (correctness, task performed, etc.).
In strong-typed programming languages, when overriding a Foo method, if you change the signature in Bar, you are actually overloading since the original method and the new method are available with different signatures. Since PHP is weak typed, this is not possible to achieve, because the compiler can't know which of the methods you are actually calling. (hence the reason you can't have 2 methods with the same name, even if their signatures are different).
So, to avoid the violation of Liskov Substituition principle, a strict standard warning is issued, telling the programmer something might break due to the change of the method signature in the child class.