​Модульность в Python.

Есть несколько видов импортов, которые вы можете использовать. Самые простые - импорты стандартных и установленных библиотек, например:

import Flask 
from random import randint

С этими импортами многие знакомы, останавливаться на них не будем.

При работе над большим проектом ваша кодовая база очень быстро разрастается. Чтобы оформить качественную декомпозицию, оформить зоны ответственности и упростить проект в целом можно разбить проект на несколько компонентов (структура проекта на приложенной картинке и на github).

Чтобы импортировать файл из той же папки, в которой находится исполняемый файл, можно использовать уже знакомую конструкцию. Допустим, рядом есть файл config.py, куда вынесены все константы. Импортировать его можно так:
import config

Также рядом с исполняемым файлом вы можете создать папку, куда вложите config.py. Такой файл можно импортировать вот так:
from folder import utils

Из вложенной в папку папки (какое странно выражение) импортируем так:
from folder.folder2 import utils2

Также вы можете создать собственный независимый проект, чтобы переиспользовать его где-то ещё. Для этого рядом с главным файлом мы создадим папку package с файлами __init__.py и functions.py.
Содержание файла __init__.py:

from package.functions import sayHello

def init():
    print('Инициализировано')

Содержание файла functions.py:

def sayHello():
    print('hello')

Теперь в главном файле просто импортируем наш package, с такой структурой нам будут доступны все вложенные функции.

Тема сложнее, чем можно рассмотреть в одном моём посте, так что заинтересовавшиеся погуглят ещё, надеюсь. Мой тестовый проект доступен на github. Хранит вас бог.

#python

​О переменных окружения.

Я думаю, что ни для кого не секрет, что секретные токены и данные лучше всего получать в своей программе именно из переменных окружения. Если кто не понимает почему это правильно, то объясняю:

Как можно хранить секретные ключи и переменные:
1. Просто в коде.
Заранее провальный метод, все ключи просто видно.

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

3. В переменных окружения.
Это достаточно унифицированный для всех проектов и программистов способ, а это очень ценится. Очень удобно работать и вот это вот всё.

В общем, об этом много где говорят, даже я использовал это вот в этом посте, но почему-то конкретные вещи никто не раскрывает. В этом посте ответ сразу на 2 вопроса:

1. Как установить переменную окружения?
Нагуглить ответ на этот вопрос крайне просто, если вы пользуетесь UNIX системами (linux/macos и т.д.), но как мы все знает, консоль windows отвратительна. А ещё windows используют всё же большинство, так что поговорим именно о нём.

Чтобы установить переменную окружения в windows необходимо написать следующую команду в консоли:
set VARIABLE_NAME=value

Команда же set выведет в консоль все переменные окружения.

2. Как получить уже установленную переменную окружения?
Всё проще, чем кажется. За это отвечает встроенный модуль os. Получить переменную можно так:

import os 

TOKEN = os.getenv('TOKEN')

На этом всё, это действительно так просто.

Используйте переменные среды, следите за безопасностью,ну и любите и будьте любимы.

#python #useful

​Форматирование строк и что такое интерполяция.

Так, раз уж у меня такое вдохновение пописать про Python, то я не вижу смысла останавливаться. Сегодня расскажу вам про возможные варианты форматирования строк, об их различиях и так далее.

Для удобства давайте обозначим изначальные данные:
name = "Денис"
age = 19

В результате ожидаем строку: "Привет, я Денис, мне 19 лет."

Чтож, начнём с самого простого способа форматирования - это обычная конкатенация. Кто не знал, во многих языках можно складывать строки при помощи оператора "+". В таком случае нужную строку получим так:
result = "Привет, я " + name + ", мне " + age + " лет."

Второй возможный способ - процентное форматирование. Достаточно старый метод, который появился уже давно, и в нашем случае нужную строку мы получили бы так:
result = "Привет, я %s, мне %d лет." % (name, age)

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

Третий способ - с использованием метода строки format()
Классный метод, но не наглядный, когда в строку нужно вставить, ну, например, 20 переменных. В нашем случае результат будет выглядеть так:
result = "Привет, я {}, мне {} лет.".format(name, age)

Обращу ваше внимание на то, что можно аргументы задавать не позиционно, а именовано, то есть:
result = "Привет, я {name}, мне {age} лет.".format(age=age, name=name)

Тут мы аргументы подаём не в том порядке, но всё отлично работает.

Ну и наконец самый любимый мной да и всеми, надеюсь, способ - это f-строки, или же интерполяция. Интерполяция - это подмена шаблона в строке на какую-то переменную, если своими словами. На практике это выглядит так:
result = f"Привет, я {name}, мне {age} лет."

Чем-то напоминает именованный способ из прошлого примера, но без грязной конструкции после строки. Но более того, этот метод крайне функционален, ведь внутри себя он поддерживает различные операции и вызовы функций. То есть запись типа:
result = f"Привет, я {name.upper()}, мне {_getAge(name)} лет."

Вполне нормально считается и выдаст нужный результат.

Ну хорошо, даже отлично. Но как вы думаете, какой вариант справляется эффективнее по времени? Достаточно нетривиальный вопрос, на который мы с товарищем недавно спорили больше получаса. График вы можете увидеть на прикрепленной к посту фотографии.

Спасибо за прочтение, это важно для меня ❤️

​Что такое .gitkeep файл.

.gitkeep обычно пуст и этот файл нужен для сохранения файловой структуры проекта. Система git не добавляет в учёт пустые папки. Если вы хотите добавить пустую папку в структуру своего проекта, вы должны поместить туда хотя бы один файл. Он может иметь абсолютно любое имя, но .gitkeep - это неформальное соглашение между программистами об именовании подобных файлов.

#useful

​Что такое ifmain конструкция в Python.

Начнём с того, что конструкция выглядит так:

if __name__ == "__main__":
    do_somethink()

Здесь __name__ - это "магическая" переменная, содержащая внутри себя название файла, откуда выполняется какая-то функция или операция. Допустим, что у нас есть 2 файла: main.py и file.py.
Внутри файла file.py имеем код:

def foo():
    print(f"А я {__name__}")

В файле main.py реализуем такой код:

import file

print(f"Я {__name__}")
file.foo()

Тогда получим вывод:

>>> Я __main__
>>> А я file.py

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

Если в файле file.py мы так же добавим:

if __name__ == "__main__":
    print("Привет из условия file.py")

То данный принт мы не увидим, потому что главным файлом в цепочке является файл main.py, а переменная __name__ у файла file.py равна "file.py".

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

#python

​Тернарный оператор в Python.

Есть такая полезная штука во многих языках программирования, как тернарный оператор. Чтобы понять пользу всей этой конструкции давайте рассмотрим такую задачу:
У нас есть переменная num, в которую пользователь положит число. Если num ≥ 0, то в консоль выведем "Положительное либо ноль", а иначе выведем "Отрицательное".

Реализуем код:

num = int(input())

if num >= 0:
    print("Положительное либо ноль") 
else:
    print("Отрицательное")

С помощью тернарного оператора имплементация решения этой же задачи выглядит так:

num = int(input())

print("Положительное либо ноль" if num >= 0 else "Отрицательное")

По моему решение выглядит очень лаконично. Более удачный тут пример - функция, возвращающая модуль числа. Обычно ее записывают вот так:

def abs(num):
    if num >= 0:
        return num
    return -num

Но с тернарным оператором она будет выглядеть вот так:

def abs(num):
    return num if num >= 0 else -num

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

Спасибо за прочтение ❤️

#python

Ещё и блог.

Кстати, совсем забыли, что на самом-то деле это не только канал про фишки питона, но и мой блог, вообще-то)
Хочу поделиться в этом посте тем что вообще в жизни происходит и как успехи с каналом и обучением.

Начну с того, что за последние несколько недель мы успели закончить и сдать сайт, который у нас с @syth0le заказывали. Прошу заметить, что это был по сути наш учебный проект и заказчик знал об этом. Так что если кто-то найдёт ошибки в коде, а они есть, ну сори. Делали как могли.

Могу сказать, что этот сайт - это колоссальный опыт. Я полностью построил вёрстку и фронт и даже когда я сам смотрю на некоторые части проекта - мне до истерики смешно, на сколько это плохо. Но из этого проекта мы очень много извлекли.

Во-вторых, канал. Для меня это что-то сакральное, наверное, потому что мне просто нравится помогать и делиться мыслями, это интересно. Мало того, что я надеюсь кому-то помочь, так ещё и вся эта писанина дополнительно обучает меня. Я заново прохожу материал, повторяю и изучаю. Это круто.

Если вынести последние несколько недель в чеклист, то:
• Купил курс Владилена на 120 уроков по нативному js
• Изучаю vue.js вот по этой книге, рекомендую
• Изучаю Flutter и на данный момент в работе над тем тревел проектом, о котором писал ранее.
• К лету планирую собрать команду из 6-8 человек и написать крутое веб/мобильное приложение, но об этом лучше расскажу как-нибудь отдельно
• Хейчу PHP просто потому что
• Продвигаю канал рекламкой
• Пытаюсь завести привычку писать посты на неделю вперед или что-то типа того. Посты уже полностью готовы до 31.10.20
• Стараюсь не забывать о друзьях и себе
• А, ну ещё я добавил свои стикеры, хаха. Без лишних слов, они прекрасны.

Как-то так вышло. Даже душевно вроде.

А ещё просьба. У меня постепенно иссякают идеи для постов, так как уже которую неделю я стараюсь выпускать что-то ежедневно. Писать мне нравится, так что всех неравнодушных я прошу отписаться мне в ЛС, на рассмотрение принимаются любые идеи.

#blog

​Цикл for для списков и словарей.

Я думаю многие знают стандартный способ запуска цикла for для Python через встроенную функцию range(). Записывается он вот так:

for i in range(10):
    print(i)

Но на самом деле в Python существует намного больше способов итерирования. Сегодня рассмотрим некоторые из них. Для работы нам понадобятся некоторые переменные, которые можно посмотреть тут.

Чтож, предлагаю начать со списков. Для итерирования я предлагаю вам использовать оператор in. Тогда запись будет выглядеть вот так:

for value in object: 
    somethink()

На конкретном примере:

for id_ in subscribersIdList:
    print(id_)

Я использую переменную id_ с нижним подчёркиванием после только для того, чтобы избежать совпадения с зарезервированным именем в Python, функцией id().

Если мы будем рассматривать словари, то всё уже гораздо интереснее. Запишем такой вариант:

for key in dict:
    somethink()

Тогда на примере:

for city in temperature:
    print(f"In {city}: {temperature[city]}°C")

Как вы можете заметить, это очень удобно, но обращаться к словарю temperature по ключу не очень удобно. Чтобы упростить работу придётся познакомиться со встроенным методом списка items(). Он возвращает нам список кортежей формата (key, value). Подробнее смотреть сноску.

Применяя этот метод получаем типовую структуру:

for key, value in dict.items():
    somethink()

На примере это будет выглядеть так:

for city, temp in temperature.items():
    print(f"In {city}: {temp}°C")

Есть ещё несколько удобных способов, но я предлагаю пока что остановиться на этом, а другое разобрать в следующих постах. Декомпозируем, так сказать, очень хорошая привычка. И шизе привет, кстати. Кто понял, тот понял.

#python

​Оператор in и немного о строках.

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

Так вот, в дополнение к прошлому посту скажу, что через for in можно перебирать так же и символы в строке:

for char in string:
    print(char)

Как-то совсем забыл об этом, но знать точно стоит. Ну а теперь заведём переменные:

string = "Я бы любил тебя, но ты не Python"

temperature = {
    "Moscow" : 11, 
    "New York": 12,
}
names = [
    "Helen",
    "Denis", 
]

Отлично. С помощью оператора in мы можем проверить почти любое вхождение в объект, вашему вниманию вот такие записи:

>>> "любил тебя" in string // True
>>> "Moscow" in temperature // True
>>> "Helen" in names // True

Я считаю, что они интуитивно понятны. Но стоит обратить внимание вот на что:
>>> "denis" in names // False

В случае строк этот оператор чувствителен к регистру и ищет лишь полное соответствие. Если понадобится найти вхождение независимо, то можно привести строки, например, к нижнему регистру при помощи метода lower().

Удобно? Я думаю, что очень. Уж точно удобнее некоторых методов поиска для строк, так ещё и в разы читабельнее.

Спасибо за прочтение, это правда очень важно ❤️

#python

​Встроенная функция enumerate.

Гениальная и простая и очень полезная функция. Она позволяет вам пронумеровать ваши данные. Рассмотрим на самых простых для понимания примерах, а именно на строках и списках:

string = 'progway'
names = ['Denis', 'Helen', 'Mark']

enumerate(names)
>>> <enumerate object at 0x00D624C8>

list(enumerate(string))
>>> [(0, 'p'), (1, 'r'), (2, 'o'), (3, 'g'), (4, ....]
list(enumerate(names))
>>> [(0, 'Denis'), (1, 'Helen'), (2, 'Mark')]

Как вы можете видеть, функция enumerate возвращает итерируемый объект без представления для пользователя. Поэтому мы делаем списки из этих объектов через конструктор list(). Таким образом, enumerate возвращает список пронумерованных кортежей типа (num, value).

Самый тривиальный вариант применения - цикл for:

for num, name in enumerate(names, 1):
    print(f'{num}: {name}')

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

Счастья, здоровья вам, и долгих лет жизни. А главное счастья. И здоровья. Счастья.

#python

​Что такое list comprehension в Python.

Очень удобная сущность, которая позволяет определять списки. Самое приятное тут то, что с помощью list comprehension мы определим список быстрее, чем любым другим способом, если я не ошибаюсь.
Итак, вот как выглядит полная структура:
[foo(x) if condition else bar(x) for x in sequence]

Это общая формула. Блоки else и if не обязательны, то есть наше представление списков может быть упрощёно вплоть до:
[x for x in sequence]

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

/// квадраты натуральных чисел от 1 до 10
[x ** 2 for x in range(1, 11)]

/// только чётные натуральные числа от 1 до 20
[x for x in range(1, 21) if x % 2 == 0]

Обратите внимание на то, что if тут в конце. Такая запись характерна для list comprehension без блока else

/// получить список символов из строки
[letter for letter in word]

Насчёт многочисленных условий:

/// список чисел от 1 до 200, одновременно делящихся на 2, 7 и 11
[x for x in range(1, 201) if x % 2 == 0 and x % 7 == 0 and x % 11 == 0]

Кстати, такое число всего одно: 154 = 2 * 7 * 11

/// список кортежей типа (type, num) от 1 до 5
[("Нечётное", x) if x % 2 != 0 else ("Чётное", x) for x in range(1,6)]

Надеюсь эти примеры оказались наглядными и помогут вам в понимании темы. Напоминаю, что все примеры с красивой подсветкой синтаксиса можно ещё раз посмотреть тут.

Ну и конечно же спасибо за прочтение, это важно для меня ❤️

#python

Генераторы и comprehensions в Python.

Немного не так подал терминологию в предыдущем посте, на что меня справедливо поправили, спасибо.

Comprehensions ≠ генератор.
Я поспешил упростить теорию, но по хорошему путать эти сущности не нужно. В интернетах ваших часто встречается объяснение comprehensions именно как генераторов, но на самом деле генератор - это уже совершенно иная вещь, о которой я планировал рассказать чуть позже, так что в скором времени будет пост ещё и о них.

На самом деле верно определить list comprehensions как один из вариантов представления списка. Можно получить список в цикле for, например, а можно при помощи list comprehensions. Преимущество такого представления, как я и сказал, в скорости и краткости записи. Но так как эта запись, по сути, возвращает нам новый список, часто её называют генератором, что не верно.

Прошлый пост я поправил, в следующих постах постараюсь больше такого не допускать. Добра вам.

#python

​Представление словарей и множеств.

Совершенно маленькое, но очень полезное дополнение к посту о list comprehensions. Аналогичным способом можно создавать списки и множества. Сразу на примере:

/// список
[x ** 2 for x in range(1, 11)]

/// множество
{x ** 2 for x in range(1, 11)}

/// словарь
{x: x**2 for x in range(1, 11)}

Полная формула для словарей выглядит сложнее:
{ (key if condition else defaultKey):(value if condition
else defaultValue) for key, value in sequence }

А вот для списков она аналогична list comprehensions.

#python

​Насчёт принципов программирования.

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

KISS - "Keep it simple, stupid" - принцип, который утверждает, что все компоненты программы должны оставаться простыми. Именно в такой расшифровке я дам его тут, хотя есть и немного другие варианты. Главное, что суть одна и та же.

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

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

Надеюсь, что всё верно объяснил. Если что-то не так, то моя личка открыта для всех, буду рад подискутировать 🙂

#useful #principles #theory

​Принцип проектирования DRY.

Продолжу эту полезную на мой взгляд рубрику. Сегодня поговорим о принципе DRY - "Don't repeat yourself". Акроним, который просит нас не повторяться. Суть принципа заключается в том, что каждый компонент программы должен иметь единственное и авторитетное представление.

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

При соблюдении DRY вы избегаете клонирование кода и тем самым делаете код более читабельным, выразительным и упрощаете его поддержку в будущем.

Что интересно, нарушение принципа DRY - это WET - "Write Everything Twice" или "We enjoy typing". Интересная игра слов получается.

Но важно знать, что иногда DRY бывает даже вреден - в системах реального времени. Это те системы, в которой компоненты зависят от состояний друг друга. В таких случаях задержка передачи данных по сети может оказаться критически большой, так что многие вычисления просто делаются на стороне клиента.

И кратенько на этом всё. Про все принципы советую почитать ещё, я не смогу изложить их одновременно кратко и очень ёмко. Ну и на этом всё, спасибо за прочтение

#useful #principles #theory

​Принцип проектирования YAGNI.

YAGNI - «You aren't gonna need it» - «Вам это не понадобится».
Достаточно интересный принцип, который должен знать каждый программист. Он просто позволяет вам делать меньше. Хотя это, наверное, слишком громко сказано🙂
Принцип продвигает идею того, что именно сейчас вы должны максимально отказаться от избыточного функционала даже в том случае, если он понадобится в будущем. То есть только самое нужное, только самое необходимое и всё по очереди, постепенно.
Чем-то напоминает KISS, о котором мы говорили тут, но это всё же немного о другом. Да и в целом в принципах одно на другое частенько похоже, так что этому удивляться не стоит.

У YAGNI есть целый список правил, которые он содержит в себе. Они даже в википедии описаны неплохо, что меня убедило, полный список можете прочитать тут.

Если кратенько, то:
•‎ Тестирование существующего лучше добавления нового функционала.
•‎ Чем больше функций, тем сложнее обслуживать код.
•‎ ПО может становится неоправданно сложным.

Да и тем более, помяните Джобса с его радикальным минимализмом.
На этом кратенько вроде всё. Спасибо за прочтение ❤️

#useful #principles #theory

​SOLID - Принцип единственности ответственности.

Продолжаем обсуждать принципы проектирования и сейчас начнём разбирать, наверное, самую популярную группу принципов SOLID - акроним от пяти аббревиатур, где каждая буква в слове - отдельный принцип. Эти принципы - набор рекомендаций к вашему ООП коду.

Первая буква акронима и первый принцип - SRP - Single Responsibility Principle.
Принцип единственности ответственности говорит нам о том, что у модуля должна быть только одна причина для изменения, а также постулирует то, что каждый класс должен отвечать за что-то одно.
Суть заключается в том, чтобы при возникновении любых изменений в программе задействовалось как можно меньше её модулей. В идеале каждое изменение будет затрагивать только один класс.
Также нужно думать и о будущем, чтобы классы можно было легко расширять без нарушения этого принципа. Есть такой антипаттерн God object, вот его точно допускать нельзя.
Как итог получаем очень серьёзную деструктуризацию, которая помогает нам на всех этапах работы с кодом и делает его более читабельным.

О SOLID буду рассказывать очень кратенько. В целом, в этих принципах нет ничего сложного и они абсолютно легко гуглятся. А я тут поболтаю немного и на этом хватит) Но по всем вопросам всегда открыта личка, прошу.

#principles #theory

​SOLID - Принцип открытости/закрытости.

Второй принцип из группы SOLID - OCP - Open/closed principle - Принцип открытости/закрытости.
Этот принцип утверждает, что каждый элемент программы (модуль, функция, класс) должен быть открыт для расширения, но закрыт для изменения. Это ментальная сущность, скажем так.
Это совсем не значит, что нужно запретить редактирование фала и открыть его только на чтение, нет. Это означает, что все эти элементы программы способны менять свою функциональность без изменения уже написанного кода. То есть то, что мы уже написали - это закрытая для изменения часть, а то, что мы допишем для расширения функционала - это открытая для расширения часть.

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

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

Спасибо тем людям, что терпят моё долгое отсутствие и остаются читателями в любом случае. Это невозможно недооценить ❤️

#principles #theory

​SOLID - Принцип подстановки Барбары Лисков.

Почему-то я слышал мнение, что это самый сложный для понимания принцип, но по моему мнение крайне ошибочное.
LSP - Liskov substitution principle - один из самых простых принципов. Суть его заключается в том, что компоненты программы (функции, модули и т.д.) должны одинаково успешно обрабатывать как экземпляр класса родителя, так и экземпляр потомка класса не зная об этом.

Для понимания достаточно описать супер простой пример, скажем, на том же питоне:

class Person:
    def __init__(self, name):
        self.name = name

class Programmer(Person):
    def __init__(self, name, language):
        Person.__init__(self, name)
        self.language = language

person = Person('Денис')
programmer = Programmer('Макс', 'Python')

А теперь реализуем функцию, которая вернёт имя человека:

def getName(person): 
    return person.name

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

print(getName(person))  // Денис
print(getName(programmer))  // Макс

Всё прекрасно работает как с классом родителем, так и с классом наследником. Если бы было бы иначе, то такая ситуация - нарушение LSP.

В оригинале Барбара Лисков даёт определение этого принципа чисто математически. Возможно, именно из-за этого оно и кажется непонятным. Надеюсь, что я смог объяснить яснее.

Спасибо за прочтение, это важно ❤️

#principles #theory

​SOLID - Принцип разделения интерфейсов.

ISP - Interface segregation principle - один из самых простых для понимания принципов. Его суть заключается в том, что большое количество интерфейсов для разных пользователей лучше, чем один большой интерфейс для всех.

Проще всего понять это можно на примере:
Допустим, что у нас есть класс представления базы данных интернет магазина, в котором реализованы различные методы для добавления/удаления/изменения товаров, поиска и т.д.
В этом случае ограничимся двумя пользователями - это администратор сайта и обычный покупатель. В таком случае делать общий интерфейс для двух этих пользователей будет нарушением принципа разделения интерфейсов. Обычному покупателю не нужны методы добавления или удаления товара. Ему нужен только поиск, возможно методы для управления пользовательской корзиной товаров. А для администратора, в свою очередь, нужны все методы, позволяющие управлять его магазином.

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

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

И снова спасибо тем людям, что не решаются отписываться из-за моей неактивности в последнее время. Не могу сказать, что вуз не нужен, но в период сессии он уж точно старается отнять гораздо больше времени, чем я хотел бы ему дать. Когда-нибудь отпишу что думаю на этот счёт, но не сегодня. Ещё раз спасибо за прочтение, это важно ❤️

#principles #theory