POKA-YOKE design: from “smell” to fragrance
From the translator. This is a translation of a series of posts from the blog of Mark Siman. I do not want to combine some of the posts, despite the fact that they are small in size, but just try to keep the structure proposed by Mark.
A little more from the translator. POKA-YOKE can be translated as “foolproof” or fault tolerant.
Encapsulation is one of the most misunderstood concepts in object-oriented programming (OOP). It seems that most people think that, with regard to encapsulation, the concept of " hiding information " simply means that private fields should be disclosed through public properties (or getter \ setter methods in languages that do not have the property support ).
Have you ever wondered what the real advantage is in inheriting code like the following?
For me, such code looks terribly redundant (and automatic properties are not the answer, this is just a trick of the compiler, which, as before, will create a field). No information is, in fact, hidden. Derik Bailey wrote a good post about why this way of encapsulation is too narrow , so I will not repeat his conclusions here.
So what does encapsulation really mean ?
The main advantage of object orientation is the production of related pieces of code (classes) that solve given problems once and for all, so that programmers can use these classes without knowing anything about their internal implementation details.
Here is a list of what well-designed classes provide:
It is this feature that makes encapsulation so important. A class must hide information that it encapsulates in order to protect it from "naive" users. Wikipedia says the following:
Keep in mind that users are not expected to fully understand the guts of a class implementation. This makes the encapsulation definition obvious:
It does not follow from this that encapsulation means concealment of difficulties. Whenever complexity is hidden ( as with the Provider pattern ), the feedback time increases. Fast feedback is highly preferred, so it is advisable to avoid delays in feedback when there is a possibility.
In Lean ( note translator: lean software development process ) this is known as foolproof ( poka-yoke ), I find the only way to think of encapsulation as Poka-yoke design: APIs that make it so difficult to do something wrong, as much as possibly.
Considering that compilation is the cheapest mechanism for obtaining feedback , it is preferable to design the API so that the code can only be compiled if the classes are used correctly. (n . translator. I think it is more correct to say: “design the API in this way (if possible) so that in cases of its misuse, users will receive compilation errors indicating the problem and, if this is not possible, they would receive a notification in during the program as early as possible. )
In the series of posts, I will look at various design “smells” that break encapsulation and prepare a guide on how to improve the designed code in order to make it more secure, thus moving from “smells” to fragrance.
Postscript: At boundaries, applications are not object-oriented.
A little more from the translator. POKA-YOKE can be translated as “foolproof” or fault tolerant.
Encapsulation is one of the most misunderstood concepts in object-oriented programming (OOP). It seems that most people think that, with regard to encapsulation, the concept of " hiding information " simply means that private fields should be disclosed through public properties (or getter \ setter methods in languages that do not have the property support ).
Have you ever wondered what the real advantage is in inheriting code like the following?
private string name; public string Name { get { return this.name; } set { this.name = value; } } For me, such code looks terribly redundant (and automatic properties are not the answer, this is just a trick of the compiler, which, as before, will create a field). No information is, in fact, hidden. Derik Bailey wrote a good post about why this way of encapsulation is too narrow , so I will not repeat his conclusions here.
So what does encapsulation really mean ?
The main advantage of object orientation is the production of related pieces of code (classes) that solve given problems once and for all, so that programmers can use these classes without knowing anything about their internal implementation details.
This is the whole essence of encapsulation: proposing (opening) solving a problem without requiring the consumer to have a full understanding of the subject area.
Here is a list of what well-designed classes provide:
- You do not have to understand the internal details of the tabular data stream ( TDS ) in order to use ADO.NET in conjunction with SQL Server.
- You do not have to understand the internal details of drawing on the screen in order to use WPF or WinForms.
- You do not have to understand the internal details of the reflection in order to use the DI Container.
- You do not have to understand how to effectively sort the list in order to sort the list using the .NET framework.
- Etc.
It is this feature that makes encapsulation so important. A class must hide information that it encapsulates in order to protect it from "naive" users. Wikipedia says the following:
Hiding the viscera of the object ensures its integrity, preventing users from setting the internal data of the component in a contradictory or incorrect state.
Keep in mind that users are not expected to fully understand the guts of a class implementation. This makes the encapsulation definition obvious:
Encapsulation is a fault tolerance mechanism.
It does not follow from this that encapsulation means concealment of difficulties. Whenever complexity is hidden ( as with the Provider pattern ), the feedback time increases. Fast feedback is highly preferred, so it is advisable to avoid delays in feedback when there is a possibility.
Encapsulation is not about hiding difficulties, on the contrary, about how to reveal complexity in a fault-tolerant form.
In Lean ( note translator: lean software development process ) this is known as foolproof ( poka-yoke ), I find the only way to think of encapsulation as Poka-yoke design: APIs that make it so difficult to do something wrong, as much as possibly.
Considering that compilation is the cheapest mechanism for obtaining feedback , it is preferable to design the API so that the code can only be compiled if the classes are used correctly. (n . translator. I think it is more correct to say: “design the API in this way (if possible) so that in cases of its misuse, users will receive compilation errors indicating the problem and, if this is not possible, they would receive a notification in during the program as early as possible. )
In the series of posts, I will look at various design “smells” that break encapsulation and prepare a guide on how to improve the designed code in order to make it more secure, thus moving from “smells” to fragrance.
- The "smell" of design: time I connectivity.
- The "smell" of design: an obsession with primitives.
- Code smell: automatic properties.
- Design smell: excessive attribute Required.
- Design smell: designer by default.
Postscript: At boundaries, applications are not object-oriented.
')
Source: https://habr.com/ru/post/205086/
All Articles