Java for Beginner
743 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

Глава 6. Ключевые модификаторы ООП

final: переменные, методы, классы

Модификатор final в Java означает "окончательный" и используется для предотвращения изменений. В зависимости от контекста — переменные, методы или классы — он ограничивает возможность переопределения, изменения или наследования.

Зачем нужен final:
Неизменяемость: Защищает данные от изменений, делая код предсказуемым.
Безопасность: Предотвращает нежелательное изменение поведения в подклассах.
Оптимизация: Компилятор может оптимизировать final-элементы, зная, что они не изменятся.
Дизайн: Помогает явно указать намерения разработчика (например, класс не для наследования).



final — один из ключевых инструментов для создания robust и maintainable кода в ООП.

1. Final переменные: Неизменяемые значения
Когда переменная помечена final, ее значение нельзя изменить после инициализации. Это делает переменную константой.

Типы переменных:
Локальные: Инициализируются один раз в методе.
Поля класса: Должны быть инициализированы при объявлении, в блоке инициализации или конструкторе.
Ссылочные типы: Ссылка неизменна, но объект, на который она указывает, может меняться (если он mutable).


Пример:
public class Circle {
private final double PI = 3.14159; // Константа
private final double radius; // Поле, инициализируется в конструкторе

public Circle(double radius) {
this.radius = radius; // Инициализация final
}

public double getArea() {
final double area = PI * radius * radius; // Локальная final переменная
// area = 10; // Ошибка: нельзя изменить
return area;
}
}


Нюанс: Для final ссылки (например, final StringBuilder sb = new StringBuilder();) нельзя переназначить sb = new StringBuilder();, но можно sb.append("text");.

Практика:

Константы: Обычно static final (например, public static final double PI = 3.14159;).
Именование: Константы в верхнем регистре с подчеркиваниями (MAX_VALUE).


2. Final методы: Запрет переопределения
Когда метод помечен final, его нельзя переопределить (override) в подклассах. Это полезно, когда поведение метода должно остаться неизменным.

Пример с наследованием:
public class Animal {
public final void eat() {
System.out.println("Животное ест.");
}
}

public class Dog extends Animal {
// Ошибка, если попытаться:
// @Override
// public void eat() { System.out.println("Собака ест кости."); }
}


Зачем:
Гарантия неизменного поведения.
Безопасность: Критичные методы (например, валидация) не изменятся.
Нюанс: final не влияет на вызов метода, только на override.


3. Final классы: Запрет наследования
Когда класс помечен final, его нельзя использовать как суперкласс (extends). Это предотвращает создание подклассов.

Пример:
public final class ImmutablePoint {
private final int x;
private final int y;

public ImmutablePoint(int x, int y) {
this.x = x;
this.y = y;
}

public int getX() { return x; }
public int getY() { return y; }
}

// Ошибка:
// public class ExtendedPoint extends ImmutablePoint {}


Зачем:
Иммутабельность: Классы вроде String или Integer — final, чтобы гарантировать неизменность.
Безопасность: Например, в криптографии или конфигурации.
Дизайн: Сигнализирует, что класс завершен и не предназначен для расширения.


#Java #для_новичков #beginner #OOP #final
👍3
Все нюансы final

Переменные:
Инициализация: Должна быть до завершения конструктора (для полей) или до использования (локальные).
Blank final: final поле без начального значения, но с обязательной инициализацией в конструкторе.
Нюанс: final List<String> list = new ArrayList<>(); — можно менять содержимое list, но не саму ссылку.


Методы:
Не влияет на полиморфизм: Вызов метода работает как обычно.
Нельзя с abstract: Абстрактный метод требует override, final запрещает.
Нюанс: Используйте для методов, где логика критична (например, security checks).


Классы:
Все методы implicitly final, но это не нужно явно указывать.
Нюанс: String, Integer, Double — примеры final классов в Java.


Ошибки:

Изменение final переменной: Ошибка компиляции.
Override final метода: Ошибка компиляции.
Extends final класса: Ошибка компиляции.


Дизайн и производительность:
Final улучшает оптимизацию JIT (компилятор знает, что не будет изменений).
Избегайте чрезмерного использования: Final классы ограничивают гибкость (например, тестирование с mocking).
Константы: static final для глобальных неизменяемых значений.


Сценарии использования:
Immutable классы: Все поля final, класс final.
Utility классы: Часто final (например, java.lang.Math).
Конфигурации: Final поля для неизменяемых настроек.



Как создать это в IntelliJ IDEA

Final переменные: Объявите поле с final, IDE проверит инициализацию.
Final методы: Добавьте final перед методом, IDE предупредит о попытке override.
Final классы: Добавьте final к классу, IDE покажет ошибку при extends.
Тестирование: Создайте Main и проверьте поведение.



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

Константы: Используйте static final для PI, MAX_VALUE и т.д.
Иммутабельность: Делайте поля final для защиты данных.
Дизайн: Final классы для завершенных реализаций, но не злоупотребляйте.
Проверяйте: Попробуйте override final метода — IDE покажет ошибку.
Ресурсы: Oracle Tutorials on Final Classes and Methods.



#Java #для_новичков #beginner #OOP #final
👍5
Основы ООП в Java

Глава 6. Ключевые модификаторы ООП

static: поля, методы, блоки инициализации


Модификатор static означает "статический" и привязывает элемент к классу, а не к экземпляру (объекту). Static-элементы существуют в одном экземпляре на класс, независимо от количества объектов.

Зачем нужен static:

Общие данные: Для переменных, общих для всех объектов (например, счетчик экземпляров).
Утилиты: Для методов, не зависящих от состояния объекта (например, Math.sqrt()).
Эффективность: Избежать создания объектов для вызова методов.
Инициализация: Блоки для выполнения кода при загрузке класса.


Static — инструмент для класс-уровня логики в ООП, но не злоупотребляйте: он может нарушать инкапсуляцию.
Static поля: Общие переменные класса
Static поля (class variables) принадлежат классу и делятся всеми объектами. Они инициализируются при загрузке класса.


Синтаксис:
static type fieldName = value;


Доступ: Через ClassName.fieldName или объект.fieldName (но рекомендуется через класс).


Пример:
public class Counter {
public static int count = 0; // Static поле

public Counter() {
count++; // Увеличивает общее значение
}
}


Использование:
public class Main {
public static void main(String[] args) {
new Counter();
new Counter();
System.out.println(Counter.count); // 2
}
}


Нюанс: Static поля инициализируются по умолчанию (0 для чисел, null для объектов). Можно изменить в static блоке.



Static методы: Утилиты класса

Static методы принадлежат классу и вызываются без объекта. Они не имеют доступа к non-static полям/методам (нет this).


Синтаксис:
static returnType methodName(params) { ... }
Доступ: ClassName.methodName().


Пример:
public class MathUtils {
public static int add(int a, int b) {
return a + b;
}
}


Вызов:
int sum = MathUtils.add(5, 3);  // 8


Нюанс: Static методы не override — это method hiding. Вызов зависит от типа ссылки, не объекта.


Static блоки инициализации: Код при загрузке класса

Static блоки — код, выполняющийся один раз при загрузке класса (перед конструкторами).

Синтаксис:
static {
// Код
}


Пример:
public class Config {
public static String appName;

static {
appName = "MyApp"; // Инициализация при загрузке
System.out.println("Класс загружен!");
}
}


Нюанс: Несколько блоков выполняются в порядке объявления. Полезно для сложной инициализации static полей (например, загрузка конфигурации).


Все нюансы static

Доступ и видимость:
Static элементы доступны без объекта, но non-static — нет из static контекста.
Нюанс: Из static метода нельзя this.field или non-static method() — ошибка.


Наследование:
Static поля/методы наследуются, но не override — hiding. ChildClass.staticMethod() скрывает ParentClass.staticMethod().
Нюанс: Вызов через ссылку: Animal a = new Dog(); a.staticMethod() — вызовет Animal.version (зависит от типа ссылки).


Инициализация:
Static поля/блоки инициализируются при первой загрузке класса (class loading).
Нюанс: Lazy loading — не инициализируется, пока не используется.


Ошибки:
Доступ к non-static из static — ошибка компиляции.
Static в интерфейсах: Да, с Java 8 (static методы).
Static классы: Nested классы могут быть static (не зависят от внешнего объекта).


Дизайн:
Избегайте mutable static полей — проблемы в многопоточности.
Используйте для констант (static final), утилит (Math), singleton.
Нюанс: Static блоки для JDBC драйверов или логирования.


Многопоточность: Static поля общие — используйте synchronization для изменений.


Как создать это в IntelliJ IDEA

Static поле/метод: Добавьте static — IDE подскажет доступ.
Static блок: Напишите static {} — IDE форматирует.
Тестирование: Вызовите static через класс — IDE автодополнит.



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

Константы: public static final для глобальных.
Утилиты: Static методы для helper-классов.
Избегайте состояния: Static поля — только immutable.
Тестируйте: Проверьте доступ из static/non-static.
Ресурсы: Oracle Tutorials on Static Members.



#Java #для_новичков #beginner #OOP #static
👍3
Основы ООП в Java

Глава 6. Ключевые модификаторы ООП


Перечисления (enum)

Перечисление (enum) — это специальный класс, который представляет фиксированный набор констант (например, дни недели, цвета или статусы). Enum введен в Java 5 и является полноценным классом, наследующим от java.lang.Enum, но с особым синтаксисом.


Зачем нужен enum:
Типобезопасность: Вместо int или String для констант (где возможны ошибки, как 8 для дня недели), enum гарантирует только допустимые значения.
Читаемость: Код становится самодокументируемым (Day.MONDAY clearer, чем 1).
ООП-функции: Enum может иметь поля, методы, конструкторы.
Переключатели: Идеально для switch, без ошибок.
Неизменяемость: Enum константы immutable и final.


Enum — это абстракция для групп констант, делая код robust и maintainable.


Синтаксис и базовое использование enum

Enum объявляется как класс, но с enum вместо class. Константы перечисляются через запятую.

Синтаксис:
public enum EnumName {
CONSTANT1,
CONSTANT2,
// ...
}


Пример для дней недели:
public enum Day {
MONDAY,
TUESDAY,
WEDNESDAY,
THURSDAY,
FRIDAY,
SATURDAY,
SUNDAY
}


Использование:
public class Main {
public static void main(String[] args) {
Day today = Day.WEDNESDAY; // Константа
System.out.println(today); // WEDNESDAY

if (today == Day.WEDNESDAY) { // Сравнение через ==
System.out.println("Середина недели!");
}
}
}


Нюанс: Enum константы — это объекты, но сравниваются через == (не equals, так как уникальные).

Вывод:
System.out.println(today) вызывает toString(), который возвращает имя константы.



Enum с полями, конструкторами и методами

Enum — полноценный класс, так что может иметь private конструкторы, поля и методы. Константы вызывают конструктор.

Пример с полями:

public enum Planet {
MERCURY(3.303e+23, 2.4397e6),
VENUS(4.869e+24, 6.0518e6),
EARTH(5.976e+24, 6.37814e6);

private final double mass; // Масса в кг
private final double radius; // Радиус в м

// Конструктор (private по умолчанию)
Planet(double mass, double radius) {
this.mass = mass;
this.radius = radius;
}

// Метод
public double surfaceGravity() {
final double G = 6.67300E-11; // Константа гравитации
return G * mass / (radius * radius);
}
}


Использование:
Planet earth = Planet.EARTH;
System.out.println("Гравитация на Земле: " + earth.surfaceGravity()); // ~9.8


Нюанс: Конструктор private (нельзя new Planet()). Константы — единственные экземпляры.
Методы: Могут быть абстрактными (каждая константа реализует) или обычными.



#Java #для_новичков #beginner #OOP #Enum
👍3
Методы Enum-класса и полезные функции

Enum наследует от Enum<E>, предоставляя методы:
name(): Возвращает имя константы как String.
ordinal(): Порядковый номер (начиная с 0).
valueOf(String name): Возвращает enum по имени.
values(): Массив всех констант.


Пример:
Day[] days = Day.values();
for (Day d : days) {
System.out.println(d + " ordinal: " + d.ordinal());
}

Вывод: MONDAY ordinal: 0, etc.


Нюанс: ordinal() не рекомендуется для логики — лучше поля, так как порядок может измениться.


Switch с enum

Enum идеален для switch — безопасно и читаемо.
public void printDayType(Day day) {
switch (day) {
case MONDAY:
case TUESDAY:
case WEDNESDAY:
case THURSDAY:
case FRIDAY:
System.out.println("Рабочий день");
break;
case SATURDAY:
case SUNDAY:
System.out.println("Выходной");
break;
}
}


Нюанс: Нет default, если все случаи покрыты — компилятор не требует.


Все нюансы enum

Наследование и реализация:
Enum не может extends класс (уже extends Enum), но может implements интерфейсы.
Нюанс: public enum MyEnum implements Interface { ... }



Конструкторы и поля:
Конструкторы private.
Константы должны быть первыми в enum, за ними — поля/методы.
Нюанс: Константы с параметрами: CONSTANT(params),


Иммутабельность: Enum константы final и immutable — идеально для singleton.
Сериализация: Enum сериализуется по имени, безопасно.

Ошибки:

Enum с public конструктором — ошибка.
valueOf("INVALID") — IllegalArgumentException.
Enum не может быть abstract, но может иметь abstract методы (константы реализуют).



Дизайн:
Используйте для фиксированных наборов (статусы, типы).
Добавляйте методы для логики.
Нюанс: Nested enum — static по умолчанию.



Как создать это в IntelliJ IDEA

Enum: New → Enum → Planet.
Константы: Напишите MERCURY(3.303e+23, 2.4397e6), — IDE подскажет конструктор.
Методы: Добавьте surfaceGravity() — IDE поможет с override для abstract.
Switch: Напишите switch (day) — IDE сгенерирует cases.



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

Замените int/String константы: Enum safer.
Добавляйте toString(): Переопределите для custom вывода.
Используйте в коллекциях: Set для уникальных.
ordinal() осторожно: Лучше поля для значений.
Ресурсы: Oracle Tutorials on Enum Types.



#Java #для_новичков #beginner #OOP #Enum
👍3
Основы ООП в Java

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

SOLID

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

1. Принцип единственной ответственности (S — Single Responsibility Principle)

Этот принцип гласит, что каждый класс или модуль в программе должен отвечать только за одну задачу или иметь только одну причину для изменения. Иными словами, класс не должен заниматься несколькими несвязанными вещами сразу. Если класс делает слишком много, он становится сложным, и изменения в одной части могут сломать другую.

Почему важно: Если класс отвечает за несколько задач, то при изменении одной из них (например, из-за новых требований бизнеса) вы рискуете сломать другие части. Это приводит к ошибкам и усложняет поддержку кода.

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

Пример нарушения принципа:
public class Report {
// Нарушение: Класс делает всё сразу
public void readDataFromFile(String fileName) {
// Код для чтения данных
}

public void processData() {
// Код для обработки данных
}

public void printReport() {
// Код для печати отчета
}
}

Здесь класс имеет три ответственности. Если изменится способ чтения файлов, придется трогать весь класс.


Пример правильного применения:
public class DataReader {
public String readDataFromFile(String fileName) {
// Только чтение данных
return "Данные из файла";
}
}

public class DataProcessor {
public String processData(String data) {
// Только обработка
return "Обработанные данные: " + data;
}
}

public class ReportPrinter {
public void printReport(String processedData) {
// Только печать
System.out.println(processedData);
}
}

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


Совет: Задайте вопрос: "Сколько причин для изменения у этого класса?" Если больше одной — разделите.


2. Принцип открытости-закрытости (O — Open-Closed Principle)

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

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

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



#Java #для_новичков #beginner #OOP #SOLID
👍4🔥1
Пример нарушения принципа:
public class ShapeCalculator {
public double calculateArea(Object shape) {
if (shape instanceof Circle) {
// Код для круга
return Math.PI * ((Circle) shape).getRadius() * ((Circle) shape).getRadius();
} else if (shape instanceof Square) {
// Код для квадрата
return ((Square) shape).getSide() * ((Square) shape).getSide();
}
// Если добавить треугольник, придется менять метод
return 0;
}
}

Добавление новой фигуры требует изменения метода, что нарушает принцип.


Пример правильного применения:Используем абстракцию и полиморфизм.

public abstract class Shape {
public abstract double calculateArea(); // Метод для расширения
}

public class Circle extends Shape {
private double radius;

public Circle(double radius) {
this.radius = radius;
}

@Override
public double calculateArea() {
return Math.PI * radius * radius;
}
}

public class Square extends Shape {
private double side;

public Square(double side) {
this.side = side;
}

@Override
public double calculateArea() {
return side * side;
}
}

// Для новой фигуры просто добавьте класс, без изменения старого кода

Теперь ShapeCalculator может быть:
public class ShapeCalculator {
public double calculateArea(Shape shape) {
return shape.calculateArea(); // Полиморфизм, закрыт для изменений
}
}

Добавление треугольника — новый класс extends Shape, без изменений в калькуляторе.


Совет: Используйте абстрактные классы или интерфейсы для "открытости", а переопределение — для расширения.



3. Принцип подстановки Лисков (L — Liskov Substitution Principle)

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

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

Подробное объяснение: Подкласс должен сохранять контракты суперкласса: предусловия (входные данные) не ужесточаются, постусловия (выход) не ослабляются, инварианты (постоянные свойства) сохраняются.


Пример нарушения принципа:
Представьте суперкласс Bird (Птица) с методом fly() (летать). Подкласс Penguin (Пингвин) переопределяет fly() и бросает исключение, потому что пингвины не летают. Тогда код Bird bird = new Penguin(); bird.fly(); сломается, хотя ожидалось, что любая птица может летать.
public class Bird {
public void fly() {
System.out.println("Летаю!");
}
}

public class Penguin extends Bird {
@Override
public void fly() {
throw new UnsupportedOperationException("Пингвины не летают!");
}
}

Это нарушение: подстановка пингвина ломает код.


Пример правильного применения:
Лучше разделить: суперкласс Animal, интерфейс Flyable для летающих. Пингвин extends Animal, но не implements Flyable.
public class Animal {
// Общие методы
}

public interface Flyable {
void fly();
}

public class Eagle extends Animal implements Flyable {
@Override
public void fly() {
System.out.println("Орел летает высоко!");
}
}

public class Penguin extends Animal {
// Нет fly(), так что не нарушает
}

Теперь код работает только с Flyable, без неожиданностей.


Совет: Проверяйте: "Можно ли заменить суперкласс подклассом без проблем?" Если нет — пересмотрите дизайн.


#Java #для_новичков #beginner #OOP #SOLID
👍4🔥1
4. Принцип разделения интерфейсов (I — Interface Segregation Principle)

Этот принцип говорит, что интерфейсы должны быть маленькими и специализированными, а не большими и универсальными. Клиенты (классы, использующие интерфейс) не должны зависеть от методов, которые они не используют.

Почему важно: Большой интерфейс заставляет классы реализовывать ненужные методы, что приводит к "пустым" реализациям и усложняет код.

Подробное объяснение: Лучше несколько маленьких интерфейсов, чем один большой. Это делает систему модульной и легче для понимания.


Пример нарушения принципа:
public interface Worker {
void work(); // Для всех
void eat(); // Только для людей
void charge(); // Только для роботов
}

Класс Human реализует charge() бесполезно, Robot — eat().


Пример правильного применения:

Разделите на маленькие интерфейсы.
public interface Workable {
void work();
}

public interface Eatable {
void eat();
}

public interface Chargeable {
void charge();
}

public class Human implements Workable, Eatable {
@Override
public void work() { /*...*/ }

@Override
public void eat() { /*...*/ }
}

public class Robot implements Workable, Chargeable {
@Override
public void work() { /*...*/ }

@Override
public void charge() { /*...*/ }
}

Теперь классы реализуют только нужное.


Совет: Интерфейс должен быть "толстым" для клиента, но "тонким" для реализатора — маленькие интерфейсы.


5. Принцип инверсии зависимостей (D — Dependency Inversion Principle)


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

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

Подробное объяснение: Используйте интерфейсы или абстрактные классы как "прослойку". Высокий уровень зависит от интерфейса, низкий — реализует его.


Пример нарушения принципа:
public class ReportService {
private MySQLDatabase db = new MySQLDatabase(); // Зависит от конкретной реализации

public void generateReport() {
db.connect();
// ...
}
}

Смена базы данных требует изменения сервиса.


Пример правильного применения:
public interface Database {
void connect();
// ...
}

public class MySQLDatabase implements Database {
@Override
public void connect() { /*...*/ }
}

public class ReportService {
private Database db; // Зависит от абстракции

public ReportService(Database db) { // Инъекция зависимости
this.db = db;
}

public void generateReport() {
db.connect();
// ...
}
}

Теперь можно передать любую реализацию: new ReportService(new MySQLDatabase()) или new ReportService(new PostgreSQLDatabase()).


Совет: Используйте dependency injection (внедрение зависимостей) для передачи абстракций.


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

Применяйте SOLID постепенно: Начните с единственной ответственности, потом добавляйте другие.
Примеры в Java: Смотрите стандартную библиотеку — она следует SOLID.
Ресурсы: Книга "Clean Code" Роберта Мартина для глубокого понимания.
Практика: Возьмите свой код и проверьте на соответствие каждому принципу.



#Java #для_новичков #beginner #OOP #SOLID
👍3🔥21
Основы ООП в 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
Основы ООП в Java

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

Композиция vs Наследование

В объектно-ориентированном программировании композиция и наследование — это два способа организации кода для повторного использования и связи между классами. Они решают разные задачи и подходят для разных ситуаций.

Наследование:
Механизм, при котором класс (подкласс) наследует поля, методы и поведение от другого класса (суперкласса) с помощью ключевого слова extends. Это воплощает отношение "является" (is-a). Например, Dog является Animal.

Композиция:
Механизм, при котором класс содержит объекты других классов как поля, используя их функциональность. Это воплощает отношение "имеет" (has-a). Например, Car имеет Engine.

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



Наследование: Когда использовать и проблемы

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

Пример наследования:
public class Animal {
protected String name;

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

public void makeSound() {
System.out.println(name + " издает звук.");
}
}

public class Dog extends Animal {
public Dog(String name) {
super(name);
}

@Override
public void makeSound() {
System.out.println(name + " лает: Гав!");
}
}


Когда использовать:
Есть четкое is-a отношение: Dog — это Animal.
Нужно переопределить или расширить поведение (через override).
Полиморфизм: Работа с подклассами через ссылку на суперкласс (Animal[] animals).


Преимущества:
Простота: Код автоматически наследуется.
Полиморфизм: Легко реализовать через override.
Иерархия: Удобно для моделирования реальных сущностей (например, Животное → Млекопитающее → Собака).


Недостатки:
Жесткая связь: Подкласс привязан к суперклассу — изменения в суперклассе могут сломать подклассы.
Хрупкий базовый класс: Изменение метода в суперклассе может неожиданно повлиять на подклассы.
Ограничение Java: Только одиночное наследование (один extends).
Сложность в глубоких иерархиях: Много уровней наследования трудно поддерживать.
Нарушение инкапсуляции: Подклассы могут зависеть от внутренней реализации.

Пример проблемы: Если добавить метод в Animal, который не подходит для всех подклассов (например, fly()), подклассы вроде Dog окажутся в неудобном положении.


Композиция: Когда использовать и преимущества

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


Пример композиции:
public class Engine {
private int horsepower;

public Engine(int horsepower) {
this.horsepower = horsepower;
}

public void start() {
System.out.println("Двигатель с " + horsepower + " л.с. запущен.");
}
}

public class Car {
private String model;
private Engine engine; // Композиция: Car "имеет" Engine

public Car(String model, Engine engine) {
this.model = model;
this.engine = engine;
}

public void drive() {
engine.start();
System.out.println(model + " едет.");
}
}


Использование:
public class Main {
public static void main(String[] args) {
Engine engine = new Engine(200);
Car car = new Car("Toyota", engine);
car.drive(); // Двигатель с 200 л.с. запущен. Toyota едет.
}
}


Когда использовать:
Отношения: Car имеет Engine, а не является им.
Нужно гибкое сочетание функциональности без жесткой связи.
Требуется заменяемость компонентов (например, разные двигатели).


Преимущества:
Гибкость: Легко заменить компонент (например, Engine на ElectricEngine).
Слабая связь: Изменения в Engine не ломают Car, если интерфейс сохранен.
Инкапсуляция: Car скрывает детали Engine, управляя доступом.
Модульность: Компоненты можно использовать в других классах.
Тестирование: Легче подменять компоненты (mocking) для тестов.


#Java #для_новичков #beginner #OOP #Composition #Extends
👍4
Недостатки:
Больше кода: Нужно явно создавать и передавать компоненты.
Сложнее полиморфизм: Требуются интерфейсы для единообразия.



Композиция vs Наследование: Как выбирать

Выбирайте композицию, если:
Нет четкого is-a отношения, а скорее has-a.
Нужна гибкость: Компоненты могут меняться (например, разные реализации Engine).
Хотите избежать жесткой связи или хрупкого базового класса.
Нужно реализовать поведение, которое не должно быть частью иерархии.

Выбирайте наследование, если:
Есть четкое is-a отношение, и подкласс логично расширяет суперкласс.
Нужен полиморфизм через ссылки на суперкласс.
Иерархия простая (1-2 уровня).


Пример: Композиция вместо наследования:

Наследование (проблема):
public class Vehicle {
public void move() {
System.out.println("Движется с помощью двигателя.");
}
}

public class Car extends Vehicle {
// Проблема: А если электромобиль или велосипед?
}

Композиция (решение):
public interface Movable {
void move();
}

public class EngineMovable implements Movable {
@Override
public void move() {
System.out.println("Движется с помощью двигателя.");
}
}

public class Car {
private Movable movement;

public Car(Movable movement) {
this.movement = movement;
}

public void drive() {
movement.move();
}
}

Теперь Car может использовать любой Movable (двигатель, электромотор), без привязки к иерархии.


Все нюансы

Наследование:
Жесткая связь: Подкласс зависит от реализации суперкласса.
Проблема ромба: В Java избежана (одиночное наследование), но множественное через интерфейсы.
Нюанс: Переопределение может нарушить контракт (Liskov Substitution Principle).


Композиция:
Требует интерфейсов для полиморфизма (например, Movable).
Нюанс: Больше кода для передачи компонентов (конструктор, сеттеры).
Делегирование: Car вызывает методы Engine — это нормально.


Когда комбинировать:
Используйте наследование для базовой структуры, композицию для поведения.
Пример: extends AbstractVehicle, но Engine как поле.


Ошибки:
Наследование вместо композиции: Глубокие иерархии или неподходящие is-a.
Композиция без интерфейсов: Теряется полиморфизм.


Дизайн:
Композиция соответствует принципу KISS (меньше связей).
Наследование — YAGNI: Не создавайте иерархии "на будущее".
DRY: Оба подхода помогают повторно использовать код.


Java-специфика:
Интерфейсы + default методы часто заменяют наследование.
Dependency Injection (Spring) — пример композиции.



Как создать это в IntelliJ IDEA

Композиция: Создайте интерфейс (New → Interface), класс с полем и методами.
Наследование: New → Class, укажите extends, IDE поможет override.
Рефакторинг: Extract Interface для перехода от наследования к композиции.



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

Композиция по умолчанию: Если сомневаетесь, начните с has-a.
Проверяйте is-a: Dog is-an Animal? Да. Car is-an Engine? Нет.
Интерфейсы для гибкости: Комбинируйте композицию с интерфейсами.
Избегайте глубоких иерархий: Не больше 2-3 уровней.



#Java #для_новичков #beginner #OOP #Composition #Extends
👍4