From 6ffa3013994a19f715973c63d7f71b55837bb43b Mon Sep 17 00:00:00 2001 From: Vladimir Kovpak Date: Sun, 15 Mar 2015 01:31:17 +0200 Subject: [PATCH 01/11] Add information about SOLID. --- _posts/06-03-01-Complex-Problem.md | 32 ++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) diff --git a/_posts/06-03-01-Complex-Problem.md b/_posts/06-03-01-Complex-Problem.md index 0d6f907..1ab6c12 100644 --- a/_posts/06-03-01-Complex-Problem.md +++ b/_posts/06-03-01-Complex-Problem.md @@ -22,9 +22,37 @@ instead of loosening dependencies, this method simply moved them. Dependency Injection allows us to more elegantly solve this problem by only injecting the dependencies we need, when we need them, without the need for any hard coded dependencies at all. -### Dependency Inversion Principle +### SOLID -Dependency Inversion Principle is the "D" in the S.O.L.I.D set of object oriented design principles that states one +#### Single responsibility principle + +It's very helpful principle because it improve code reusability and +states that every class should have responsibility over a single part of the functionality provided by the software. +Your class should do just one thing and no more. And you can use it in any place of program without changing it. + +#### Open/closed principle + +States that classes should be open for extension, but closed for modification. +it's very important and helpful especially in production, +because it provides ability to change program behaviour without changing source code. + +#### Liskov substitution principle + +This principle extends previous principle, and states +if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S +without altering any class of the program. +That's amazing principle provides ability to build very flexible and easily configurable programs +because when you change one object to another you don't need to change anything in your program. + +#### Interface segregation principle + +Splits interfaces which are very large into smaller and more specific ones. +It provides to work in each time only with methods that interesting for client, +and facilitate conceptual explanation of the code. + +#### Dependency Inversion Principle + +Dependency Inversion Principle set of object oriented design principles that states one should *"Depend on Abstractions. Do not depend on concretions."*. Put simply, this means our dependencies should be interfaces/contracts or abstract classes rather than concrete implementations. We can easily refactor the above example to follow this principle. From d57d2f142f8d48737055228136bdd88f13457bd2 Mon Sep 17 00:00:00 2001 From: Ryan Parman Date: Sun, 4 Oct 2015 12:50:22 -0700 Subject: [PATCH 02/11] Expanded and clarified the language around SOLID principles. --- _posts/06-03-01-Complex-Problem.md | 69 +++++++++++++++++++----------- 1 file changed, 44 insertions(+), 25 deletions(-) diff --git a/_posts/06-03-01-Complex-Problem.md b/_posts/06-03-01-Complex-Problem.md index 1ab6c12..61aecc8 100644 --- a/_posts/06-03-01-Complex-Problem.md +++ b/_posts/06-03-01-Complex-Problem.md @@ -15,47 +15,66 @@ separate from our objects. In terms of Dependency Injection, this means loosenin instantiating them elsewhere in the system. For years, PHP frameworks have been achieving Inversion of Control, however, the question became, which part of control -are you inverting, and where to? For example, MVC frameworks would generally provide a super object or base controller +are we inverting, and where to? For example, MVC frameworks would generally provide a super object or base controller that other controllers must extend to gain access to its dependencies. This **is** Inversion of Control, however, instead of loosening dependencies, this method simply moved them. Dependency Injection allows us to more elegantly solve this problem by only injecting the dependencies we need, when we need them, without the need for any hard coded dependencies at all. -### SOLID +### S.O.L.I.D. -#### Single responsibility principle +#### Single Responsibility Principle -It's very helpful principle because it improve code reusability and -states that every class should have responsibility over a single part of the functionality provided by the software. -Your class should do just one thing and no more. And you can use it in any place of program without changing it. +The Single Responsibility Principle is about actors and high-level architecture. It states that “A class should have +only one reason to change.” This means that every class should _only_ have responsibility over a single part of the +functionality provided by the software. The largest benefit of this approach is that it enables improved code +_reusability_. By designing our class to do just one thing, we can use (or re-use) it in any other program without +changing it. -#### Open/closed principle +#### Open/Closed Principle -States that classes should be open for extension, but closed for modification. -it's very important and helpful especially in production, -because it provides ability to change program behaviour without changing source code. +The Open/Closed Principle is about class design and feature extensions. It states that “Software entities (classes, +modules, functions, etc.) should be open for extension, but closed for modification.” This means that we should design +our modules, classes and functions in a way that when a new functionality is needed, we should not modify our existing +code but rather write new code that will be used by existing code. Practically speaking, this means that we should write +classes that implement and adhere to _interfaces_, then type-hint against those interfaces instead of specific classes. -#### Liskov substitution principle +The largest benefit of this approach is that we can very easily extend our code with support for something new without +having to modify existing code, meaning that we can reduce QA time, and the risk for negative impact to the application +is substantially reduced. We can deploy new code, faster, and with more confidence. -This principle extends previous principle, and states -if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S -without altering any class of the program. -That's amazing principle provides ability to build very flexible and easily configurable programs -because when you change one object to another you don't need to change anything in your program. +#### Liskov Substitution Principle -#### Interface segregation principle +The Liskov Substitution Principle is about subtyping and inheritance. It states that “Child classes should never break +the parent class’ type definitions.” Or, in Robert C. Martin’s words, “Subtypes must be substitutable for their base +types.” -Splits interfaces which are very large into smaller and more specific ones. -It provides to work in each time only with methods that interesting for client, -and facilitate conceptual explanation of the code. +For example, if we have a `FileInterface` interface which defines an `embed()` method, and we have `Audio` and `Video` +classes which both implement the `embed()` method, then we can expect that the usage of the `embed()` method will always +do the thing that we intend. If we later create a `PDF` class or a `Gist` class which implement the `FileInterface` +interface, we will already know and understand what the `embed()` method will do. The largest benefit of this approach +is that we have the ability to build flexible and easily-configurable programs, because when we change one object of a +type (e.g., `FileInterface`) to another we don't need to change anything else in our program. + +#### Interface Segregation Principle + +The Interface Segregation Principle (ISP) is about _business-logic-to-clients_ communication. It states that “No client +should be forced to depend on methods it does not use.” This means that instead of having a single monolithic interface +that all conforming classes need to implement, we should instead provide a set of smaller, concept-specific interfaces +that a conforming class implements one or more of. + +For example, a `Car` or `Bus` class would be interested in a `steeringWheel()` method, but a `Motorcycle` or `Tricycle` +class would not. Conversely, a `Motorcycle` or `Tricycle` class would be interested in a `handlebars()` method, but a +`Car` or `Bus` class would not. There is no need to have all of these types of vehicles implement support for both +`steeringWheel()` as well as `handlebars()`, so we should break-apart the source interface. #### Dependency Inversion Principle -Dependency Inversion Principle set of object oriented design principles that states one -should *"Depend on Abstractions. Do not depend on concretions."*. Put simply, this means our dependencies should be -interfaces/contracts or abstract classes rather than concrete implementations. We can easily refactor the above example -to follow this principle. +The Dependency Inversion Principle is about removing hard-links between discrete classes so that new functionality can +be leveraged by passing a different class. It states that one should *"Depend on Abstractions. Do not depend on +concretions."*. Put simply, this means our dependencies should be interfaces/contracts or abstract classes rather than +concrete implementations. We can easily refactor the above example to follow this principle. {% highlight php %} Date: Wed, 30 Nov 2016 00:23:58 +0000 Subject: [PATCH 03/11] Add php-mock and humbug --- _posts/11-04-01-Complementary-Testing-Tools.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/_posts/11-04-01-Complementary-Testing-Tools.md b/_posts/11-04-01-Complementary-Testing-Tools.md index e0af3a4..b7ed173 100644 --- a/_posts/11-04-01-Complementary-Testing-Tools.md +++ b/_posts/11-04-01-Complementary-Testing-Tools.md @@ -14,6 +14,8 @@ libraries useful for any preferred approach taken. * [Mockery] is a Mock Object Framework which can be integrated with [PHPUnit] or [PHPSpec] * [Prophecy] is a highly opinionated yet very powerful and flexible PHP object mocking framework. It's integrated with [PHPSpec] and can be used with [PHPUnit]. +* [php-mock] is a library to help to mock PHP native functions. +* [Humbug] is a PHP implementation of [Mutation Testing] to help to measure the effectiveness of your tests. [Selenium]: http://seleniumhq.org/ @@ -22,3 +24,6 @@ libraries useful for any preferred approach taken. [PHPUnit]: http://phpunit.de/ [PHPSpec]: http://www.phpspec.net/ [Prophecy]: https://github.com/phpspec/prophecy +[php-mock]: https://github.com/php-mock/php-mock +[Humbug]: https://github.com/padraic/humbug +[Mutation Testing]: https://en.wikipedia.org/wiki/Mutation_testing From 5cad0d04c671edf41d3a3a2c74f871b066a012d1 Mon Sep 17 00:00:00 2001 From: "Paul M. Jones" Date: Tue, 31 Jan 2017 10:52:47 -0600 Subject: [PATCH 04/11] add aura/intl --- _posts/05-06-01-Internationalization-and-Localization.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/_posts/05-06-01-Internationalization-and-Localization.md b/_posts/05-06-01-Internationalization-and-Localization.md index 7b38284..5bec5d9 100644 --- a/_posts/05-06-01-Internationalization-and-Localization.md +++ b/_posts/05-06-01-Internationalization-and-Localization.md @@ -41,6 +41,9 @@ There are common libraries used that support Gettext and other implementations o install or sport additional features or i18n file formats. In this document, we focus on the tools provided with the PHP core, but here we list others for completion: +- [aura/intl][aura-intl]: Provides internationalization (I18N) tools, specifically package-oriented per-locale message +translation. It uses array formats for message. Does not provide a message extractor, but does provide advanced +message formatting via the `intl` extension (including pluralized messages). - [oscarotero/Gettext][oscarotero]: Gettext support with an OO interface; includes improved helper functions, powerful extractors for several file formats (some of them not supported natively by the `gettext` command), and can also export to other formats besides `.mo/.po` files. Can be useful if you need to integrate your translation files into other parts @@ -400,6 +403,7 @@ After including those new rules in the `.po` file, a new scan will bring in your [3166-1]: http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2 [rare]: http://www.gnu.org/software/gettext/manual/gettext.html#Rare-Language-Codes [func_format]: https://www.gnu.org/software/gettext/manual/gettext.html#Language-specific-options +[aura-intl]: https://github.com/auraphp/Aura.Intl [oscarotero]: https://github.com/oscarotero/Gettext [symfony]: https://symfony.com/doc/current/components/translation.html [zend]: https://docs.zendframework.com/zend-i18n/translation From b55a190df016ef4fdae96be9bb1c515de9e07b73 Mon Sep 17 00:00:00 2001 From: marijaninjo Date: Mon, 15 May 2017 01:05:29 +0200 Subject: [PATCH 05/11] Example code consistency Added surrounding
  • tags just to be consistent with code examples at line 16 and 37 --- _posts/07-04-01-Interacting-via-Code.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/07-04-01-Interacting-via-Code.md b/_posts/07-04-01-Interacting-via-Code.md index 5cae4f0..3004664 100644 --- a/_posts/07-04-01-Interacting-via-Code.md +++ b/_posts/07-04-01-Interacting-via-Code.md @@ -86,7 +86,7 @@ class FooModel {% highlight php %} - - +
  • -
    • {% endhighlight %} From 88329152a7ab7b2f19546fb4b9bdba2e7869849f Mon Sep 17 00:00:00 2001 From: Eric Poe Date: Fri, 7 Jul 2017 01:49:22 -0500 Subject: [PATCH 06/11] Add information about the common directory structure used for php dev work This information is based on the great analysis done by Paul M. Jones. --- _posts/01-06-01-Common-Directory-Structure.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 _posts/01-06-01-Common-Directory-Structure.md diff --git a/_posts/01-06-01-Common-Directory-Structure.md b/_posts/01-06-01-Common-Directory-Structure.md new file mode 100644 index 0000000..69a16f9 --- /dev/null +++ b/_posts/01-06-01-Common-Directory-Structure.md @@ -0,0 +1,19 @@ +--- +title: Common Directory Structure +isChild: true +anchor: common_directory_structure +--- + +## Common Directory structure {#common_directory_structure_title} + +A common question among those starting out with writing programs for the web is, "where do I put my stuff?" Over the years, this answer has consistently been "where the `DocumentRoot` is." Although this answer is not complete, it's a great place to start. + +For security reasons, configuration files should not be accessible by a site's visitors; therefore, public scripts are kept in a public directory and private configurations and data are kept outside of that directory. + +For each team, CMS, or framework one works in, a standard directory structure is used by each of those entities. However, if one is starting a project alone, knowing which filesystem structure to use can be daunting. + +[Paul M. Jones] has done some fantastic research into common practices of tens of thousands of github projects in the realm of PHP. He has compiled a standard file and directory structure, the [Standard PHP Package Skeleton], based on this research. In this directory structure, `DocumentRoot` should point to `public/`, unit tests should be in the `tests/` directory, and third party libraries, as installed by [composer], belong in the `vendor/` directory. For other files and directories, abiding by the [Standard PHP Package Skeleton] will make the most sense to contributors of a project. + +[Paul M. Jones]: https://twitter.com/pmjones +[Standard PHP Package Skeleton]: https://github.com/php-pds/skeleton +[Composer]: /#composer_and_packagist From 1a62ece55b19d2bf70beb5e4c1424c2feb3c6706 Mon Sep 17 00:00:00 2001 From: NJ Date: Wed, 7 Feb 2018 15:17:50 -0800 Subject: [PATCH 07/11] Use utf8mb4 instead of utf8 in MySQL database connection string --- _posts/07-04-01-Interacting-via-Code.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/_posts/07-04-01-Interacting-via-Code.md b/_posts/07-04-01-Interacting-via-Code.md index 5cae4f0..8f7d2b3 100644 --- a/_posts/07-04-01-Interacting-via-Code.md +++ b/_posts/07-04-01-Interacting-via-Code.md @@ -48,7 +48,7 @@ logic in and you have a "View", which is very nearly [MVC] - a common OOP archit {% highlight php %} Date: Thu, 5 Apr 2018 01:51:16 +0530 Subject: [PATCH 08/11] Add CakePHP's standalone packages/components --- _posts/16-07-01-Components.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/_posts/16-07-01-Components.md b/_posts/16-07-01-Components.md index c614d9b..616ea7d 100644 --- a/_posts/16-07-01-Components.md +++ b/_posts/16-07-01-Components.md @@ -20,6 +20,13 @@ another source of packages which ideally have little to no dependencies on other For example, you can use the [FuelPHP Validation package], without needing to use the FuelPHP framework itself. * [Aura] +* CakePHP Components + * [Collection] + * [Database] + * [Datasource] + * [Event] + * [I18n] + * [ORM] * [FuelPHP] * [Hoa Project] * [Orno] @@ -48,3 +55,9 @@ components best decoupled from the Laravel framework are listed above._ [Eloquent ORM]: https://github.com/illuminate/database [Queue]: https://github.com/illuminate/queue [Illuminate components]: https://github.com/illuminate +[Collection]: https://github.com/cakephp/collection +[Database]: https://github.com/cakephp/database +[Datasource]: https://github.com/cakephp/datasource +[Event]: https://github.com/cakephp/event +[I18n]: https://github.com/cakephp/i18n +[ORM]: https://github.com/cakephp/orm From 131843b5b2e3fe4f938915ed958de7305ae7e314 Mon Sep 17 00:00:00 2001 From: "Brian A. Weston" Date: Thu, 19 Apr 2018 14:19:14 -0700 Subject: [PATCH 09/11] Update Gettext introduction phrasing --- _posts/05-06-01-Internationalization-and-Localization.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/_posts/05-06-01-Internationalization-and-Localization.md b/_posts/05-06-01-Internationalization-and-Localization.md index 7e53a5d..9c36dec 100644 --- a/_posts/05-06-01-Internationalization-and-Localization.md +++ b/_posts/05-06-01-Internationalization-and-Localization.md @@ -31,9 +31,9 @@ don't try this if your project will contain more than a couple of pages. The most classic way and often taken as reference for i18n and l10n is a [Unix tool called `gettext`][gettext]. It dates back to 1995 and is still a complete implementation for translating software. It is pretty easy to get running, while -it still sports powerful supporting tools. It's about Gettext we will be talking here. Also, to help you not get messy -over the command-line, we will be presenting a great GUI application that can be used to easily update your l10n source -files. +it still sports powerful supporting tools. We will talk about Gettext in more detail below. If you would prefer to not +have to get your hands dirty with the command line, we will also be presenting a great GUI application that can be used +to easily update your l10n source files. ### Other tools From a1f8e83a3fd9403fec685dfa9cf871bf6c529797 Mon Sep 17 00:00:00 2001 From: Christopher Date: Fri, 1 Jun 2018 16:01:11 +0100 Subject: [PATCH 10/11] Using php 7 feature in example --- _posts/09-02-01-Errors.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/_posts/09-02-01-Errors.md b/_posts/09-02-01-Errors.md index c510a70..66befbd 100644 --- a/_posts/09-02-01-Errors.md +++ b/_posts/09-02-01-Errors.md @@ -87,7 +87,8 @@ rewritten like this: {% highlight php %} Date: Mon, 11 Jun 2018 11:43:22 +0100 Subject: [PATCH 11/11] Change Humbug for Infection --- _posts/11-04-01-Complementary-Testing-Tools.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/_posts/11-04-01-Complementary-Testing-Tools.md b/_posts/11-04-01-Complementary-Testing-Tools.md index b7ed173..b797647 100644 --- a/_posts/11-04-01-Complementary-Testing-Tools.md +++ b/_posts/11-04-01-Complementary-Testing-Tools.md @@ -15,7 +15,7 @@ libraries useful for any preferred approach taken. * [Prophecy] is a highly opinionated yet very powerful and flexible PHP object mocking framework. It's integrated with [PHPSpec] and can be used with [PHPUnit]. * [php-mock] is a library to help to mock PHP native functions. -* [Humbug] is a PHP implementation of [Mutation Testing] to help to measure the effectiveness of your tests. +* [Infection] is a PHP implementation of [Mutation Testing] to help to measure the effectiveness of your tests. [Selenium]: http://seleniumhq.org/ @@ -25,5 +25,5 @@ libraries useful for any preferred approach taken. [PHPSpec]: http://www.phpspec.net/ [Prophecy]: https://github.com/phpspec/prophecy [php-mock]: https://github.com/php-mock/php-mock -[Humbug]: https://github.com/padraic/humbug +[Infection]: https://github.com/infection/infection [Mutation Testing]: https://en.wikipedia.org/wiki/Mutation_testing