Что такое инкапсуляция в java?

Что не так с процедурным программированием

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

Тут при­хо­дит продакт-менеджер и гово­рит: «Хочу, что­бы поль­зо­ва­тель точ­но знал, в чём ошиб­ка при вво­де элек­трон­но­го адре­са». Теперь вам нуж­но научить функ­цию выда­вать не про­сто true — false, а ещё и код ошиб­ки: напри­мер, если в адре­се опе­чат­ка, то код 01, если адрес спа­мер­ский — код 02 и так далее. Это неслож­но реализовать.

Вы зале­за­е­те внутрь этой функ­ции и меня­е­те её пове­де­ние: теперь она вме­сто true — false выда­ёт код ошиб­ки, а если ошиб­ки нет — пишет «ОК».

И тут ваш код лома­ет­ся: все десять мест, кото­рые ожи­да­ли от про­ве­ряль­щи­ка true или false, теперь полу­ча­ют «ОК» и из-за это­го ломаются.

Теперь вам нужно:

• либо пере­пи­сы­вать все функ­ции, что­бы научить их пони­мать новые отве­ты про­ве­ряль­щи­ка адресов;
• либо пере­де­лать сам про­ве­ряль­щик адре­сов, что­бы он остал­ся сов­ме­сти­мым со ста­ры­ми места­ми, но в нуж­ном вам месте как-то ещё выда­вал коды ошибок;
• либо напи­сать новый про­ве­ряль­щик, кото­рый выда­ёт коды оши­бок, а в ста­рых местах исполь­зо­вать ста­рый проверяльщик.

Зада­ча, конеч­но, реша­е­мая за час-другой.

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

Это назы­ва­ет­ся спагетти-код, и для борь­бы с ним как раз при­ду­ма­ли объектно-ориентированное программирование.

Определение классов

Последнее обновление: 07.10.2017

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

Класс предназначен для описания некоторого типа объектов. То есть по сути класс является планом объекта. А объект представляет конкретное воплощение класса, его реализацию.

Класс может определять переменные и константы для хранения состояния объекта и функции для определения поведения объекта.

Например, определим простейший класс:

class Person
{

};

Для определения класса применяется ключевое слово class, после которого идет собственно название класса. В данном случае класс называется
Person и представляет человека. После названия класса идет блок кода, который определяет тело класса.

После определения класса мы можем создавать его переменные:

class Person
{

};
int main()
{
	Person person;
	return 0;
}

Но данный класс мало что делает. Теперь изменим его:

#include <iostream>
#include <string>
using std::string;
using std::cout;
using std::endl;

class Person
{
public:
	string name;
	int age;
	void move() {
		cout << name << " is moving"<< endl;
	}
};
int main()
{
	Person person;
	person.name = "Tom";
	person.age = 22;
	cout << "Name: " << person.name << "\tAge: " << person.age << endl;
	person.move();

	return 0;
}

Теперь класс Person имеет две переменных name и age, которые предназначены для хранения имени и возраста человека соответственно. Также класс определяет функцию move,
которая выводит строку на консоль

Также стоит обратить внимание на модификатор доступа public:, который указывает,
что идущие после него переменные и функции будут доступны извне, из внешнего кода

Затем в функции main создается один объект класса Person. Через точку мы можем обратиться к его переменным и функциям.
Например, через выражение

person.name = "Tom";

Можно передать значение переменной name. А с помощью выражения

string personName = person.name;

Получить это значение в какую-нибуь переменную. Ну и также мы можем вызывать функции у объекта:

person.move();

Консольный вывод данной программы:

Name: Tom	Age: 22
Tom is moving

Указатели на объекты классов

На объекты классов, как и на объекты других типов, можно определять указатели. Затем через указатель можно обращаться к членам класса — переменным и методам. Однако если при обращении через обычную
переменную используется символ точка, то для для обащения к членам класса через указатель применяется стрелка (->):

#include <iostream>
#include <string>
using std::string;
using std::cout;
using std::endl;

class Person
{
public:
	string name;
	int age;
	void move() {
		cout << name << " is moving" << endl;
	}
};
int main()
{
	Person person;
	Person *ptr = &person;
	ptr->name = "Tom";
	ptr->age = 22;
	ptr->move();
	cout << "Name: " << ptr->name << "\tAge: " << ptr->age << endl;
	cout << "Name: " << person.name << "\tAge: " << person.age << endl;

	return 0;
}

Изменения по указателю ptr в данном случае приведут к изменениям объекта person.

НазадВперед

Инкапсуляция

В информатике инкапсуляцией (лат. en capsula) называется упаковка данных и/или функций в единый объект.

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

Модификаторы доступа

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

Модификатор доступа	Область действия
public	Без ограничений
private	Только из данного класса
protected	Из данного класса и его потомков
Без модификатора	Для всех классов данного пакета

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

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

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

Пример простого описания робота

public class Robot
{
    private double x      = 0; // Текущая координата X
    private double y      = 0; // Текущая координата Y
    private double course = 0; // Текущий курс (в градусах)
 
    public double getX() {
        return x;
    }
    public void setX(double x) {
        this.x = x;
    }
 
    public double getY() {
        return y;
    }
    public void setY(double y) {
        this.y = y;
    }
 
    public double getCourse() {
        return course;
    }
 
    // Определение курса
    public void setCourse(double course) {
        this.course = course;
    }

    // Передвижение на дистанцию distance
    public void forward(int distance) {
        // Обращение к полю объекта X
        x = x + distance * Math.cos(course / 180 * Math.PI);
        // Обращение к полю объекта Y
        y = y + distance * Math.sin(course / 180 * Math.PI);
    }

    // Печать координат робота
    public void printCoordinates() {
        System.out.println(x + "," + y);
    }
}

В представленном примере робота используются наборы методов, начинающие с set и get. Эту пару методов часто называют
сеттер/геттер. Данные методы используются для доступа к полям объекта. Наименования метода заканчиваются наименованием поля, начинающееся
с ПРОПИСНОЙ буквы.

В методах set мы передаем значение через формальный параметр во внутрь процедуры. В коде процедуры мы присваиваем значение
переменной объекта/класса с использованием ключевого слова this.

 ...
this.course = course
...

Использование ключевого слова this необходимо, т.к. наименование формального параметра совпадает с наименованием переменной объекта.
Если бы наименования отличались бы, то можно было бы this не использавать.

Single Responsibility Principle. Не такой простой, как кажется

Tutorial

Single responsibility principle, он же принцип единой ответственности,
он же принцип единой изменчивости — крайне скользкий для понимания парень и столь нервозный вопрос на собеседовании программиста.

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

В лесу нас разделили на группы по 8-9 человек в каждой и устроили соревнование — какая группа быстрее выпьет бутылку водки при условии, что первый человек из группы наливает водку в стакан, второй выпивает, а третий закусывает. Выполнивший свою операцию юнит встает в конец очереди группы.

Случай, когда размер очереди был кратен трем, и являлся хорошей реализацией SRP.

Объект в ООП: определение

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

Какие вещи становятся объектами в ООП? Ниже представлены типичные категории.

Физический объект в ООП – это:

• транспорт в моделях движения потока;
• электрические элементы в программах схемотехники;
• страны в модели экономики;
• самолет в системе управления воздушным движением.

Элементы среды компьютера пользователя:

• меню;
• окна;
• графика (линия, прямоугольник, круг);
• клавиатура, мышь, принтер, дисковые накопители.

Люди:

• работники;
• студенты;
• клиенты;
• продавцы.

Данные:

• книга учета;
• личное дело;
• словарь;
• таблица широт и долгот населенных пунктов.

Связь объектов реального мира и ООП стало результатом сочетания функций и данных: они произвели переворот в программировании. Такого близкого соответствия в процедурных языках нет.

Указатели в Python: в чём суть?

Перевод

Если вы когда-нибудь работали с такими низкоуровневыми языками, как С или С++, то наверняка слышали про указатели. Они позволяют сильно повышать эффективность разных кусков кода. Но также они могут запутывать новичков — и даже опытных разработчиков — и приводить к багам управления памятью. А есть ли указатели в Python, можно их как-то эмулировать?
Указатели широко применяются в С и С++. По сути, это переменные, которые содержат адреса памяти, по которым находятся другие переменные. Чтобы освежить знания об указателях, почитайте этот обзор.
Благодаря этой статье вы лучше поймёте модель объектов в Python и узнаете, почему в этом языке на самом деле не существуют указатели. На случай, если вам понадобится сымитировать поведение указателей, вы научитесь эмулировать их без сопутствующего кошмара управления памятью.

Полиморфизм

Полиморфизм (polymorphism) (от
греческого polymorphos) — это свойство, которое
позволяет одно и то же имя использовать для
решения двух или более схожих, но технически
разных задач. Целью полиморфизма, применительно
к объектно-ориентированному программированию,
является использование одного имени для задания
общих для класса действий. Выполнение каждого
конкретного действия будет определяться типом
данных. Например для языка Си, в котором
полиморфизм поддерживается недостаточно,
нахождение абсолютной величины числа требует
трёх различных функций: abs(), labs() и fabs(). Эти
функции подсчитывают и возвращают абсолютную
величину целых, длинных целых и чисел с плавающей
точкой соответственно. В С++ каждая из этих
функций может быть названа abs().
Тип данных, который используется при вызове
функции, определяет, какая конкретная версия
функции действительно выполняется. В С++ можно
использовать одно имя функции для множества
различных действий. Это называется перегрузкой
функций (function overloading).

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

  Полиморфизм может
применяться также и к операторам. Фактически во
всех языках программирования ограниченно
применяется полиморфизм, например, в
арифметических операторах. Так, в Си, символ +
используется для складывания целых, длинных
целых, символьных переменных и чисел с плавающей
точкой. В этом случае компилятор автоматически
определяет, какой тип арифметики требуется. В С++
вы можете применить эту концепцию и к другим,
заданным вами, типам данных. Такой тип
полиморфизма называется перегрузкой операторов
(operator overloading).

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

ORM: почему эта задача не имеет решения, но делать с этим, тем не менее, что-то нужно

Современные информационные технологии поражают своей мощью, ошеломляют открывающимися возможностями, обескураживают заложенным в них техническим совершенством, но есть один смехотворный пункт, об который IT раз за разом снова и снова ломает зубы. Показать пользователю данные из базы, получить от него ввод, положить обратно в базу, показать результат. Поля ввода, кнопочки, галочки, надписи — казалось бы, что в них может быть такого запредельно сложного, чтобы потребовалось городить головоломные конструкции типа фреймворков поверх шаблонизаторов поверх фреймворков поверх транспайлеров? И почему несмотря на все колоссальные усилия мы имеем то, что игрушечные примеры по туториалу, конечно, делаются легко и приятно, но как только инструментарий сталкивается с реальными задачами реальной жизни… как бы это сказать помягче… с ростом сложности решаемых задач наблюдается сильная нелинейность возрастания сложности реализации. Ладно бы речь шла о чём-то действительно головоломном уровня теоретической физики или космической техники, так ведь нет же — кнопочки и галочки. Почему эта ерунда десятилетиями продолжает отравлять жизнь гражданам и трудовым коллективам?
Причин, наверно, как всегда оно бывает, много. Наверно все они так или иначе достойны рассмотрения, но здесь и сейчас мы поговорим о задаче объектно-реляционного отображения (Object-Relational Mapping, ORM), которая всегда в каком-либо виде стоит за всеми этими «кнопочками и галочками».

Инкапсуляция на примере

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

class Account {
    private int account_number;
    private int account_balance;

    public void show Data() {
        //code to show data 
    }

    public void deposit(int a) {
        if (a < 0) {
            //show error 
        } else
            account_balance = account_balance + a;
    }
}

Предположим, хакеру удалось получить доступ к коду вашего банковского счета. Теперь он пытается внести сумму -100 на ваш счет двумя способами. Давайте посмотрим на его первый метод или подход.

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

Обычно переменные в классе устанавливаются как «частные», как показано ниже. Доступ к нему можно получить только с помощью методов, определенных в классе. Никакой другой класс или объект не может получить к ним доступ.

Так что в нашем случае хакер не может внести сумму -100 на ваш счет.

Подход 2: Первый подход Хакера не сработал. Далее он пытается внести сумму -100, используя метод «депозит».

Но реализация метода имеет проверку на отрицательные значения. Таким образом, второй подход также терпит неудачу.

Таким образом, вы никогда не подвергаете свои данные внешней стороне. Что делает ваше приложение безопасным.

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

Что такое ООП

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

• инкапсуляция;
• наследование;
• полиморфизм.

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

Примеры объектно-ориентированных языков:

1. Pascal. С выходом Delphi 7 на официальном уровне стал называться Delphi. Основная область использования Object Pascal — написание прикладного ПО.
2. C++ широко используется для разработки программного обеспечения, является одним из самых популярных языков. Применяется для создания ОС, прикладных программ, драйверов устройств, приложений, серверов, игр.
3. Java — транслируется в байт-код, обрабатывается виртуальной машиной Java. Преимуществом такого способа выполнения является независимость от операционной системой и оборудования. Существующие семейства: Standard Edition, Enterprise Edition, Micro Edition, Card.
4. JavaScript применяется в качестве языка сценариев для web-страниц. Синтаксис во многом напоминает Си и Java. Является реализацией Ecmascript. Сам Ecmascript используется в качестве основы для построения других скриптовых языков, таких как JScript, ActionScript.
5. Objective-C построен на основе языка Си, а сам код Си понятен компилятору Objective-C.
6. Perl — высокоуровневый интерпретируемый динамический язык общего назначения. Имеет богатые возможности для работы с текстом, изначально разработан именно для манипуляций с текстом. Сейчас используется в системном администрировании, разработке, сетевом программировании, биоинформатике и т. д.
7. PHP. Аббревиатура переводится как препроцессор гипертекста. Применяется для разработки веб-приложений, в частности серверной части. С его помощью можно создавать gui-приложения с помощью пакетов PHP-GTK, PHP-Qt, WinBinder.
8. Python — язык общего назначения, ориентирован на повышение производительности разработчика и читаемость кода. Был разработан проект Cython, с помощью которого осуществляется трансляция программ, написанных на Python в код на языке Си.

Абстракция

Преимущества:

• Применяя абстракцию, мы можем отделить то, что может быть сгруппировано по какому-либо типу.
• Часто изменяемые свойства и методы могут быть сгруппированы в отдельный тип, таким образом основной тип не будет подвергаться изменениям. Это усиливает принцип ООП: «Код должен быть открытым для Расширения, но закрытым для Изменений».
• Абстракция упрощает представление доменных моделей.

Отличие между абстракцией и инкапсуляциейЧто такое абстрактный класс и абстрактный метод?Когда необходимо использовать абстрактный класс?Что такое интерфейс?

1. Множественное наследование.
2. Слабая связанность. Происходит абстракция операции, такая как разделение на уровни, а конкретной реализацией может быть что угодно: JDBC, JPA, JTA и т.д.
3. Программа-интерфейс не реализуется.
4. Полиморфизм с динамическим связыванием: раскрывается програмный интерфейс объекта без раскрытия его фактической реализации.
5. Абстрактные уровни, разделение функциональностей.

Разница между интерфейсом и абстрактным классом.

• Интерфейс — это договорные отношения с классами, которые этот интерфейс реализуют, о том, что реализация происходит путём, обозначенным интерфейсом. Это пустая оболочка с объявленными методами.
• Абстрактный класс определяет некоторое общее поведение и просит свои подклассы определить нетипичное или конкретное поведение для своего класса.
• Методы и члены абстрактного класса могут быть обозначены любым модификатором доступа, в свою очередь все методы интерфейса обязаны быть открытыми (public).
• Когда происходит наследование абстрактного класса, класс-наследник должен определить абстрактные методы, в то время как интерфейс может наследовать другой интерфейс и при этом не обязательно определять его методы.
• Класс-наследник может расширять только один абстрактный класс, а интерфейс может расширять или класс может реализовывать множество других интерфейсов.
• Класс-наследник может определять абстрактные методы с тем же или менее ограниченным модификатором доступа, при этом класс, реализующий интерфейс, должен определять методы с тем же уровнем видимости.
• Интерфейс не содержит конструкторы, в том время, как они есть в абстрактном классе.
• Переменные, объявленные в Java-интерфейсе по умолчанию являются final. Абстрактный класс может содержать переменные, которые не являются final.
• Все участники Java-интерфейса по умолчанию являются . Участники абстрактного класса могут позволить себе быть , и др.

Управление зависимостями в Python: сравнение подходов

Из песочницы

Я пишу на питоне лет пять, из них последние три года — развиваю собственный проект. Большую часть этого пути мне помогает в этом моя команда. И с каждым релизом, с каждой новой фичей у нас все больше усилий уходит на то, чтобы проект не превращался в месиво из неподдерживаемого кода; мы боремся с циклическими импортами, взаимными зависимостями, выделяем переиспользуемые модули, перестраиваем структуру.
К сожалению, в Python-сообществе нет универсального понятия «хорошей архитектуры», есть только понятие «питоничности», поэтому архитектуру приходится придумывать самим. Под катом — лонгрид с размышлениями об архитектуре и в первую очередь — об управлении зависимостями применимо к Python.

Наиболее популярные объектно-ориентированные языки программирования

Первыми успешными объектно-ориентированными языками считаются Симула-67 и Smalltalk-80. Расцвет популярности ООП пришелся на вторую половину 1980-х гг., когда появились такие языки, как С++, Objective C (эти два языка были разработаны на основе не являющегося объектно-ориентированным, но очень популярного Си), Eiffel. Некоторые существовавшие на тот момент языки были доработаны с целью предоставить своим приверженцам возможность работать в стиле ООП (Ada, Lisp, Pascal).

Большим шагом вперед в развитии ООП стал язык Java. Он сосредоточил в себе, помимо объектно-ориентированного подхода, наиболее эффективные технологии, появившиеся в начале 1990-х, такие, как:

• ссылочный синтаксис: объекты создаются таким образом, чтобы невозможно было напрямую (через адреса ячеек памяти, т.н. указатели) повлиять на состояние этих объектов;
• автоматическая сборка мусора: программист избавлен от необходимости вручную очищать память от переменных, которые больше не понадобятся;
• кроссплатформенность — способность программ запускаться на различных платформах (слоган Java — «написано однажды — работает везде»);
• защита полей и методов от нежелательного влияния со стороны других классов: например, поле, помеченное как , доступно для чтения и записи только изнутри класса, — только из иерархии, в состав которой входит класс, — для любых объектов.

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

Всплеск популярности Java побудил другого крупного игрока на софтверном рынке — компанию Microsoft — создать аналогичные продукты. Сначала компания Билла Гейтса хотела выпустить «собственную версию» Java, однако, поскольку написанные на этом языке программы были рассчитаны на запуск лишь в среде Windows (терялась кроссплатформенность), со временем Microsoft решила разработать собственные фреймворк с похожими на Java свойствами. Так появилась платформа .NET и связанный с ней язык C# (Си-шарп). В настоящее время C# считается предпочтительным языком для разработки под Windows. При написании программ на нем применяется преимущественно объектно-ориентированный стиль разработки.

В настоящее время ООП нельзя назвать доминирующей парадигмой программирования. Из языков, бурно развивавшихся в годы наивысшего интереса к этой технологии, активно продолжают использоваться C++, Java, C#. Нынешние языки не делают основную ставку на ООП, но поддерживают эту возможность, поскольку среди программистов остается немало приверженцев этого подхода. Так, объектно-ориентированные программы можно писать на таких популярных в настоящее время языках, как Python, JavaScript, PHP и другие.

Рисунок 3. Популярные объектно-ориентированные языки программирования. Автор24 — интернет-биржа студенческих работ

3 Инкапсуляция

Цель инкапсуляции — улучшить качество взаимодействия вещей за счет их упрощения.

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

С другой стороны, для пассажиров самолета все выглядит проще: купил билет, сел в самолет, взлетели и приземлились. Вы можете с легкостью перелететь с континента на континент, обладая только навыками «купить билет» и «сесть на самолет». Все сложности в виде подготовки самолета к полету, взлета, посадки и различных внештатных ситуаций скрыты от вас. Не говоря уже о спутниковой навигации, автопилоте и диспетчерских центрах в аэропортах. И это упрощает нам жизнь.

С точки зрения программирования, инкапсуляция — это «сокрытие реализации». Мне нравится такое определение. Наш класс может содержать сотни методов и реализовывать очень сложное поведение в различных ситуациях. Но мы можем скрыть от посторонних глаз все его методы (пометить модификатором private), а для взаимодействия с другими классами оставить всего пару-тройку методов (пометить их модификатором public). Тогда все остальные классы нашей программы будут видеть в этом классе всего три метода и вызывать именно их. А все сложности будут скрыты внутри класса, как кабина пилотов от счастливых пассажиров.

Entity “фреймворк” для PHP из одного класса

Поскольку развитие технологий привело к тому, что у каждого программиста теперь есть собственный компьютер, в качестве побочного эффекта имеем тысячи разнообразных библиотек, фреймворков, сервисов, API и т.д. на все случаи жизни. Но когда этот случай жизни наступает, возникает проблема — что их этого использовать и что делать если оно не совсем подходит — переписывать, писать с нуля свое или прикручивать несколько решений для разных вариантов использования.
Думаю, многие замечали, что зачастую создание проекта сводится не столько к программированию сколько к написанию кода интеграции нескольких готовых решений. Иногда такие комбинации превращаются в новые решения, которые можно неоднократно использовать в последующих задачах.
Перейдем к конкретной «ходовой» задаче — объектная прослойка для работы с базами данных в PHP. Решений великое множество, начиная от PDO и заканчивая многоуровневыми (и, на мой взгляд, не совсем уместными в PHP) ORM движками.

Когда полиморфизм терпит неудачу

Из песочницы

Большинство фанатов ООП одновременно и фанаты полиморфизма. Многие хорошие книги (взять хотя бы «Рефакторинг» Фаулера) даже впадают в крайность и утверждают: если вы используете проверки типов во время выполнения (такие как операция в Java), то вы, скорее всего, в душе ужасный монстр. Из тех, что пугают маленьких детей операторами .
Вообще говоря, я признаю, что использование и его аналогов обычно является следствием недостаточных навыков ООП проектирования. Полиморфизм лучше проверок типов. Он делает код гибче и понятнее. Однако есть по крайней мере один распространенный случай, когда вы точно не сможете использовать полиморфизм. Причем случай этот распостранен настолько, что может уже считаться паттерном. Я бы с удовольствием применил в нем полиморфизм, честно. И если вы знаете как это сделать — расскажите мне. Но не думаю что это возможно. По крайней мере точно не в статических языках типа Java или C++.

Определение полиморфизма

На тот случай если вы не знакомы с терминологией ООП объясню о чем идет речь. Полиморфизм — это претенциозное обозначение для концепции позднего связывания. Позднее связывание, в свою очередь — это претенциозное обозначение (вы обнаружите здесь паттерн если копнете глубже) для ситуации, при которой решение о том, какой конкретно метод будет вызван, откладывается до начала выполнения программы. Таким образом проверка соответствия объекта и сообщения (т.е. метода) выполнится уже в ходе работы приложения.
В языках программирования ориентированных на производительность, таких как C++, Java или OCaml, методам ставятся в соответствие числа, а затем для каждого класса создается таблица его методов. По которой и производится поиск во время выполнения. В языках же отдающих предпочтение гибкости и динамизму, поиск осуществляется не среди чисел, а среди хэшированных названий методов. В остальном эти два подхода практически совпадают.
Виртуальные методы сами по себе не порождают полиморфизм. Он вступает в игру только тогда, когда у класса появляются несколько подклассов. Причем каждый из которых реализует свою, особую, версию полиморфного метода. В банальнейшем примере из учебника это было бы проиллюстрировано аналогией с зоопарком, в котором все животные по-разному обрабатывают сообщение . (Хотя на самом деле учебники врут — все запахи чертовски схожи, дело просто в их величине. По моему скромному мнению, конечно. Правда, я все еще не решил у кого эта величина максимальна — у гиппопотама или жирафа? Спросите об этом чуть позже.)

Класс

Класс — это такой тип данных, который состоит из единого набора полей и методов.

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

• наследования;
• ассоциации;
• агрегации.

При наследовании дочерний класс наследует все свойства родителя, ассоциация подразумевает взаимодействие объектов. Когда объект одного класса входит в другой, это называется агрегацией. Но когда они еще зависят друг от друга по времени жизни, — это композиция.

Одной из главных характеристик является область видимости. Понятие по-разному определяется разными ЯП.

В Object Pascal описывается следующим образом:

ClassName = class(SuperClass)

private

{ использование элементов ограничивается только пределами модуля }

{ здесь указываются поля }

strict private

{ спецификатор доступа стал доступным с выходом Delphi 2007, обозначает то же, что и private }

protected

{ элементы могут использоваться внутри ClassName или при наследовании }

public

{ }

published

{ элементы доступны всем, они отображаются в Object Inspector’e }

end;

Здесь SuperClass — предок, от которого происходит наследование.

Для C++ создание выглядит так:

class MyClass: public Parent

{

public:

MyClass(); // конструктор

~MyClass(); // деструктор

protected:

private:

};

В этом примере Parent является предком, если таковой имеется. Спецификаторы private, public, protected обозначают то же самое, что в предыдущем примере на Паскале. Также мы видим конструктор, деструктор, доступные для любой части программы. У C++ все элементы по умолчанию являются private, соответственно, это можно не указывать.

Шаблоны с переменным количеством аргументов на примере обертки для Lua

Из песочницы

Понадобилось мне прикрутить Lua к проекту на C++. Писать обертки в ручную — лень (слишком много писать), готовые не подходили по тем или иным причинам. Решил написать свою. А потому задался вопросом, как максимально упростить интерфейс? От одной только мысли об этом в голову лезли жутчайшие конструкции из шаблонов. Так оно в последствии и оказалось, но гораздо проще, чем представлялось.
В C++11 появились шаблоны с переменным числом аргументов, это позволяет писать шаблонные функции/классы так, как в C++03 было невозможно вовсе. Такие шаблоны сильно упрощают задачу.
Первым делом понадобилось написать обертку над простейшими действиями с интерпретатором (можно было бы обойтись простыми вызовами к C API Lua, но держать в памяти кучу индексов различных значений в стеке мне не хочется. Поэтому я обернул их в несколько функций, которые помимо того, что избавляют от необходимости передавать в каждую функцию указатель на состояние интерпретатора, практически не требуют индексов, так как они имеют значения по умолчанию.
В итоге хотелось увидеть интерфейс близкий к следующему:

Типизируйте уже наконец свой код

Перевод

Привет хабр!

На днях мне в очередной раз на глаза попал код вида

В коде есть одна довольно важная особенность: получателю крайне хотелось бы знать, что произошло на самом деле. Ведь в одном случае у нас проблемы с работой системой, а в другом — мы просто прогреваемся. Однако модель не дает нам этого (в угоду отправителю, который зачастую является автором модели).
Более того, даже факт «возможно, что-то не так» происходит из того, что коллекция пуста. Что в некоторых случаях может быть и корректно.

Я уверен, что большинство опытных разработчиков встречало в коде строки, в которых заключалось тайное знание в стиле «если выставлена эта комбинация флажков, то от нас просят сделать A, B и C» (хотя по самой модели этого не видно).

С моей точки зрения, подобная экономия на структуре классов сказывается крайне негативно на проекте в будущем, превращая его в набор хаков и костылей, постепенно трансформируя более-менее удобный код в legacy.

Важно: в статье я привожу примеры, которые полезны для проектов, в которых несколько разработчиков (а не один), плюс которые будут обновляться и расширяться в течении хотя бы 5-10 лет. Всё это не имеет смысла, если в проекте один разработчик лет на пять, или же если после релиза никаких изменений не планируется

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

Однако если же вы занимаетесь долгоиграющим — добро пожаловать под кат.

Самодокументируемый код – это (как правило) чушь

Перевод

Всем привет!
Предваряя сегодняшнюю переводную публикацию, сразу отметим, что этот текст задуман как follow-up недавнему дискуссионному материалу «Прекратите усердствовать с комментариями в коде». Нас настолько впечатлила развернувшаяся там дискуссия и 189 комментариев по состоянию на 19.07.2019, что мы решили дать здесь слово и другому автору с портала Medium (Кристоферу Лейну), который практически по всем принципиальным вопросам полемизирует с тезисами Брайана Норлендера, автора первой статьи. Отметим, что в оригинале данная статья вышла на месяц позже предыдущей (16 мая и 16 июня), но собрала практически вдвое меньше аплодисментов (706 против 1,5K на момент публикации перевода). Посмотрим, что будет на Хабре…
Снимок взят с сайта rawpixels.com от автора Pexels