Skip to content

Instantly share code, notes, and snippets.

View dimabory's full-sized avatar
💭
🦁

Dmytro Borysovskyi dimabory

💭
🦁
View GitHub Profile
@dimabory
dimabory / 01-overview.md
Last active September 5, 2022 08:33
coupling, cohesion, encapsulation

http://wiki.c2.com/?CouplingAndCohesion

Low Coupling

Coupling refers to the relationship of a module with another module. A module is said to be highly coupled with another module if changes to it will result to changes to the other module. And a module is said to be loosely coupled if a module is independent of any other modules. This can be achieved by having a stable interface that effectively hides the implementation of another module.

Benefits of low coupling are

  • maintainability – changes are confined in a single module
  • testability – modules involved in unit testing can be limited to a minimum
@dimabory
dimabory / solid.md
Last active February 1, 2019 13:30
Principles Of Object Oriented Design http://wiki.c2.com/?PrinciplesOfObjectOrientedDesign
(SRP) The SingleResponsibilityPrinciple
(OCP) The OpenClosedPrinciple
(LSP) The LiskovSubstitutionPrinciple
(ISP) The InterfaceSegregationPrinciple
(DIP) The DependencyInversionPrinciple
There are three principles of package cohesion
(REP) The ReuseReleaseEquivalencePrinciple
(CCP) The CommonClosurePrinciple
(CRP) The CommonReusePrinciple
@dimabory
dimabory / screaming_architectur.md
Last active January 28, 2019 10:42
system design

To design well decoupled components, it helps to reflect about: “if I would want to remove this business concept, by deleting its component root folder would all of the business concept code be removed and would the remaining application not break?” If the answer is yes, then we have a well decoupled component.

For example, in a Command Bus architecture the command and the handler do not work one without the other, they are conceptually and functionally bound together, so if we would need to remove that logic, we would remove them both, and if they are in the same place, we just remove one folder (the problem we are trying to solve is not about deleting code, it’s about having decoupled and cohesive code, but it helps to think in these terms). So to follow the CCP and the CRP, a command should be in the same folder as its handler.

@dimabory
dimabory / 1.php
Last active January 30, 2019 10:23
return true
<?php
function foo($x)
{
return $x === $x();
}
@dimabory
dimabory / 14.php
Created November 6, 2018 17:08
pikabu interview
<?php
/*
14. Напишите, пожалуйста, код для сортировки массива $arr по полю id. Структура массива:
$arr = [
['id' => 1, ...],
['id' => 2, ...],
['id' => 3, ...],
...
];
*/
@dimabory
dimabory / deepClone.js
Last active November 6, 2018 09:18
The best algorithm for copying objects in Javascript is heavily dependent on the context and type of objects that you are looking to copy
/*
* 1.
* objects with properties which are themselves objects, only the references are copied over:
* var foo = { a: 0 , b: { c: 0 } };
* var copy = { ...foo };
*/
var obj = { foo: "foo", bar: "bar" };
var copy = { ...obj };
var copy = Object.assign({}, obj);
@dimabory
dimabory / Bidirectional Associations.md
Last active May 15, 2018 10:18
Bidirectional Associations (DOCTRINE)
  • The inverse side has to have the mappedBy attribute of the OneToOne, OneToMany, or ManyToMany mapping declaration.

  • The mappedBy attribute contains the name of the association-field on the owning side.

  • The owning side has to have the inversedBy attribute of the OneToOne, ManyToOne, or ManyToMany mapping declaration.

  • The inversedBy attribute contains the name of the association-field on the inverse-side.

  • ManyToOne is always the owning side of a bidirectional association.

  • OneToMany is always the inverse side of a bidirectional association.

  • The owning side of a OneToOne association is the entity with the table containing the foreign key.

  • You can pick the owning side of a many-to-many association yourself.

@dimabory
dimabory / Тестирование.md
Created April 18, 2018 15:55 — forked from codedokode/Тестирование.md
Автоматизированное тестирование

Автоматизированное тестирование

Если ты пишешь код, то наверняка его тестируешь. Если речь о какой-то функции, то ты можешь вызывать ее с разными аргументами, и смотреть, что она вернет. Если ты сверстал сайт, то ты открываешь его в браузере, жмешь ссылки и кнопки, проверяешь что все сделано верно. Это называется ручное тестирование — человек проверяет работу программы. Нельзя ли эту задачу переложить на плечи роботов? Обычно можно, и это называется автоматизированное тестирование.

Тестирование позволяет сделать твой код надежнее, а твою жизнь проще. Ведь согласись, лучше когда ты сам обнаруживаешь и исправляешь ошибку до релиза, чем когда рассерженный заказчик звонит на выходных и требует срочно исправить неработающий функционал.

Тестирование особенно полезно при разработке больших приложений в большой команде, когда ты можешь нечаянно сломать какую-то функцию, которую делал другой человек, и о которой ты не знал. Или когда надо доработать написанный ранее сложный проект.

В больших компаниях может быт

@dimabory
dimabory / .gitlab-ci.sh
Created April 12, 2018 15:17 — forked from RomainMarecat/.gitlab-ci.sh
Simple gitlab-ci configuration symfony
#!/bin/bash
# Install dependencies only for Docker.
[[ ! -e /.dockerinit ]] && exit 0
set -xe
# Update packages and install composer and PHP dependencies.
apt-get update -yqq
apt-get install git libcurl4-gnutls-dev libicu-dev libmcrypt-dev libvpx-dev libjpeg-dev libpng-dev libxpm-dev zlib1g-dev libfreetype6-dev libxml2-dev libexpat1-dev libbz2-dev libgmp3-dev libldap2-dev unixodbc-dev libpq-dev libsqlite3-dev libaspell-dev libsnmp-dev libpcre3-dev libtidy-dev phpunit -yqq