Forem: Billie

How do you maintain entity state in Golang

Billie — Thu, 14 Sep 2017 11:25:27 +0000

Is this the best way in Go to create an Entity that can't be set into an invalid state?

Here's an example of how I might implement it. I'm unsure if this is very idiomatic.

package custom_subdomain

import (
    "errors"
    "regexp"
)

type domainReg struct {
    domainName string
    // Other values ...
}

func NewDomainRegistration(domainName string) (*domainReg, error) {
    reg := &domainReg{}
    if err := reg.SetDomainName(domainName); err != nil {
        return nil, err
    }

    return reg, nil
}

func (r *domainReg) GetDomainName() string {
    return r.domainName
}

func (r *domainReg) SetDomainName(domain string) error {
    matches, err := regexp.Match("\\.example.com$", []byte(domain))

    if err != nil {
        return err
    }

    if !matches {
        return errors.New("all domains must be sub-domains to .example.com")
    }

    r.domainName = domain

    return nil
}

type DomainRegistration interface {
    GetDomainName() string
    SetDomainName(domain string) error
}

package main

import (
    "fmt"
    "github.com/purplebooth/entity-state-example"
    "log"
)

func main() {

    reg, err := custom_subdomain.NewDomainRegistration("test.example.com")

    if err != nil {
        log.Panic(err)
    }

    fmt.Println(reg.GetDomainName())

}

Breaking Encapsulation with traits in PHP

Billie — Sun, 06 Aug 2017 22:20:24 +0000

Traits in PHP are dangerous because they allow the accidental breaking of encapsulation, for no real gain. In this example you can see an example of traits vs an invokable class, you could use any callable type here for the same effect. You can avoid this by being careful and not setting any member variables in traits, but everyone makes mistakes, so why risk it, when the encapsulation comes for free with callable types?

<?php

declare(strict_types=1);

use PurpleBooth\EncapsulationTraits\ExampleClass;

require_once __DIR__.'/vendor/autoload.php';

$instance = new ExampleClass();

echo sprintf("%s:\t%s\n", 'new', $instance->getName());
$instance->changeNameTrait();
echo sprintf("%s:\t%s\n", 'trait', $instance->getName());

$instance = new ExampleClass();
echo sprintf("%s:\t%s\n", 'new', $instance->getName());
$instance->changeNameInvokable();
echo sprintf("%s:\t%s\n", 'anonf', $instance->getName());

<?php

declare(strict_types=1);

namespace PurpleBooth\EncapsulationTraits;

class ExampleClass
{
    use ExampleTrait;

    private $name = 'Initial';
    private $changeNameInvokable;

    /**
     * ExampleClass constructor.
     */
    public function __construct()
    {
        $this->changeNameInvokable = new ExampleInvokable();
    }

    public function changeNameInvokable(): void
    {
        call_user_func($this->changeNameInvokable);
    }

    public function getName(): string
    {
        return $this->name;
    }
}

<?php

declare(strict_types=1);

namespace PurpleBooth\EncapsulationTraits;

trait ExampleTrait
{
    public function changeNameTrait(): void
    {
        $this->name = 'I broke encapsulation';
    }
}

<?php

declare(strict_types=1);

namespace PurpleBooth\EncapsulationTraits;

class ExampleInvokable
{
    public function __invoke(): void
    {
        $this->name = 'I do nothing';
    }
}

$ php run.php 
new:    Initial
trait:  I broke encapsulation
new:    Initial
anonf:  Initial

Code in easier to run form on github

Coding standards in PHP using PHP-CS-Fixer

Billie — Sat, 05 Aug 2017 07:03:43 +0000

One of the best things you can do early on in your project is define a coding standard.

This has a number of benefits:

Standard inline documentation
No indentation conflicts when editing others code
Reduced cognitive overhead when switching files and code blocks
Less time talking about coding standards
Enable static analysis of code based on inline documentation

Now in PHP we are very lucky to have an organisation that defines sensible standards for code, the FIG (or Framework Interoperability Group). These come in the form of PSR-1 and PSR-2. These standards are pretty loose but all of the major frameworks use them, but it's worth making sure the standard you choose does too.

When choosing a coding standard if you have framework or library you use a lot, then you should consider having a coding standard that matches it. By doing this the "other" code that you come into contact with most. This has the added benefit that if you get a new team member they're going to feel at home with the similar style to code they have seen before.

Also this gives you a direct way to defuse arguments about X styling trait, pass on the blame to the library you are taking your style from.

The next important thing to bare in mind is no one will follow your standard if you can't automatically fix your code to it. If you mildly disagree with the indentation or styling of code it's easy to gloss over that if it's automatically fixed just before you commit, but if you have to go through each instance and fix them manually, people will get pissed off. Ultimately unhappy developers don't do things that they don't want to - especially easy to be missed things like a coding standard.

To this end I would recommend using php-cs-fixer. PHP-CS-Fixer is a PHP tool that will help you fix your PHP code to follow, by automatically fixing the problems with coding style in your codebase.

You can run it in a couple of ways. Firstly just standalone using someone elses standard.

php-cs-fixer fix /path/to/project --rules=@Symfony

Would fix your project to Symfony stanard.

You can even add extra fixers too

php-cs-fixer fix /path/to/project --rules=@Symfony,ordered_class_elements

Would fix your project to Symfony standard, and include the ordered_class_elements fixer, that orders the elements in a class.

Getting each developer to remember what flags to pass for a project could be tricky though, so you can save this in a .php_cs.dist file with your standard in.

This is a copy of what my standard looks like.

<?php

return PhpCsFixer\Config::create()
                        ->setRiskyAllowed(true)
                        ->setRules(
                            [
                                '@Symfony' => true,
                                '@Symfony:risky' => true,
                                '@PHP71Migration' => true,
                                'array_syntax' => ['syntax' => 'short'],
                                'dir_constant' => true,
                                'heredoc_to_nowdoc' => true,
                                'linebreak_after_opening_tag' => true,
                                'modernize_types_casting' => true,
                                'no_multiline_whitespace_before_semicolons' => true,
                                'no_unreachable_default_argument_value' => true,
                                'no_useless_else' => true,
                                'no_useless_return' => true,
                                'ordered_class_elements' => true,
                                'ordered_imports' => true,
                                'phpdoc_add_missing_param_annotation' => ['only_untyped' => false],
                                'phpdoc_order' => true,
                                'declare_strict_types' => true,
                                'doctrine_annotation_braces' => true,
                                'doctrine_annotation_indentation' => true,
                                'doctrine_annotation_spaces' => true,
                                'psr4' => true,
                                'no_php4_constructor' => true,
                                'no_short_echo_tag' => true,
                                'semicolon_after_instruction' => true,
                                'align_multiline_comment' => true,
                                'doctrine_annotation_array_assignment' => true,
                                'general_phpdoc_annotation_remove' => ['annotations' => ["author", "package"]],
                                'list_syntax' => ["syntax" => "short"],
                                'phpdoc_types_order' => ['null_adjustment'=> 'always_last'],
                                'single_line_comment_style' => true,
                            ]
                        )
                        ->setCacheFile(__DIR__.'/.php_cs.cache')
                        ->setFinder(
                            PhpCsFixer\Finder::create()
                                             ->in(__DIR__)
                        );

This file is hands in other ways. You can also tell php-cs-fixer to skip certain files.

See this finder line

          ->setFinder(
                            PhpCsFixer\Finder::create()
                                             ->in(__DIR__)
                        );

You ignore files by adding this

          ->setFinder(
                            PhpCsFixer\Finder::create()
                                             ->in(__DIR__)
                                             ->notPath('/^app\/check.php/')
                                             ->notPath('/^web\/config.php/')

                        );

You can find a full guide on everything you can do with php-cs-fixer here. But hopefully this is enough to get you started using a tool that is super useful for all PHP projects.

Hi, I'm Billie

Billie — Thu, 06 Jul 2017 11:55:08 +0000

I have been coding for 10 years.

You can find me on Twitter as @PurpleBooth

I live in London.

I work for Purple Booth Ltd

I mostly program in these languages: JavaScript, PHP, and GoLang.

I am currently learning more about GoLang!

Nice to meet you.