Принцип единственной обязанности (SPR, Single Responsibility Principle)

Принцип единственной обязанности (SPR, Single Responsibility Principle)

Принцип единственной обязанности обозначает, что каждый объект должен иметь одну обязанность и эта обязанность должна быть полностью инкапсулированна в классе.

Связность (cohesion) —  характеристика внутренней взаимосвязи между частями одного модуля.

Связанность (coupling) — степень, в которой программный модуль зависит от других модулей.

Нужно стремиться к слабой связанности и сильной связности модулей.

• Изменения в требованиях обычно влекут за собой изменение обязанностей
• Чем больше обязанностей у класса — тем больше вероятность его изменения
• Несколько обязанностей в пределах одного класса делают эти обязанности взаимозависимыми
• Чем больше классов затронет изменение, тем больше вероятность появления ошибок

«Разработчик состоит из четырех компонентов: тело, сердце, разум и душа.

1. Телу необходимы деньги и безопасность.
2. Сердцу — любовь и признание. 
3. Разуму — развитие и самосовершенствование. 
4. Душе — самореализация».

С. Архипенков

Принципы объектно-ориентированного проектирования

Первые пять принципов описывают дизайн классов (SOLID)

SRP	Принцип единственной обязанности	На каждый объект должна быть возложена одна обязанность.
OCP	Принцип открытости/закрытости	Сущности должны быть открыты для расширения, но закрыты для изменения.
LSP	Принцип подстановки Барбары Лисков	Объекты в программе могут быть заменены их наследниками без изменения свойств программы.
ISP	Принцип разделения интерфейсов	Много специализированных изменений лучше, чем один универсальный.
DIP	Принцип инверсии зависимостей	Зависимости внутри системы строятся на основе абстракций. Модули верхнего уровня не зависят от модулей нижнего уровня. Абстракции не должны зависеть от деталий. Детали должны зависеть от абстракций.

Следующие 6 принципов касаются сборок (.jar или .dll)

Первые 3 принципа описывают содержание сборки.

REP	Принцип эквивалентности повторного использования и выпуска	Единица повторного использования равна единице выпуска.
CCP	Принцип общей закрытости	Все классы внутри пакета должны быть закрыты относительно изменений одного и того же вида. Изменение, затрагивающее пакет, должно затрагивать все классы в этом пакете и только в нем.
CRP	Принцип совместного повторного использования	Все классы внутри компонента используются совместно. Если вы можете повторно использовать один класс, то можете использовать и все остальные.

Следующие 3 принципа описывают связи между сборками.

ADD	Принцип ацикличности зависимостей	В графе зависимостей между пакетами не должно быть циклов.
SDP	Принцип устойчивых зависимостей	Зависимости должны быть направлены в сторону устойчивости.
SAP	Принцип устойчивых абстракций	Пакет должен быть столь же абстрактным, сколь и устойчивым.

Закон Амдала (Amdahl's law)

Общаясь с коллегой на тему паралленьного программирования и многопоточности, мы затронули вопрос о производительности большоко количества потоков. Я с удивлением узнал, что много программистов не знает Закона Амдала, который иллюстрирует ограничение роста с увеличением вычислителей.

Приведу сам закон:

«В случае, когда задача разделяется на несколько частей, суммарное время её выполнения на параллельной системе не может быть меньше времени выполнения самого длинного фрагмента».

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

Но самое главное вывод, который можно сделать из Закона Амдала:
С определенного момента добавление новых узлов (потоков, процессов) будет увеличивать время расчета задачи.

Проиллюстрирую это на графике:

Закон Деметры (Law of Demeter, LoD — Закон наименьшего знания )

Закон Деметры — одно из правил ООД, помогающее добиться ослабления связанности кода. Он был сформулирован в 1987 году в Бостоне и в простейшем виде может быть сформулирован так: «Используй только одну точку».

Закон накладывает следующие требования на каждый программный модуль:

• должен обладать ограниченным знанием о других модулях
• должен взаимодействовать только с известными ему модулями — «друзьями» и не взаимодействовать с незнакомцами
• обращаться только к непосредственным «друзьям»

Для ООП Закон Деметры может быть сформулирован так: Объект A не должен иметь возможность получить непосредственный доступ к объекту C, если у объекта A есть доступ к объекту B и у объекта B есть доступ к объекту C.

Для функций, Закон Деметры требует, что метод М объекта О должен вызывать методы только следующих типов объектов:

• собственно самого О
• параметров М
• других объектов, созданных в рамках М
• прямых компонентных объектов О
• глобальных переменных, доступных О, в пределах М

Каждый лишний шаг и каждое дополнительное усилие, требуемое для выполнения той или иной задачи, — верные признаки непривлекательного продукта.

От идеи к продукту

Путь от идеи к продукту:

• определение проблемы (ЗАЧЕМ )
• поиск подходящего решения (ЧТО) 
• реализация (КАК)

Подсмотрел тут: http://maxua.com/post/20834631249

Шесть принципов при создании новых вещей

Находить (а) простые решения (б) к никем не замеченным проблемам (в) которые действительно нужно решать (г) предоставляя решения в максимально свободном стиле (д) начиная с сырой версии 1 (е) и постоянно совершенствуя ее.

Коэффициенты работы с клиентами

CAC (Customer Acquisition Cost) — Стоимость привлечения одного клиента: это общий объем расходов на продажи и издержки по сбыту (зарплаты, программы и т.д.) за определенный период времени (например, месяц), поделенный на количество клиентов, приобретенных в этом месяце.

Cancellation Rate / Churn Rate — Коэффициент оттока клиентов: процентное соотношение количества покупателей, отказавшихся от услуг компании по отношению к количеству покупателей в начале месяца.

LTV (Lifetime Value of a customer) —  Продолжительность «жизни» и ценность клиента: основывается на том, как долго клиент будет оставаться клиентом именно вашей компании (коэффициент оттока) и средней выручке.

Денежные потоки

Типы денежных потоков:

• CF–O (Операционный) - денежный поток от основной деятельности
• CF–I (Инвестиционный) -денежный поток от купли-продажи долгосрочных активов
• CF–F (Финансовый) - денежный поток от инвестиционной и кредитной деятельности

Способы построения денежного потока:

• прямой
• CF–O = +/– Изменения в рабочем капитале +/– Изменения в амортизации + Льготы по налогу на прибыль
• CF–I = +/– Изменения в счетах долгосрочных активов
• CF–F = +/– Изменения в счетах акционерного капитала +/– Изменения в долгосрочных долговых счетах – Выплаты дивидендов
• косвенный
• CF–O = + Поступления от продаж – Платежи контрагентам (поставщикам, аренда, реклама, юристы и пр.) – Зарплата и соцвыплаты сотрудников – Платежи в социальные фонды – Налоги на основную деятельность (НДС, на прибыль и пр.)
• CF–I = + Выручка от продажи долгосрочного имущества – Расходы на покупку долгосрочного имущества – Налог на имущество
• CF–F = +/– Продажа-купля ценных бумаг +/– Полученные и возвращенные кредиты – Выплаты дивидендов