Niezalogowany [ logowanie ]
Subskrybuj kanał ATOM Kanał ATOM    Subskrybuj kanał ATOM dla tagu oop Kanał ATOM (tag: oop)

Autor wpisu: matipl, dodany: 08.01.2019 13:20, tagi: php, oop

Od miesiąca możemy cieszyć się PHP w wersji 7.3, który jest kolejnym krokiem ewolucji jaka zachodzi w tym popularnym języku. Obecne zmiany to dopracowywanie prostszego sposobu tworzenia aplikacji, jak również dopracowywanie samego silnika.

WordPress 5.0 benchmark

Dzięki tym zmianom PHP wciąż przyspiesza. To prawda, że to głównie zasługa coraz lepszego opcache, ale jednak jest to część silnika. WordPress nie jest dobrym przykładem jak powinno się pisać kod, ale jest dobrym przykładem na wzrost wydajności PHP na przestrzeni lat:

  • PHP 5.6: 91.64 req/sec
  • PHP 7.0: 206.71 req/sec
  • PHP 7.1: 210.98 req/sec
  • PHP 7.2: 229.18 req/sec
  • PHP 7.3: 253.20 req/sec

PHP 7.3

PHP 7.3 przyniósł bardzo wiele przydatnych funkcji, które zostały przegłosowane przez społeczność w ramach zgłaszanych RFC. W nowej wersji możemy teraz zostawiać nie tylko przecinek po ostatnim elemencie w tablicy, ale również w wywołaniu metody:

$newArray = array_merge(
    $arrayOne,
    $arrayTwo,
    ['foo', 'bar'],
);

Kolejne wbudowane funkcje zostały wsparte o wyjątki. Tym razem wyjątki zostały wprowadzone do wywołań json_encode() i json_decode(). Oczywiście zgodność wsteczna jest ważna w PHP, dlatego aby został rzucony wyjątek należy dodać parametr JSON_THROW_ON_ERROR:

try {
    $decoded = json_decode("{ 'invalid' : 'json' }", false, 512, JSON_THROW_ON_ERROR);
} catch (\JsonException $e) {
    echo $e->getCode(); // 4
    echo $e->getMessage(); // Syntax error
}

Poza tym pojawiły się…. nowe fukncje. Na przykład is_countable(), która sprawdzi czy rzecz jest policzalna (count() od PHP 7.2 rzuca Warning, gdy jest wykonywane na czymś co jest niepoliczalne). Dodano również monotoniczny timer wysokiej rozdzielczości (hrtime()), który nie ma jeszcze dokumentacji na php.net, ale jest następcą polecenia microtime(), ale jest niezależny od zmiany czasu systemowego.

I na koniec, przypominam, że obecnie wspierane wersje PHP zaczynają się od wersji 7.1. Wersja 7.0 oraz 5.6 nie posiada już żadnego wsparcie, nawet łatek bezpieczeństwa.

PHP 7.4 – Typowanie 2.0

Jednym z większych przełomów jakie przyniósł PHP 7 (2015) jest możliwość deklaracji typów. Tego czego wciąż brakuje, to możliwość ustalenia typu właściwości klasy już na etapie jej opisywania, a nie tworzenia metod. PHP 7.4, który pojawi się pod koniec 2019 roku rozwiąże ten problem.

class User {
    public int $id;
    public string $name;
 
    public function __construct(int $id, string $name) {
        $this->id = $id;
        $this->name = $name;
    }
}

Po wprowadzeniu Typed Properties 2.0, komentarze w PHP znów będą służyły do komentowania kodu, a nie uzupełniały braki języka poprzez @param, @return itp. Pozostaje czekać.

Artykuł PHP 7.3 na pokładzie, przed nami PHP 7.4 pochodzi z serwisu Mateusz matipl Kamiński.

Autor wpisu: bastard13, dodany: 26.06.2015 22:10, tagi: design, oop

o prawach i zasadach

Jakiś czas temu pisałem o Law of Demeter, o tym o co w tym właściwie chodzi oraz o plusach przestrzegania prawa :) Dzisiaj chciałbym przybliżyć Wam zasadę Tell, don’t ask, która w moim odczuciu jest punktem wyjścia do wspomnianego wcześniej prawa, przestrzeganie LoD jest jednym z następstw stosowania zasady TDA.Czytaj więcej »

Autor wpisu: bastard13, dodany: 12.05.2015 23:45, tagi: design, oop

Wszystko ma sens wtedy, gdy ma sens. Nie tworzysz kodu, którego nie potrzebujesz z kilku powodów. Po pierwsze, może się okazać, że go (o ironio!) nie będziesz potrzebował. Po drugie, dodajesz pracy sobie i innym, ponieważ ktoś musi o ten kod dbać, ktoś będzie go zapewne niejednokrotnie czytał, i tak dalej. Po trzecie, kod który jest niepotrzebny stwarza problemy ze zrozumieniem aplikacji, bo przecież „skoro ktoś to dodał, to jest potrzebne”. Nie zawsze jednak jest tak, że kod niepotrzebny nie jest nigdzie wykorzystywany. Zdarzają się sytuacje, gdy powstają metody, które co prawda są użyte, ale są jedynie elementem pewnej funkcjonalnej całości i same nie niosą nic poza potencjalnymi problemami. I o takich tworach chciałbym dzisiaj opowiedzieć.Czytaj więcej »

Autor wpisu: bastard13, dodany: 20.04.2015 22:39, tagi: design, oop

z obcymi (nie) za pan brat

Jeżeli chcielibyśmy ująć kwintesencję Prawa Demeter (Law of Demeter) w jednym zdaniu to brzmiałoby ono: "rozmawiaj tylko z (bliskimi) przyjaciółmi". W pełnej formie mówi ono o tym, że metoda danego obiektu może odwoływać się jedynie do metod należących do:
  • tego samego obiektu,
  • dowolnego parametru przekazanego do niej,
  • dowolnego obiektu przez nią stworzonego,
  • dowolnego składnika, klasy do której należy dana metoda.
Czytaj więcej »

Autor wpisu: matipl, dodany: 07.03.2015 10:57, tagi: php, oop

Przez pryzmat ostatnich rozmów rekrutacyjnych, oraz architektury kilku projektów jakie analizowałem, dochodzę do wniosku, że spora część „programistów” nie tylko nie widzi sensu, co nie nie ma pojęcia o istnieniu pewnych standardów w świecie PHP. Dzisiaj chciałbym przybliżyć kilka pojęć, kilka z naciskiem na OOP.

PHP Framework Interop Group (PHP-FIG)

Moim zdaniem w tym momencie znajomość PSR-0 do PSR-4 to podstawa. Projekt PHP-FIG zawiązał się w 2012 roku (3 lata temu). Przy „jednym stole” zasiadł m.in. Matthew Weier O’Phinney reprezentujący ZF2, Fabien Potencier z Symfony2, jak również Jordi Boggiano odpowiedzialny za Composer i Packagist. Pomysł był prosty – każdy zespół podchodził inaczej do tematu autoloadera (PSR-0), jak również pojawiały się różne wariacje coding style (PSR-1 i PSR-2). Później powstał standard związany z interfejsem dla Loggera (PSR-3, dla niektórych dyskusyjne, dla mnie ok) oraz udoskonalona koncepcja autoloadera (PSR-4). A reszta już poszła lawinowo, zespół poniosła fantazja.

Reguła KISS

KISS to skrót od Keep It Simple, Stupid. Nie komplikuj kodu, pisz przejrzysty kod bez zbędnych dodatków. Dojdzie nowy programista do projektu, lub ktoś przejmie projekt? Taka osoba powinna móc szybko się wdrożyć, zrozumieć kod bez czytania obszernej dokumentacji i wprowadzić potencjalne poprawki. Pamiętaj – twórz i utrzymuj taki kod, żeby każdy mógł go zrozumieć i nie musiał posiadać doktoratu w tej dziedzinie.

Zasada DRY

DRY to skrót od Don’t Repeat Yourself. Krótko: nie powtarzaj się. Widzisz podobne elementy kodu? Wydziel je, ustandaryzuj. Podczas deploy’u robisz zawsze te same czynności ręcznie? Zautomatyzuj to. Zaczynasz kolejny projekt? Z poprzedniego wydziel wspólną bibliotekę/bundle/etc.

Zasada YAGNI

YAGNI to skrót od You Aren’t Gonna Need It. Nie potrzebujesz czegoś tu i teraz, ani w następnej iteracji? Nie rób tego, nie twórz kodu na wyrost bo kiedyś wykorzystasz jakiś interfejs, albo cały mechanizm do tworzenia uniwersalnych walidatorów. Większa ilość kodu zwiększa prawdopodobieństwo wystąpienia błędów oraz skomplikowanie kodu. Ta zasada po części wiąże się z KISS – wybieraj najprostszą drogę do celu, która daje zwiększoną niezawodność zaimplementowanych algorytmów.

Wzorce projektowe

Jest to chyba jedyny element programowania obiektowego, który został opanowany, a raczej wykuty przez programistów. Większość osób jest w stanie wymienić 3 wzorce i je opisać. Gorzej z wytłumaczeniem własnymi słowami do czego tak naprawdę dany wzorzec służy. Moim zdaniem lepiej nie znać na blachę kilku pojęć z PHP, niż mieć problem ze zrozumieniem podstaw. Przy okazji przypomnijmy sobie czym jest OOP – podstawowe założenia paradygmatu obiektowego:

  • Abstrakcja
  • Hermetyzacja
  • Polimorfizm
  • Dziedziczenie

SOLID

Same wzorce projektowe, czy tworzenie klas i ich ciał nie świadczą o tym, że programuje się już obiektowo. Możemy mieć masę klas, zależności itp. A kod nadal jest proceduralny, bo ciągle zapominamy o OOP. W tym przypadku pomoże nam zastosowanie 5 założeń nazwanych w skrócie SOLID.

GRASP

Jakby równolegle obok zasad projektowania obiektowego SOLID, są zasady GRASP (General Responsibility Assignment Software Patterns).

W dużym uproszczeniu w GRASP chodzi o opisanie podstawowych zasad, którymi będziemy kierować się podczas tworzenia całego projektu, gdzie wszystko kręci się wokół metodycznego podejścia do fundamentów OOP. GRASP składa się z 9 zasad: Creator, Information Expert, Controller, Low Coupling, High Cohesion, Polymorphism, Indirection, Pure Fabrication, Protected Variations. Małe wprowadzenie do GRASP znajdziecie w grwykładzie Wiktora Zychla.

Konferencje

Tak wiem, konferencje != stanardy, przynajmniej teoretycznie. Jeśli znasz powyższe reguły, przeczytałeś wiele mądrych książek oraz masz za sobą kilka projektów… Pamiętaj nie stój w miejscu, świat dookoła się zmienia, tak samo zmienia się IT. Powstają nowe frameworki, biblioteki, narzędzia, inni programiści natrafiają na inne problemy. Warto pojechać chociażby na PHPCon (niedługo pojawią się informacje o tegorocznej edycji), czy również pójść na spotkanie lokalnej społeczności (PHPers).

Czytaj dalej tutaj (rozwija treść wpisu)
Czytaj dalej na blogu autora...

Autor wpisu: bastard13, dodany: 06.03.2015 07:13, tagi: design, oop

Tematem Domain-Driven Design jestem zainteresowany już od dłuższego czasu, ale ostatnio częstotliwość jego występowania przy okazji developmentu znacznie się zwiększyła.Biorąc to pod uwagę zdecydowałem się na odświeżenie swojej pamięci i ponowne przewertowanie stronic Domain-Driven Design Eric’a Evansa. A skoro już to zrobiłem, to chyba warto podzielić się odczuciami i obserwacjami na temat tej lektury z Wami.Czytaj więcej »

Autor wpisu: Piotr Pasich, dodany: 30.01.2015 09:23, tagi: oop

NamingConventions

Hi! First of all I’d like to ask you a question – what’s your name? My name is Piotr and that is derived from the Greek Πετρος (Petros) meaning “stone”.  Next to me is sitting my friend – Michael. Michael is from the Hebrew name מִיכָאֵל (Mikha’el) meaning “who is like God?” (after this article […]

The post ClassManager – You shall not pass appeared first on Piotr Pasich.

Wszystkie wpisy należą do ich twórców. PHP.pl nie ponosi odpowiedzialności za treść wpisów.