Единый доступ в программировании: принцип Бертрана Мейера для объектно-ориентированного кода. Отсутствие синтаксической разницы между атрибутами и методами.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Содержание
Введение
Принцип компьютерного программирования
Computer programming principle
Принцип единого доступа в компьютерном программировании был сформулирован Бертраном Мейером (впервые в его книге «Объектно-ориентированное построение программного обеспечения»). Он гласит: «Все услуги, предоставляемые модулем, должны быть доступны посредством единого синтаксиса, который не указывает, реализованы ли они через хранение или вычисление». Этот принцип в целом применим к синтаксису объектно-ориентированных языков программирования. В более простой форме он утверждает, что не должно быть синтаксических различий между обращением к атрибуту, предварительно вычисленному свойству или методу/запросу объекта. Хотя большинство примеров фокусируются на аспекте «чтения» принципа (то есть, на получении значения), Мейер показывает, что последствия принципа для «записи» (то есть, для изменения значения) сложнее, в своей ежемесячной колонке на официальном сайте языка программирования Эйфель.
The uniform access principle of computer programming was put forth by Bertrand Meyer (originally in his book Object Oriented Software Construction). It states "All services offered by a module should be available through a uniform notation, which does not betray whether they are implemented through storage or through computation." This principle applies generally to the syntax of object oriented programming languages. In simpler form, it states that there should be no syntactical difference between working with an attribute, pre computed property, or method/query of an object. While most examples focus on the "read" aspect of the principle (i. e., retrieving a value), Meyer shows that the "write" implications (i. e., modifying a value) of the principle are harder to deal with in his monthly column on the Eiffel programming language official website.
Пояснение
Проблема, которую решает Мейер, связана с поддержкой и сопровождением крупных программных проектов или библиотек кода. Иногда в процессе разработки или сопровождения программного обеспечения возникает необходимость изменить класс или объект, превратив простой доступ к атрибуту в вызов метода, после того как значительная часть кода уже написана. Языки программирования часто используют различный синтаксис для доступа к атрибутам и вызова методов (например, `.` против `()`). Такое изменение синтаксиса потребовало бы, в популярных языках программирования того времени, изменения исходного кода во всех местах использования этого атрибута. Это могло бы потребовать внесения изменений в исходный код во множестве различных мест в очень большом объеме кода. Или, что еще хуже, если изменение касается библиотеки объектов, используемой сотнями клиентов, каждому из них пришлось бы найти и изменить все места использования атрибута в своем коде и перекомпилировать свои программы. Обратный переход (от метода к простому атрибуту) не представлял собой проблемы, поскольку функцию можно было просто сохранить и заставить ее возвращать значение атрибута. Мейер осознал необходимость в том, чтобы разработчики программного обеспечения писали код таким образом, чтобы минимизировать или устранить каскадные изменения, возникающие в результате преобразования атрибута объекта в вызов метода или наоборот. Для решения этой задачи он разработал принцип единого доступа. Многие языки программирования не поддерживают принцип единого доступа в строгом виде, но поддерживают его различные формы. Свойства, предоставляемые во многих языках программирования, решают проблему, которую Мейер решал с помощью принципа единого доступа, другим способом. Вместо предоставления единой унифицированной нотации, свойства позволяют вызывать метод объекта, используя тот же синтаксис, что и для доступа к атрибутам. Отдельный синтаксис вызова метода при этом остается доступным.
The problem being addressed by Meyer involves the maintenance of large software projects or software libraries. Sometimes when developing or maintaining software it is necessary, after much code is in place, to change a class or object in a way that transforms what was simply an attribute access into a method call. Programming languages often use different syntax for attribute access and invoking a method, (e. g., versus ). The syntax change would require, in popular programming languages of the day, changing the source code in all the places where the attribute was used. This might require changing source code in many different locations throughout a very large volume of source code. Or worse, if the change is in an object library used by hundreds of customers, each of those customers would have to find and change all the places the attribute was used in their own code and recompile their programs. Going the reverse way (from method to simple attribute) really was not a problem, as one can always just keep the function and have it simply return the attribute value. Meyer recognized the need for software developers to write code in such a way as to minimize or eliminate cascading changes in code that result from changes which convert an object attribute to a method call or vice versa. For this he developed the Uniform Access Principle. Many programming languages do not strictly support the UAP but do support forms of it. Properties, which are provided in a number of programming languages, address the problem Meyer was addressing with his UAP in a different way. Instead of providing a single uniform notation, properties provide a way to invoke a method of an object while using the same notation as is used for attribute access. The separate method invocation syntax is still available.
C++
В C++ нет ни UAP, ни свойств. Когда объект изменяется таким образом, что атрибут (например, цвет) становится парой функций, любое место в коде, где используется экземпляр этого объекта для установки или получения значения атрибута, необходимо изменить, чтобы вызывать одну из этих функций. Используя шаблоны и перегрузку операторов, можно эмулировать свойства, но это сложнее, чем в языках с прямой поддержкой свойств. Это усложняет поддержку программ на C++. Распределенные библиотеки объектов C++ должны тщательно продумать, как они предоставляют доступ к своим членам данных.
C++ has neither the UAP nor properties, when an object is changed such that an attribute (color) becomes a pair of functions Any place in that uses an instance of the object and either sets or gets the attribute value ( or ) must be changed to invoke one of the functions. ( or ). Using templates and operator overloading, it is possible to fake properties, but this is more complex than in languages which directly support properties. This complicates maintenance of C++ programs. Distributed libraries of C++ objects must be careful about how they provide access to member data.
Язык JavaScript
JavaScript поддерживает вычисляемые свойства с 2009 года.
JavaScript has had support for computed properties since 2009.