Liste des liens
Liste de vidéos à voir sur le css
Série de tutoriels sur node-webkit.
"Just one more time, in the simplest terms possible:
An Interface is like a protocol. It doesn't designate the behavior of the object; it designates how your code tells that object to act. An interface would be like the English Language: defining an interface defines how your code communicates with any object implementing that interface.
An interface is always an agreement or a promise. When a class says "I implement interface Y", it is saying "I promise to have the same public methods that any object with interface Y has".
On the other hand, an Abstract Class is like a partially built class. It is much like a document with blanks to fill in. It might be using English, but that isn't as important as the fact that some of the document is already written.
An abstract class is the foundation for another object. When a class says "I extend abstract class Y", it is saying "I use some methods or properties already defined in this other class named Y".
So, consider the following PHP:
<?php
class X implements Y { } // this is saying that "X" agrees to speak language "Y" with your code.
class X extends Y { } // this is saying that "X" is going to complete the partial class "Y".
?>
You would have your class implement a particular interface if you were distributing a class to be used by other people. The interface is an agreement to have a specific set of public methods for your class.
You would have your class extend an abstract class if you (or someone else) wrote a class that already had some methods written that you want to use in your new class.
These concepts, while easy to confuse, are specifically different and distinct. For all intents and purposes, if you're the only user of any of your classes, you don't need to implement interfaces."
Quelques précisions supplémentaires et l'explication de la différence entre abstraction et interface.
"It seems like many contributors are missing the point of using an INTERFACE. An INTERFACE is not specifically provided for abstraction. That's what a CLASS is used for. Most examples in this article of interfaces could be achieved just as easily using just classes alone.
An INTERFACE is provided so you can describe a set of functions and then hide the final implementation of those functions in an implementing class. This allows you to change the IMPLEMENTATION of those functions without changing how you use it.
For example: I have a database. I want to write a class that accesses the data in my database. I define an interface like this:
interface Database {
function listOrders();
function addOrder();
function removeOrder();
...
}
Then let's say we start out using a MySQL database. So we write a class to access the MySQL database:
class MySqlDatabase implements Database {
function listOrders() {...
}
we write these methods as needed to get to the MySQL database tables. Then you can write your controller to use the interface as such:
$database = new MySqlDatabase();
foreach ($database->listOrders() as $order) {
Then let's say we decide to migrate to an Oracle database. We could write another class to get to the Oracle database as such:
class OracleDatabase implements Database {
public function listOrders() {...
}
Then - to switch our application to use the Oracle database instead of the MySQL database we only have to change ONE LINE of code:
$database = new OracleDatabase();
all other lines of code, such as:
foreach ($database->listOrders() as $order) {
will remain unchanged. The point is - the INTERFACE describes the methods that we need to access our database. It does NOT describe in any way HOW we achieve that. That's what the IMPLEMENTing class does. We can IMPLEMENT this interface as many times as we need in as many different ways as we need. We can then switch between implementations of the interface without impact to our code because the interface defines how we will use it regardless of how it actually works."
ET :
"When should you use interfaces? What are they good for?
Here are two examples.
- Interfaces are an excellent way to implement reusability.
You can create a general interface for a number of situations
(such as a save to/load from disk interface.) You can then
implement the interface in a variety of different ways (e.g. for
formats such as tab delimited ASCII, XML and a database.)
You can write code that asks the object to "save itself to
disk" without having to worry what that means for the object
in question. One object might save itself to the database,
another to an XML and you can change this behavior over
time without having to rewrite the calling code.
This allows you to write reusable calling code that can work
for any number of different objects -- you don't need to know
what kind of object it is, as long as it obeys the common
interface.
- Interfaces can also promote gradual evolution. On a
recent project I had some very complicated work to do and I
didn't know how to implement it. I could think of a "basic"
implementation but I knew I would have to change it later.
So I created interfaces in each of these cases, and created
at least one "basic" implementation of the interface that
was "good enough for now" even though I knew it would have
to change later.
When I came back to make the changes, I was able to create
some new implementations of these interfaces that added the
extra features I needed. Some of my classes still used
the "basic" implementations, but others needed the
specialized ones. I was able to add the new features to the
objects themselves without rewriting the calling code in most
cases. It was easy to evolve my code in this way because
the changes were mostly isolated -- they didn't spread all
over the place like you might expect."
Enfin, je comprends à quoi sert une interface (Merci à dlovell2001 at yahoo dot com et erik dot zoltan at msn dot com) ! Je n'avais jamais lu les commentaires associés à cette page. J'aurais dû le faire plus tôt.
Moralité : TOUJOURS LIRE LES COMMENTAIRES DES PAGES DE LA DOCUMENTATION PHP !
Articles sur svg à lire. Beaucoup de choses intéressantes et bien expliquées.
Une animation du système solaire. Assez bien réalisée pour expliquer à des cht'ite n'enfants.
Bon par contre, c'est en anglais...
Une documentation php un peu différente mais pertinente.
Un mode d'emploi du ficher htaccess.
Si Bronco tu me lis, vas y faire un tour... :)
Tout est dans le titre. A explorer. Vraiment bien rédigé et expliqué.
Tutoriels css et autres joyeusetés. A lire
Le site du zéro gouvernemental. A voir...
Le blog de Lea Verrou. Une référence.
Tout est dans le titre : des manuels en français sur des logiciels/programmes libres, en version html, epub et pdf.
Et chacun peut aider à améliorer chaque ouvrage, à la manière d'un wiki.