Java for Beginner
742 subscribers
708 photos
196 videos
12 files
1.14K links
Канал от новичков для новичков!
Изучайте Java вместе с нами!
Здесь мы обмениваемся опытом и постоянно изучаем что-то новое!

Наш YouTube канал - https://www.youtube.com/@Java_Beginner-Dev

Наш канал на RUTube - https://rutube.ru/channel/37896292/
Download Telegram
Основы ООП в Java

Глава 7. Принципы проектирования и хорошего кода

DRY, KISS, YAGNI

DRY: Не повторяйся

DRY (Don't Repeat Yourself — Не повторяйся) — это принцип, который требует избегать дублирования кода, логики или данных в программе. Если один и тот же фрагмент повторяется в нескольких местах, его нужно вынести в общий элемент, чтобы изменения в одном месте автоматически отражались везде.

Почему важно: Дублирование приводит к ошибкам — если нужно исправить логику, вы рискуете забыть обновить все копии. Это усложняет поддержку кода и увеличивает его объем.
Как применять в
Java: Выносите общую логику в методы, классы или утилиты. Используйте наследование, композицию или библиотеки.

Пример нарушения DRY:
Два метода в классе Calculator, которые дублируют расчет площади:
public class Calculator {
// Нарушение: Дублирование
public double circleArea(double radius) {
return 3.14159 * radius * radius;
}

public double circleVolume(double radius, double height) {
return 3.14159 * radius * radius * height; // Тот же расчет площади
}
}


Исправление: Выносите общую часть в метод:
public class Calculator {
// Правильно: Общий метод
private double calculateCircleBase(double radius) {
final double PI = 3.14159;
return PI * radius * radius;
}

public double circleArea(double radius) {
return calculateCircleBase(radius);
}

public double circleVolume(double radius, double height) {
return calculateCircleBase(radius) * height;
}
}


Нюансы:
Не путайте с WET (We Enjoy Typing — Мы любим печатать) — саркастический термин для дублирующего кода.
В ООП: Используйте абстрактные классы или интерфейсы для общих шаблонов.
В
Java: Константы в enum или static final для общих значений.
Ловушка: Избыточная абстракция — не выносите, если код используется редко (связано с YAGNI).



KISS: Делай просто

KISS (Keep It Simple, Stupid — Делай просто, глупец) — принцип, который призывает к простоте в дизайне кода, алгоритмах и архитектуре. Вместо сложных конструкций выбирайте простые решения, которые легко понять и поддерживать.

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

Пример нарушения KISS:
Сложный расчет с лишними классами:
// Нарушение: Избыточная сложность
public class ComplexCalculator {
public double calculate(double a, double b) {
AdvancedMathUtils utils = new AdvancedMathUtils();
return utils.performAdvancedOps(new OperationContext(a, b)).getResult();
}
}

// Куча лишних классов...
Исправление: Простой метод:
javapublic class SimpleCalculator {
public double calculate(double a, double b) {
return Math.sqrt(a * a + b * b); // Прямо и ясно
}
}


Нюансы:
"Глупец" в аббревиатуре — напоминание, что простота побеждает "умные" хаки.
В ООП: Предпочитайте композицию над глубоким наследованием.
В
Java: Используйте Stream API для простых операций, но не для всего.
Ловушка: Простота не значит примитивность — балансируйте с читаемостью.



#Java #для_новичков #beginner #OOP #DRY #KISS #YAGNI
👍3
YAGNI: Тебе это не понадобится

YAGNI (You Ain't Gonna Need It — Тебе это не понадобится) — принцип, который предупреждает против добавления функциональности заранее, на основе предположений о будущем. Реализуйте только то, что нужно сейчас, чтобы избежать переусложнения.

Почему важно: Предвидение будущего часто ошибочно, и лишний код увеличивает сложность, баги и время на поддержку.
Как применять в
Java: Добавляйте код по мере необходимости, используйте рефакторинг для расширений.

Пример нарушения YAGNI:

Класс с "будущими" методами:
// Нарушение: Лишние методы "на всякий случай"
public class User {
private String name;

public User(String name) {
this.name = name;
}

public void sendEmail() { /* Пока пусто */ }
public void sendSMS() { /* Пока пусто */ }
public void integrateWithAPI() { /* Пока пусто */ }
}
Исправление: Только необходимое:
javapublic class User {
private String name;

public User(String name) {
this.name = name;
}

// Только базовая функциональность
public String getName() {
return name;
}
}


Нюансы:
Связано с принципом "You Are Not Gonna Need It" — фокус на MVP (минимально жизнеспособном продукте).
В ООП: Не создавайте абстрактные классы "на будущее" — реализуйте, когда нужно.
В
Java: Избегайте over-engineering в дизайне (например, Factory для простых объектов).
Ловушка: YAGNI не значит игнорировать планирование — используйте TDD (тест-драйвен разработку) для роста.



Полезные советы для новичков

DRY: Ищите дубли — рефакторьте в методы или утилиты.
KISS: Читайте код через день — если не понятно, упростите.
YAGNI: Задавайте: "Нужно ли это прямо сейчас?"
В
Java: Используйте IDE для рефакторинга (Extract Method для DRY).
Ресурсы: Книга "Чистый код" Роберта Мартина — классика по этим принципам.



#Java #для_новичков #beginner #OOP #DRY #KISS #YAGNI
👍4🔥1
Реактивное программирование

Концепции реактивного программирования: Push vs Pull — кто управляет данными

Сегодня разберём модели Push (отправку данных) и Pull (получение данных), почему одна из них идеальна для реактивного стиля, и как это решает проблемы из первого поста: от тяжёлых потоков до callback-ада.

Представьте: у вас есть конвейер на фабрике. В pull-модели рабочий сам подходит к предыдущему этапу и "берет" деталь, когда ему нужно. В push-модели предыдущий этап "отправляет" деталь дальше, как только она готова, не спрашивая.
Какая модель лучше? Зависит от сценария. В программировании это то же самое: pull подходит для предсказуемых, контролируемых потоков, а push — для динамичных, событийных, где данные приходят непредсказуемо (сеть, пользователи, сенсоры).

Реактивное программирование строится на push — и вот почему это революция.



Pull-модель: вы контролируете темп, но рискуете блокировками

В традиционном императивном программировании (когда код выполняется шаг за шагом, как рецепт) данные обычно "получаются" по требованию. Это pull-модель: потребитель (ваш код) сам запрашивает данные, когда готов их обработать.

Пример — чтение из итератора в Java:
List<String> fruits = Arrays.asList("яблоко", "банан", "вишня");

Iterator<String> iterator = fruits.iterator();

while (iterator.hasNext()) {
String fruit = iterator.next(); // "Вытягиваем" следующий элемент
System.out.println(fruit.toUpperCase());
}


Здесь вы контролируете процесс: hasNext() проверяет наличие, next() получает элемент. Это удобно для локальных, синхронных данных — вы знаете, сколько элементов, и ничего не ждёте. Но под капотом это синхронно: если данные в потоке (файл, сеть), next() может заблокироваться, как в старых потоках. Поток висит в ожидании, ресурсы тратятся впустую.

В асинхронных сценариях pull эволюционировал в Future или CompletableFuture: вы "запрашиваете" результат через get() или цепочки, но контроль остаётся у вас.
Проблема: если источник данных медленный (БД, API), ваш pull-запрос блокирует или создаёт callback-ад. Под нагрузкой — тысячи pull-запросов — система не масштабируется, потому что каждый требует ресурса (потока). Это как толпа в очереди: каждый тянет за своим, но если касса одна, все стоят.


Ещё минус: pull не справляется с "лишними" данными. Если источник генерирует 1 млн событий в секунду, а вы получаете по одному — либо перегрузка буфера, либо вы не успеваете. Нет встроенного механизма, чтобы сказать "замедлись".


#Java #middle #Reactor #Push #Flux
👍3
Push-модель: данные приходят сами, реактивно и эффективно

Теперь изменим: в push-модели источник "отправляет" данные потребителю, как только они готовы, без запросов. Потребитель пассивен — он подписывается и реагирует.
Это основа реактивного программирования: события push'атся асинхронно, без блокировок. Контроль переходит к источнику, но с обратным давлением — подписчик может сказать "хватит на время".


В Reactive Streams это реализовано через Publisher и Subscriber: издатель толкает onNext(элемент), подписчик реагирует сразу.

Пример с Flux в Project Reactor (push-стиль):
Flux<String> pushFlux = Flux.fromIterable(Arrays.asList("яблоко", "банан", "вишня"))
.map(String::toUpperCase); // Преобразование в потоке

pushFlux.subscribe(
fruit -> System.out.println("Получено из push: " + fruit), // Реакция на толкание
Throwable::printStackTrace, // Обработка ошибок
() -> System.out.println("Push завершён")
);


Здесь Flux — издатель, который отправляет элементы по мере готовности. subscribe() — подписка, и элементы приходят автоматически: "ЯБЛОКО", "БАНАН"... Нет next() — нет pull.

Если источник асинхронный, например, чтение из сети:
WebClient.create()
.get()
.uri("https://api.example.com/fruits")
.retrieve()
.bodyToFlux(String.class) // Flux толкает строки из ответа
.subscribe(fruit -> System.out.println("Push из API: " + fruit));


Данные push'атся по мере поступления от сервера — без блокировок. Reactor использует неблокирующий IO (на базе Netty), так что поток не висит: один event-loop-цикл (цикл обработки событий) обслуживает тысячи подписок.


Почему push лучше для реактивности?
Во-первых, эффективность: нет лишних проверок hasNext().
Во-вторых, естественность для событий: клик мыши, сообщение в чате — это push по природе, они приходят сами.
В-третьих, масштабируемость: тысячи подписчиков на один издатель — ок, потому что push идёт через события, а не потоки на каждого.



Гибридные сценарии: когда mix работает

На практике модели смешиваются. В Reactor Flux может имитировать pull через операторы вроде buffer() или take(), но основа — push.

Пример: pull из локального списка, но push в сеть:
Flux.fromIterable(fruits)
.map(String::toUpperCase)
.flatMap(fruit -> sendToApi(fruit)) // flatMap толкает в асинхронный API
.subscribe(result -> System.out.println("Ответ: " + result));


Здесь локальный pull (fromIterable) переходит в push (flatMap для API).
Это гибкость: используйте pull для контроля, push для асинхронности. Но важно избегать блокировок: Reactor проверяет и предупреждает, если в лямбде блокирующий код (onBlock()).

Ещё пример из реальной жизни: стриминг видео в Netflix. Pull — когда пользователь сам получает фреймы, но под нагрузкой лагает. Push — сервер отдает фреймы по мере готовности, с буферизацией. Реактивные библиотеки (как RxJava) позволяют строить такие конвейеры.



Почему Push — ключ к новому подходу в реактивном программировании

Возвращаясь к проблемам: потоки тяжёлые, потому что pull требует ожидания; Future блокирует на get(), потому что это pull в асинхронной обёртке; CompletableFuture даёт цепочки, но push-подход в нём слаб (колбэки — это мини-push, но без полного контроля).

Реактивный push меняет всё:
данные текут как река, вы реагируете без ожидания, ресурсы на минимуме. Системы становятся resilient (устойчивыми): если один поток сломается, другие продолжают. Под нагрузкой — горизонтальное масштабирование без боли.

#Java #middle #Reactor #Push #Flux
👍3