Alexander Makarov "Let’s talk about code"

❌ Let's talk about code ✔
Alexander Makarov, Yii framework

1. Composition and inheritance.
2. State.
3. Dependencies and injection.
4. Methods.
5. Exceptions.
6. Object types.
7. Services and PHP long running servers.
8. Tests.
9. Principles.
10. Layers and abstraction.

● Inheritance.
● Coupling.
● State.
● Assumptions.
● Testing.
● Architecture.
● ...

😍 Composition and inheritance 🤨

😍 Composition vs inheritance 🤕

abstract class Notifier
{
private string $template;
private array $parameters;
public function __construct(string $template, array $parameters = [])
{
// ...
}
protected function renderTemplate(): string
{
// ...
}
abstract public function send(): void;
}

final class EmailNotifier extends Notifier
{
private string $to;
private string $subject;
public function __construct(string $to, string $subject, string $template, array
$parameters = [])
{
// ...
}
public function send(): void
{
mail($this->to, $this->subject, $this->renderTemplate());
}
}

abstract Notifier - compose message, send message
○ final EmailNotifier.
○ final SmsNotifier.
○ final DebugNotifier.
Problems?
Notifier is coupled with concrete implementations.
We need more!
○ Sms notifier and Email notifier should log.
○ Sms notifier and Email notifier should not allow to send message twice.
○ We should send to multiple channels with fallback.
○ We should not send emails on April 1st.
○ 😱

Let's try without inheritance? 😎

final class Notifier
{
private Sender $sender;
public function __construct(Sender $sender) {
// ...
}
public function send(Message $message, Address $to): void
{
$this->sender->send($message, $to);
}
}

interface Message
{
public function getSubject(): string;
public function getText(): string;
}
final class Address
{
public function getEmail(): string { … }
public function getPhone(): string { … }
}

interface Sender
{
public function send(Message $message, Address $to): void;
}

class EmailSender implements Sender
class SmsSender implements Sender
class Logger implements Sender
class DuplicatePreventer implements Sender
$sender = new DuplicatePreventer(new Logger(new SmsSender()));
$notifier = new Notifier($sender);
$notifier->send($message, $to);

So… inheritance is bad?
● Yes. Prefer to avoid it.
● Use it where appropriate: exceptions and other
hierarchies.

final class DataProvider
{
public function __construct(Query $query, Connection $connection) { ... }
public function all()
{
return $this->connection->findAll($this->query);
}
public function one()
{
$limitedQuery = $this->query->limit(1);
return $this->connection->findOne($limitedQuery);
}
}

$query = (new Query())
->select()
->from('post');
$dataProvider = new DataProvider($query);
var_dump($dataProvider->one());
var_dump($dataProvider->all());

interface QueryInterface
{
public function select(string $columns): self;
public function from(string $table): self;
public function limit(int $limit): self;
}

Alexander Makarov "Let’s talk about code"

public function limit(int $limit): self
{
$this->limit = $limit;
return $this;
}

public function one()
{
$limitedQuery = $this->query->limit(1);
return
$this->connection->findOne($limitedQuery);
}

public function limit(int $limit): self
{
$new = clone $this;
$new->limit = $limit;
return $new;
}

State
● Avoid it if possible.
● Encapsulate it.
● Absolutely avoid for ﬂuent interfaces.
● Fluent interface = immutability.

Dependencies and injection 🤓

Is it possible to do it wrong?

{
private ContainerInterface $container;
public function __construct(ContainerInterface $container) {
// ...
}
{
$sender = $this->container->get(Sender::class);
$sender->send($message, $to);
}
}

public function __construct(ContainerInterface $container) {
// ...
}
{
$sender = $this->container->get(Sender::class);

Dependency Injection
● DI is simple.
● You can do DI without container.
● Prefer composition over inheritance.
● Request what you need, not what you want to
ask to get what you need.
● Avoid passing container around.

Is it possible to do moar wrong?

{
{
$sender = App::$container->get(Sender::class);
$sender->send($message, $to);
}
}

Method structure
1. Precondition checks.
2. Failure scenarios.
3. Main path.
4. Postcondition checks.
5. return.

Precondition checks
● Check if arguments are valid.
● Throw InvalidArgumentException.
● Don't try to "ﬁx" things.

Fixing things
● Auth via Facebook. Same nickname present.
Attach Facebook ID to the account.
● Only letters are allowed in a nickname.
"samdark123" entered. Fix it by removing all
the numbers.

Failure scenarios
● RuntimeException.
● Avoid trying to "ﬁx" things.

Main path
● Just what method does.

Postcondition checks
● Check if what was done is done right.
● Throw RuntimeException if not.

Cyclomatic complexity
Number of independent execution paths in a
control graph.

V(G) = E - N + 2 = 7 - 6 + 2 = 3
V(G) = P + 1 = 2 + 1 = 3
● V(G) - cyclomatic complexity.
● E - edges.
● N - nodes.
● P - control structure points:
○ if → 1.
○ compound if → number of
sub-conditions.
○ iteration → 1.
○ switch → 1 per branch.
Keep cyclomatic
complexity low.

{
if (!isset($data['username'], $data['password'])) {
throw new InvalidArgumentException('Both username and password are required.');
}
if ($user === null) {
throw new InvalidArgumentException('User not found.');
}
if (!$user->isPasswordValid($data['password'])) {
throw new InvalidArgumentException('Password is not valid.');
}
$this->loginUser();
$this->refresh();
}

{
$this->assertUsernameAndPasswordPresent($data);
$this->assertUserFound($user);
$this->assertPasswordValid($user, $data['password']);
$this->loginUser();
$this->refresh();
}

If a method has a boolean ﬂag:
1. Single responsibility principle is violated.
2. You need multiple methods instead.

Visibility scopes
Private should be your default.

Exceptions
● Two types:
○ Ones we can handle.
■ Custom type, domain exceptions.
○ Ones we should not handle.
■ Prefer built-in types:
● RunitmeException.
● InvalidArgumentException.

Exception messages
● Should be explanative.
● Use proper English sentences.

Friendly exceptions
● https://github.com/yiisoft/friendly-exception
● getName().
● getSolution().

Services and non-services
● Services are doing something.
● Non-services hold data and return/mutate it.

Domain objects
● Extract domain objects to validate less.
○ Money, Point, Email.
● Composite values are object as well.
● Should not have dependencies injected. Only values.
● Use static named constructors: fromString, fromInt etc.
● Use private constructor for validation.
● Do not bloat these.
● Immutable.

DTO
● Can go crazy here but keep it simple.
● Public properties are ﬁne :)
● Collect errors instead of throwing
exceptions.
● Use mass-assign.

Services / Components
● Created once.
● Usually immutable.
● Use proper DI.
● Usually stored in DI container and/or accessible
via service locator.

Rules for a service
● Preferably stateless.
● No method injection or property injection.
● No optional dependencies.
● Explicit dependencies (proper DI).
● Action-relevant data should be passed to action
method.
● Light constructors. Postpone initialization.
● Do not make assumptions. Throw exceptions right
away.

How it works
// initialization
while ($request = $psr7->acceptRequest()) {
$response = $application->handle($request);
$psr7->respond($response);
gc_collect_cycles();
}

Rules
● Stateless services / State reset.
● Taking care about memory.
● Killing what's not used.

How to write tests
● Arrange, act, assert.
● No dependencies.
● One test - one AAA.
● Prefer black box tests.
○ Test public API.
○ Hands oﬀ non-public API!
○ Don't check internal state!
○ Don't test methods, tests behavior.

Should it be immutable?
● Service = immutable (if possible).
● Entity = mutable.
● Other objects = immutable.
● Fluent interface = immutable (don't do it with
mutable objects).

How to mutate object?
● DTO:
○ Directly.
● Value objects:
○ Immutable chaining.
● Entities:
○ Record changes as events.
● Other objects:
○ Immutable chaining.

Command-query separation
● Doing both is confusing.
● In some cases it is necessary.

Query method
class ShoppingCart
{
public function getTotal(): int {
}
}

Rules for queries
● Return a single type.
● Do not return internal state.
● Be speciﬁc. Avoid too ﬂexible methods.
● Add abstraction for queries crossing system
boundaries.
● Do not use command methods in query
methods.

Command method
class ShoppingCart
{
public function addItem(Item $item): void {
if ($this->getTotal() + $item->cost > self::MAX_TOTAL) {
throw new MaxTotalReached('Leave something for others!');
}
$this->items[] = $item;
}
}

Rules for commands
● Name in imperative form.
● Limit the scope, postpone with events and
queues.
● Throw exceptions.
● Add abstraction for commands crossing system
boundaries.
● Use queries to get info, commands to process it.

Read/write models
● Similar to query / command.
● Search in Elastic / Insert to MySQL.
● Read models should be use-case speciﬁc.
● Read models should be close to data source.

🥞 Layers and abstraction 🍔

Don't over-abstract
● Some objects are meant to be concrete:
○ Controllers.
○ Application services.
○ Entities.
○ Value objects.

❓ Questions time!
● https://www.yiiframework.com/
● https://twitter.com/sam_dark
● https://rmcreative.ru/
● PHP Russia Videos
● Further learning:
○ Matthias Noback https://matthiasnoback.nl/
○ Cyclomatic complexity by Anna Filina
https://www.youtube.com/watch?v=UdjEb6t9-e4
○ Anthony Ferrara videos: https://www.youtube.com/user/ircmaxell/videos

Alexander Makarov "Let’s talk about code"

More Related Content

What's hot (20)

Similar to Alexander Makarov "Let’s talk about code" (20)

More from Fwdays (20)

Recently uploaded (20)

Alexander Makarov "Let’s talk about code"