Hey! Whats'up?!

Is there some version of this repo in other language? I've forked this repo yesterday to translate to portuguese.

To contribute in translation, check Translation Rule/Hint below

[important] Before your start, re-fork this project or synchronize your repo with upstream!(because i just do some change)

Translation Rule/Hint

1. All po files were generated by all README.rst, Only them (explication of patterns) will be translated, Code and comments should be in English and not change. code is always the core of this repo.
2. Word for Word translation is not needed, you can add your own explication to make translation much easy to understand.
3. if you didn't found the language you want to translate, take a look at here, and @shangguokan who will add initial files.
4. You can use po editor or text editor to translate.
5. It remain some markup in po files, please be careful not to break reST notation.

example: Russian translation is completed

#: ../../Creational/AbstractFactory/README.rst:22
msgid "You can also find these code on `GitHub`_"
msgstr "在 `GitHub`_ 上查看代码"   (`xxx`_ one underscore here)

#: ../../Creational/AbstractFactory/README.rst:24
msgid "AbstractFactory.php"
msgstr ""                         (do not need translate xxx.php, keep it empty)

PR

if you finished, make one pull request or by "Russian translation part one two..."(maxi five) i will create project on read the doc and translation will be hosted at http://designpatternsphp.readthedocs.org/{language_slug}/latest/

Language

| language(click to preview) | translator | | --- | :-: | | ca – Catalan | @torrentalle | | en – English | @domnikl | | es – Spanish | @torrentalle @desarrolla2 | | pt_BR – Brazilian Portuguese | @leleonam @bgsouza @davispeixoto | | ru – Russian | @KIVagant | | zh_CN – Simplified Chinese | @su-xiaolin @yplam |

Title

It's possible to change english wikipedia link of title to the localized version. three formats are possible:

//take care of the num of underscore

#: ../../Behavioral/ChainOfResponsibilities/README.rst:2
msgid "`Chain Of Responsibilities`__"

//1. only keep russian title, russian link on russian title
msgstr "`Цепочка обязанностей <https://ru.wikipedia.org/wiki/Цепочка_обязанностей>`_" 

or
//2. keep two version titles, russian link on russian title, english link on english title
msgstr "`Цепочка обязанностей <https://ru.wikipedia.org/wiki/Цепочка_обязанностей>`_ (`Chain Of Responsibilities`__)"

or
//3. keep two version titles, russian link on russian title, no english link
msgstr "`Цепочка обязанностей <https://ru.wikipedia.org/wiki/Цепочка_обязанностей>`_ (Chain Of Responsibilities)"

or
//4. if no russian wikipedia page,so english link on russian title
msgstr "`Цепочка обязанностей`__" 

// I think 1 and 3 are best way

FAQ

1. How can i add some link or bold on the translation string? you can use reST markup. msgstr "External **hyperlinks**, likePython http://www.python.org/_."
2. How can i test my translation? first, you don't need test your translations. if you want, the repo use Sphinx + reStructuredText a.install sphinx on your computer http://sphinx-doc.org/ b.learn how translation works http://sphinx-doc.org/latest/intl.html c.Install sphinx-intl by pip install sphinx-intl or easy_install sphinx-intl. d.execute $ sphinx-intl build e.execute $ make -e SPHINXOPTS="-D language='pt_BR'" html f.you can find html in folder _build

What are you think to restructure this repository?

My proposal:

Create a directory structure with types of Design Patterns, like on my branch restructure:

|-- Creational
|   |-- Factory
|   |   |-- Tests
|   |-- ...
|-- Behavioral
|   |-- ...
|-- Structural
|   |-- ...

address: http://designpatternsphp.readthedocs.org

| - Q. - | - A. - | | --- | --- | | Tickets | #114 , #115 | | Type | Feature / Documentation | | Techniques | Sphinx + reStructuredText + readthedocs.org | | Participants | @domnikl , @eddiejaoude , @aik099 |

what has changed and will change:

• [x] use Pandoc to convert all the README.md to README.rst in script read-the-docs.sh
• [x] use sphinx tag: literalinclude to embed all related php files in the README.rst of every pattern. in script read-the-docs.sh
• [x] sphinx-quickstart
• [x] create TOC tree (index of projet)
• [x] host on Read the docs
• [x] add Wikipedia link
• [x] bug fix
• [x] reorder php embed files (Top-down)
• [x] revision
• [x] finish and ready to merge

Hello everyone, i found the work in #115 is stop, so i try to continue the work of converting this repo to a documentation/book.

Do you have any suggestions of the version preview?

Translate behavior design patterns into Chinese.

Translation Content:

• [x] 3 Behavior design patterns

  • [x] 3.1 Chain of responsibility
  • [x] 3.2. Command
  • [x] 3.3. Interpreter
  • [x] 3.4. Iterator
  • [x] 3.5. Mediator
  • [x] 3.6. Memento
  • [x] 3.7. Null Object
  • [x] 3.8. Observer
  • [x] 3.9. Specification
  • [x] 3.10. State
  • [x] 3.11. Strategy
  • [x] 3.12. Template Method
  • [x] 3.13. Visitor

The following code doesn't produce the expected output :

<?php
require_once 'Book.php';
require_once 'BookList.php';
require_once 'BookListIterator.php';

use DesignPatterns\Behavioral\Iterator\Book;
use DesignPatterns\Behavioral\Iterator\BookList;
use DesignPatterns\Behavioral\Iterator\BookListIterator;

$list = new BookList();
$list->addBook(new Book('foo', 'bar'));
$list->addBook(new Book('a', '1'));
$list->addBook(new Book('b', '2'));
$list->addBook(new Book('c', '3'));
$list->addBook(new Book('d', '4'));

$list->removeBook(new Book('b', '2'));

$it = new BookListIterator($list);
foreach($it as $i => $b)
    echo $b->getAuthorAndTitle(), PHP_EOL;

The output is :

foo by bar
a by 1

When it should be :

foo by bar
a by 1
c by 3
d by 4

The reason why this happens is that after deleting the "b by 2" book, the internal array of BookList looks like this :

Array
(
    [0] => DesignPatterns\Behavioral\Iterator\Book Object
    (
        [author:DesignPatterns\Behavioral\Iterator\Book:private] => bar
        [title:DesignPatterns\Behavioral\Iterator\Book:private] => foo
    )

    [1] => DesignPatterns\Behavioral\Iterator\Book Object
    (
        [author:DesignPatterns\Behavioral\Iterator\Book:private] => 1
        [title:DesignPatterns\Behavioral\Iterator\Book:private] => a
    )

    [3] => DesignPatterns\Behavioral\Iterator\Book Object
    (
        [author:DesignPatterns\Behavioral\Iterator\Book:private] => 3
        [title:DesignPatterns\Behavioral\Iterator\Book:private] => c
    )

    [4] => DesignPatterns\Behavioral\Iterator\Book Object
    (
        [author:DesignPatterns\Behavioral\Iterator\Book:private] => 4
        [title:DesignPatterns\Behavioral\Iterator\Book:private] => d
    )

)

You'll notice that the index 2 is missing, which makes sense since removeBook calls unset() on that specific book. However, BookListIterator's next() method simply increments the internal index ($currentBook) and BookListIterator::valid() stops when BookList::getBook() returns null, which happens once BookListIterator::currentBook reaches 2, the book we just removed by calling $list->removeBook(new Book('b', '2')). Because of this, the iterator stops prematurely.

I have a thought about Repository pattern. It knows too much about the columns name, if I want to create a Storage for a database where created is a keyword, so the name of this column in this DB is created_at. It will break my Repository implementation. Or even so, if in DB 1 my date is in format YYYY-MM-DD and DB 2 my date is as MM-DD-YYYY, my Repository should not know how to transform the returned string from storage to a DateTime, because the String could vary. What you think?

Update

RendererDecorator.php has this comment but it dosen't implements the interface.

/**
 * the Decorator MUST implement the RendererInterface contract, this is the key-feature
 * of this design pattern. If not, this is no longer a Decorator but just a dumb
 * wrapper.
 */
abstract class RendererDecorator {}

Hi domnikl,

Awesome examples! Learning a lot, thanks. I have a question, why does your composite pattern uses an abstract class in stead of an interface or trait?

Trait example:

trait RenderableTrait
{
   /**
     * renders the elements' code.
     *
     * @param int $indent
     *
     * @return mixed
     */
    abstract public function render($indent = 0);
}

Interface example

interface RenderableInterface
{
   /**
     * renders the elements' code.
     *
     * @param int $indent
     *
     * @return mixed
     */
    public function render($indent = 0);
}

Than you can decouple the From class from the FormElement and add the RenderableTrait or RederableInterface to the Form and FormElement class.

Forgive my possible ignorance, I'm still learning and trying to understand the why of programming decisions.

If you already use SPL interfaces in your example, maybe better to use SplObjectStorage too instead of array to store observers with attach and detach convenient methods? @domnikl What do you think?

How do you feel about adding the Presenter Pattern to this repo? Its similar to the Decorator pattern, but has some key differences. Decorators add new functionality to class instances, whereas Presenters are closer to the view and work directly with the view layer and may contain the language of the view (html/css/etc..). It also contains the ui business logic for the View.

Example code:

class PresentableClass{
  use PresentableTrait;
  protected $presenter = 'ClassPresenter';
}

//Sample class presenter used for this test only
class ClassPresenter extends Presenter{
  public function userName(){
    if($this->email) return $this->email;   
    return "{$this->firstName} $this->lastName";
  }
}

//An example of a presenter trait
<?php namespace App\Presenters;
trait PresentableTrait {
    protected $presenterInstance;

    public function present()
    {
        // Check if the property has been declared on the model and
        // the class exists
        if (!$this->presenter or !class_exists($this->presenter)) {
            throw new Exception('Please set the Presenter path to your Presenter FQN');
        }

        // The good old Singleton pattern
        if (!$this->presenterInstance) {
            $this->presenterInstance = new $this->presenter($this);
        }
        return $this->presenterInstance;
    }
}

<?php
namespace App\Presenters;
abstract class Presenter
{
    protected $entity; // Store the original model instance
    function __construct($entity){
        $this->beforeConstruct();
        $this->entity = $entity;
        $this->afterConstruct();
    }

  // Call the function if exists, or return the property on the original model
    public function __get($property)
    {
        if (method_exists($this, $property)) {
            return $this->{$property}();
        }
        return $this->entity->{$property};
    }
    //optional
    public function beforeConstruct(){}
    public function afterConstruct(){}
}

Some references: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter http://stackoverflow.com/questions/2056/what-are-mvp-and-mvc-and-what-is-the-difference https://github.com/laracasts/Presenter

Thoughts as this might be closer to the singleton pattern (might be an anti-pattern)?

Do NOT merge (yet)

• [x] Vagrant and Ansible

Creational

• [ ] AbstractFactory
• [ ] Builder
• [x] FactoryMethod
• [ ] Multiton
• [ ] Pool
• [x] Prototype
• [ ] SimpleFactory
• [x] Singleton
• [x] StaticFactory

Structural

• [ ] Adapter
• [ ] Bridge
• [ ] Composite
• [ ] DataMapper
• [ ] Decorator
• [ ] DependencyInjection
• [ ] Facade
• [ ] FluentInterface
• [ ] Proxy
• [ ] Registry

Behavioral

• [ ] ChainOfResponsibilities
• [ ] Command
• [ ] Iterator
• [ ] Mediator
• [ ] Memento
• [ ] NullObject
• [ ] Observer
• [ ] Specification
• [ ] State
• [ ] Strategy
• [ ] TemplateMethod
• [ ] Visitor

More

• [ ] Delegation
• [ ] ServiceLocator
• [ ] Repository