Przedstawiam 2 kody, które są niezgodne z Side Effects Rule.
KOD1

[PHP] pobierz, plaintext 
<?php
require __DIR__ . '/vendor/autoload.php';
$obj = new Johny\Foo\Bar();
[PHP] pobierz, plaintext 

KOD2

[PHP] pobierz, plaintext 
<?php
require __DIR__ . '/vendor/autoload.php';
include 'addresses_for_mailing.php';
$mailer = new Johny\Foo\Mailer($addresses);
$mailer->send();
$mailer->report();
[PHP] pobierz, plaintext 

Mam nadzieję, że mniej więcej widać, co programista chciał osiągnąć...

KOD1
Wczytuje autoloader i od razu z niego korzysta.

KOD2
Korzysta z klasy Mailer oraz spisu adresów zawartego w oddzielnym pliku. Potem wysyła mejle i sporządza raport z wysyłania.

I teraz moje pytanie. Jak zbudować te aplikacje, żeby były zgodne z PSR-1 Side Effects Rule. Czy da się zachowując odrębność plików, czyli bez umieszczenia wszystkiego w jednym pliku. Czy może programiści jednak nie przejmują się tą zasadą?

Z góry dziękuję

Ta zasada nie pozwala mieszać deklarowania (klas, funkcji, ustawień etc.) z wykonywaniem kodu.

Jeśli masz w pliku deklarację klasy, to nie powinno być tam żadnego include. Jeśli natomiast w danym pliku coś robisz, to… nie da się przecież nie zrobić include.

Zresztą to jest w pierwszym zdaniu tej zasady:


Kod wykonujący konkretne działania może mieć skutki uboczne. Kod deklarujący klasy, funkcje itd. – nie.

W pytaniu chodzi o to, jak przerobić podane aplikacje, aby były zgodne z tą zasadą.

A w moim poście masz odpowiedź…

Nie żartuj. Pytam jak uniknąć stosowania deklaracji i includowania w 1 pliku, a Ty odpowiadasz, że przez uniknięcie stosowania deklaracji i includowania w 1 pliku. Chodzi mi o przepisanie podanego kodu na poprawny. I nie o to, jakie tam zastosować zasady PSR, tylko jak powinien kod wyglądać konkretnie.

Jeśli to prośba o gotowca, to proszę o podanie zarysu struktury aplikacji w sensie użytych klas i plików.

Nie wiem na ile moja odpowiedź jest zgodna ze standardami, ale skoro w pliku "adresses_for_mailing.php" trzymasz jedynie adresy mailowe, może wartoby przenieść to do jakiejś klasy, która byłaby za to odpowiedzialna.

[PHP] pobierz, plaintext 
class Addresses
{
    public static function load()
    {
        return 'addresses';
    }
}
[PHP] pobierz, plaintext 

+ Namespace i konkret autoloader

Klasa trzymająca dane to jednak chyba rozwiązanie wątpliwe, bo dane się mogą zmieniać, a zmiana danych nie powinna wymuszać zmiany klasy. Naturalnym wydaje się trzymanie danych gdzieś na zewnątrz, w jakimś xml albo csv, czy bazie danych. I teraz, pobieranie tych danych to zawsze będzie zjawiskiem Side Effect.

@trzczy, problem w tym, że przedstawiony przez Ciebie kod jest poprawny…

include nie może być tam, gdzie deklarujesz klasy lub masz config aplikacji. W reszcie to nieistotne.

Dołączenie pliku np tablicy konfiguracyjnej nie ma zazwyczaj żadnych efektów ubocznych.. Problem się pojawi jak ten sam plik zacznie wykonywać ddatkowo logikę np zmieni ustawienia aplikacji przez redeklaracje ścieżek.

Przypisywanie zmiennej i tworzenie obiektu może sąsiadować z Side Effects. Ok. Z kolei proste inkludowanie danych nie jest Side Effects.