From 93701f08e01f1474180848878b07da145294f5b0 Mon Sep 17 00:00:00 2001 From: Andrey Kapitonov Date: Mon, 11 May 2020 12:38:56 +0300 Subject: [PATCH] Change readme --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 414f2ae..34df55a 100644 --- a/README.md +++ b/README.md @@ -2,7 +2,7 @@ ## SOLID -За этой аббревиатурой скрываются 5 базовых принципов ООП, предложенные Робертом Мартином в его статье [«Принципы проектирования и шаблоны проектирования»](https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf). Следование их духу сделает код легко тестируемым, расширяемым, читаемым и поддерживаемым. +За этой аббревиатурой скрываются 5 базовых принципов ООП, предложенные __Робертом Мартином__ в его статье [«Принципы проектирования и шаблоны проектирования»](https://web.archive.org/web/20150906155800/http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf). Следование их духу сделает код легко тестируемым, расширяемым, читаемым и поддерживаемым. Вот шпаргалка по этим принципам: @@ -12,21 +12,21 @@ - (__I__) Interface Segregation Principle (принцип разделения интерфейса) - (__D__) Dependency Inversion Principle (принцип инверсии зависимостей) -По словам Роберта С. Мартина, симптомы гниющего дизайна или плохого кода: +По словам __Роберта С. Мартина__, симптомы гниющего дизайна или плохого кода: -- Жесткость (трудно менять код, так как простое изменение затрагивает много мест); -- Неподвижность (сложно разделить код на модули, которые можно использовать в других программах); -- Вязкость (разрабатывать и/или тестировать код довольно тяжело); -- Ненужная Сложность (в коде есть неиспользуемый функционал); -- Ненужная Повторяемость (Copy/Paste); -- Плохая Читабельность (трудно понять что код делает, трудно его поддерживать); -- Хрупкость (легко поломать функционал даже небольшими изменениями); +- __Жесткость__ (трудно менять код, так как простое изменение затрагивает много мест); +- __Неподвижность__ (сложно разделить код на модули, которые можно использовать в других программах); +- __Вязкость__ (разрабатывать и/или тестировать код довольно тяжело); +- __Ненужная Сложность__ (в коде есть неиспользуемый функционал); +- __Ненужная Повторяемость__ (Copy/Paste); +- __Плохая Читабельность__ (трудно понять что код делает, трудно его поддерживать); +- __Хрупкость__ (легко поломать функционал даже небольшими изменениями); Но это улучшение, теперь мы можем сказать что то вроде "мне не нравится это потому, что слишком сложно модифицировать", или "мне не нравится это потому, что я не могу сказать, что этот код пытается сделать", но что насчет того, чтобы вести обсуждение позитивно? Разве это не было бы здорово, если бы существовал способ описать свойства хорошего дизайна, а не только плохого и иметь возможность рассуждать объективными терминами? Для этого нам на помощь спешат принципы проектирования архитектуры и написания программного кода. -Сейчас мы рассмотрим эти принципы на схематичных примерах. Обратите внимание на то, что главная цель примеров заключается в том, чтобы помочь читателю понять принципы SOLID, узнать, как их применять и как следовать им, проектируя приложения. Автор материала не стремился к тому, чтобы выйти на работающий код, который можно было бы использовать в реальных проектах. +Сейчас мы рассмотрим эти принципы на схематичных примерах. Обратите внимание на то, что главная цель примеров заключается в том, чтобы помочь читателю понять принципы __SOLID__, узнать, как их применять и как следовать им, проектируя приложения. Автор материала не стремился к тому, чтобы выйти на работающий код, который можно было бы использовать в реальных проектах. В golang в качестве отдельных частей у нас есть - пакаджи, структуры, методы и интерфейсы. Давайте расссмотрим SOLID в этих терминах.