Names or semantics of classes in programming
1. When programming, inventing names can take a lot of time. It would seem such an unimportant thing as a name. And just today I realized why I was wasting time on it, and why, in the end, it wasn’t a waste of time.
Creating a name for a model, class (subject area) is important both in design and in coding. After all, the name carries with it a huge cloud of associations from real life, from other areas.
Choosing a name is one of the design stages, when some complicated things - operations, objects, relationships, are hidden by the level of abstraction. That is, hiding behind the designated name.
')
If the name is chosen unsuccessfully and it distorts what the model is, it will interfere not only with those who will read the code and documentation in the future. It interferes right now in the design, confusing. An unsuccessful name makes it difficult to detail the model, makes it difficult to think through the relationship of this model with other models or with the user.
As you call a boat, it will sail.
2. Fresh personal example. I am writing code to run pre-installed virtual machines from various cloud providers. At first, it turned out that the model, that is, the object that the user configures and creates a step-by-step form, in which the installation results are stored later, and with which the user can then perform other actions, first became Instance - an instance of the virtual machine. Such a name made the properties unnecessary for this task - to keep a history of state changes, to track the current status of the instance at the provider and to show it in the user panel. They could not be realized, but they all loom in the background, because This is the common behavior of instances. At the same time, the initial task is very simple and minimal - start the instance, install and configure software on it, and give the result to the user.
I do not like the name, the model is narrowed down to LaunchedInstance, that is, the “instance of the virtual machine that is currently running”. Such a restriction cuts off superfluous concepts, but this name still has many associations that distract from the main short task.
As a result, the correct name for the model was Launch, i.e. direct start operation. The methods and attributes of the class remain the same; only the name has changed. But it now contains only the necessary minimum and does not carry excessive semantic load. After that, it became easier to develop the work logic of the class and to organize interaction with other components of the project.
3. Thinking a name is an immediate part of the design. And if you cannot find a good word and feel dissatisfaction, then most likely you have either thought badly about the model and it does not realize what you called it, or have badly thought through this part of the project and need another model altogether.
The time spent on choosing a name is not wasted. It can be perceived as the earliest testing of the model - a kind of integration test that checks whether the developer correctly represents the task.
Creating a name for a model, class (subject area) is important both in design and in coding. After all, the name carries with it a huge cloud of associations from real life, from other areas.
Choosing a name is one of the design stages, when some complicated things - operations, objects, relationships, are hidden by the level of abstraction. That is, hiding behind the designated name.
')
If the name is chosen unsuccessfully and it distorts what the model is, it will interfere not only with those who will read the code and documentation in the future. It interferes right now in the design, confusing. An unsuccessful name makes it difficult to detail the model, makes it difficult to think through the relationship of this model with other models or with the user.
As you call a boat, it will sail.
2. Fresh personal example. I am writing code to run pre-installed virtual machines from various cloud providers. At first, it turned out that the model, that is, the object that the user configures and creates a step-by-step form, in which the installation results are stored later, and with which the user can then perform other actions, first became Instance - an instance of the virtual machine. Such a name made the properties unnecessary for this task - to keep a history of state changes, to track the current status of the instance at the provider and to show it in the user panel. They could not be realized, but they all loom in the background, because This is the common behavior of instances. At the same time, the initial task is very simple and minimal - start the instance, install and configure software on it, and give the result to the user.
I do not like the name, the model is narrowed down to LaunchedInstance, that is, the “instance of the virtual machine that is currently running”. Such a restriction cuts off superfluous concepts, but this name still has many associations that distract from the main short task.
As a result, the correct name for the model was Launch, i.e. direct start operation. The methods and attributes of the class remain the same; only the name has changed. But it now contains only the necessary minimum and does not carry excessive semantic load. After that, it became easier to develop the work logic of the class and to organize interaction with other components of the project.
3. Thinking a name is an immediate part of the design. And if you cannot find a good word and feel dissatisfaction, then most likely you have either thought badly about the model and it does not realize what you called it, or have badly thought through this part of the project and need another model altogether.
The time spent on choosing a name is not wasted. It can be perceived as the earliest testing of the model - a kind of integration test that checks whether the developer correctly represents the task.
Source: https://habr.com/ru/post/324170/
All Articles