Ползване на интерфейси, добра практика ли е ?

[Pok4]

Здравейте хора,

Тъй като в предишни екстеншъни, които са правени за Аргос срещнах интерфейс, който представлява това:

<?php
namespace Ext\val4o0o0\credits;
 
interface Interface_Credits
{
    public function get_credits($user_id);
    public function set_credits($user_id,$credits);
    public function remove_credits($user_id,$credits);
}

И това нещо се имплементира в контролерите така:

//Your Extension Script
class credits extends \App\Controllers\BaseController implements \Ext\val4o0o0\credits\Interface_Credits {

И дефакто, то те задължава да имаш тези 3 метода, описани точно така в даден контролер.
Целта явно е била, да се задължат тези, които пишат други екстеншъни, които работят с кредит системата, да имат тези 3 метода и да ги ползват, за да работят по този дизайн (така да го кажа)

Това добра практика ли е и въобще някой ползва ли такива неща ?

 

[topchokt]

Разбира се, че се ползват и аз лично го смятам за добра практика. Зависи от случая, колко хора работят и т.н., но се използват и е препоръчително да се използват, когато е необходимо.

Давам супер прост пример. Например, правиш sdk за кънекция към база данни. В този случай, обаче базата може да използва различен драйвър - например - mysql, mongodb или нещо друго, при всички положения, обаче, решаваш, че независимо от типа база, класовете, трябва да имат метод connect(). В такъв случай, правиш един интерфейс с метод connect() и всеки клас, например mysql, mongodb ще имплементира този интерфейс, което означава, че в него трябва да има имплементиран метода connect(). После имаш един общ клас например DBConnection, който просто връща инстанция от класовете mysql, mongodb - благодарение на този интерфейс, си гарантираш, че тази инстация ще има метод connect(), който може да използваш или ако утре, някой реши, че иска да добави нов драйвър - например redis, благодарение на interface-а, той ще е задължен отново да имплементира този метод и теб няма, като човек, който не е писал този нов клас, после като го използваш, няма да те интересува какво точно се прави в connect и как е имплементиран, но благодарение на интерфейса, ще знаеш, че такъв метод съществува.


Друг пример - например имаш много класове, които са свързани с интеграции - Facebook, Twitter и там каквото се сетиш. Да примем, че има и interface за тях, където има метод disconnect(). Ако всеки клас (интеграция) имплементира този интерфейс, то в него ще трябва има метод disconnect(). Това е удобно, защото, когато знаеш, че става дума за клас интеграция, ти може да извикаш метода disconnect() и той ще го има, просто защото всички интеграция наследяват този интерфейс - идеята на този метод ще е да прекратява интеграцията, а как точно е имплементира и какво точно прави - теб не те интересува.


Не съм сигурен дали примерите са най-добрите, но мисля, че ще схванеш каква е идеята.

 

[Pok4]

Благодаря

 

[anonimen]

И дефакто, то те задължава да имаш тези 3 метода, описани точно така в даден контролер.
Целта явно е била, да се задължат тези, които пишат други екстеншъни, които работят с кредит системата, да имат тези 3 метода и да ги ползват, за да работят по този дизайн (така да го кажа)

Това добра практика ли е и въобще някой ползва ли такива неща ?

На така формулиран въпроса аз бих казал НЕ. Идеята на интерфейсите не е да те задължат да имплементираш методи просто ей така.

Идеята е да предоставиш възможност на потребителя на твоя код да работи с теб, давайки ти минималната нужна имплементация, за да си свършиш работата.
В твоята система има смисъл от този интерфейс, ако искаш да поддържаш произволни модули, които имат собствен "вид кредити", и за произволен предоставен вид кредити искаш ядрото на системата да знае кой потребител колко от тях има и да му добавя/трие от тях. (аналогията с поста на топчето са различните видове бази, с които твоята система може да работи, използвайки само connect и query методи).

 

[Revelation]

Също така са полезни при създаването на unit тестове, когато трябва да се моква даден сървиз.