ПИРОЖОК.
Вы когда-нибудь слышали об этом? По какой-то причине у меня текут слюнки.
A-PIE – это не только вкусный запеченный десерт с шелушащейся корочкой и теплой липкой начинкой внутри, это небольшая аббревиатура/мнемоника, помогающая запомнить четыре наиболее важных принципа объектно-ориентированного программирования (ООП).:
- A абстракция.
- P полиморфизм.
- Я наследство.
- E инкапсуляция.
Инкапсуляция – это то, о чем я хочу поговорить сегодня. Похоже, функционал стал новой захватывающей блестящей вещью, и все забыли об ООП, даже на языках ООП. Давайте немного сбросим настройки. Если вы пишете на языке ООП (а их очень много!), если принципы ООП заложены в дизайн вашего языка, то одна из худших вещей, которые вы можете сделать, – это забыть о них. Это все равно что держать нож за лезвие и пытаться резать сыр рукояткой. Тебя порежут на кусочки!
По-другому можно сказать, что это будет похоже на вождение Honda Civic 85-го года по трассе линии электропередач, когда рядом с вами асфальтированная дорога. Это история для другого раза, но мы с другом однажды попытались это сделать, и позвольте мне сказать вам по опыту: это некрасиво, если вы не хотите увидеть какой-нибудь погнутый металл…
Прости! Здесь я сбиваюсь с пути. Давайте вернемся к инкапсуляции .
Таким образом, концепция “классов данных” в наши дни вошла в моду. Kotlin имеет прямую поддержку классов данных и в Scala есть классы case. Это языки JVM. У Java нет прямого эквивалента, но интересно отметить, что оба подхода в основном являются кратчайшими способами создания классического JavaBean , который является модным словом для пакета данных с общедоступными средствами доступа и мутаторами.
C# придерживается той же идеи с автоматическими свойствами . Если вы посмотрите на документацию по автоматическим свойствам , то увидите яркий пример ложки дегтя в моей бочке меда сегодня. В примере определен класс Customer , который затем видоизменяется кодом вне класса:
Класс клиентов
// This class is mutable. Its data can be modified from
// outside the class.
class Customer
{
// Auto-Impl Properties for trivial get and set
public double TotalPurchases { get; set; }
public string Name { get; set; }
public int CustomerID { get; set; }
// other code elided . . .
}
Программа :
class Program
{
static void Main()
{
// Intialize a new object.
Customer cust1 = new Customer ( 4987.63, "Northwind",90108 );
//Modify a property
cust1.TotalPurchases += 499.99;
}
}
Они даже поместили там комментарий: Этот класс является изменяемым. Его данные могут быть изменены извне класса.
Стыд, стыд, стыд, я знаю твое имя C#!!!!!!
Это просто Объектно-ориентированный 101! Когда цель состоит в том, чтобы отслеживать общее количество покупок, раскрывайте эту функциональность как общедоступное поведение в классе клиентов и инкапсулируйте данные, необходимые для обеспечения возможности такого поведения. Код должен выглядеть примерно так:
Класс клиентов
// This class' data cannot be modified from outside the class.
class Customer
{
private double TotalPurchases;
private string Name;
private int CustomerID;
// other code elided . . .
public void AddPurchase( DollarAmount amt ) {
TotalPurchase += amt;
}
}
Программа :
class Program
{
static void Main()
{
Customer cust1 = new Customer ( 4987.63, "Northwind", 90108 );
cust1.AddPurchase(499.99);
}
}
Посмотрите, как свойства класса Customer теперь частные , частные , частные ?
Это верно! Вы должны хранить свои личные данные в секрете . Очевидно, это не только урок, который я должен продолжать преподавать своему двухлетнему ребенку, но соответствующий и вечная поговорка для программистов всех возрастов.
Итак, есть множество причин для того, чтобы держать ваши личные данные в секрете. Большое значение имеет то, что это облегчает развитие программы! Очень возможно, что мы захотим перейти от отслеживания только Сумма в долларах к чему-то большему в будущем. Возможно, вместо этого мы захотим сохранить целый список транзакций.
Так что я не знаю, как вы, но я бы предпочел получить острый тычок в глаз, чем потратить свой день на выслеживание всех ссылок на TotalPurchases и вытаскивание их из любых запутанных сорняков, в которых их потерял другой программист. В хорошем дизайне OO, где мы сохранили Общие покупки приватными, это разовое изменение. Я бы просто обновил внутренности класса Customer и получил всю эту эволюцию бесплатно!
Конечно, это действительно ваш выбор. Никто не может сказать вам, как писать ваш код. Если вы не думаете, что у вас возникнут проблемы с “классами данных” отдельно от “классов поведения” в вашем приложении, обязательно сделайте это хорошо. Но поверь мне, даже если тебе будет забавно один раз посмотреть, каково это – засунуть палец в розетку, ты не захочешь делать это снова. Если я смогу помочь избавить вас от лишних хлопот, то буду чувствовать, что выполнил свою работу при написании этой статьи. Желаю удачи!
Оригинал: “https://dev.to/scottshipp/encapsulate-state-and-expose-behavior-when-writing-object-oriented-code-ea5”