is there any relation object states control and encapsulation?
-
I am writing an article on best practices and in this article I am trying to formulate an hypothesis for which public functions eventually lead to most of the code design issues. It's not public functions per se, but more about inter-objects communication (messaging). Established that encapsulation works fine for data abstract types, how would you define the situation in which stateful objects with well defined behaviours, do not have control on their states? Let's say in the best case scenarios, I have a well defined object with well defined behaviours, like Walk() and Run() but doesn't have control on when it walks and when it runs. Other objects will control when this object walks or runs. Let's now say that this object is used in a spaghetti codebase, where the reference to this object is injected indiscriminately. The object could potentially find itself walking or running at the wrong times. What I am trying to say is that encapsulation ensures the validity of the states, but cannot determine if the states are set at the right time. How would you define this problem? I know how to solve it, I am just trying to understand if encapsulation is involved at all in this problem. Without public functions this problem wouldn't exist in the first place, but is the possibility of settings states at the wrong time a form of broken encapsulation?
-
I am writing an article on best practices and in this article I am trying to formulate an hypothesis for which public functions eventually lead to most of the code design issues. It's not public functions per se, but more about inter-objects communication (messaging). Established that encapsulation works fine for data abstract types, how would you define the situation in which stateful objects with well defined behaviours, do not have control on their states? Let's say in the best case scenarios, I have a well defined object with well defined behaviours, like Walk() and Run() but doesn't have control on when it walks and when it runs. Other objects will control when this object walks or runs. Let's now say that this object is used in a spaghetti codebase, where the reference to this object is injected indiscriminately. The object could potentially find itself walking or running at the wrong times. What I am trying to say is that encapsulation ensures the validity of the states, but cannot determine if the states are set at the right time. How would you define this problem? I know how to solve it, I am just trying to understand if encapsulation is involved at all in this problem. Without public functions this problem wouldn't exist in the first place, but is the possibility of settings states at the wrong time a form of broken encapsulation?
-
I am writing an article on best practices and in this article I am trying to formulate an hypothesis for which public functions eventually lead to most of the code design issues. It's not public functions per se, but more about inter-objects communication (messaging). Established that encapsulation works fine for data abstract types, how would you define the situation in which stateful objects with well defined behaviours, do not have control on their states? Let's say in the best case scenarios, I have a well defined object with well defined behaviours, like Walk() and Run() but doesn't have control on when it walks and when it runs. Other objects will control when this object walks or runs. Let's now say that this object is used in a spaghetti codebase, where the reference to this object is injected indiscriminately. The object could potentially find itself walking or running at the wrong times. What I am trying to say is that encapsulation ensures the validity of the states, but cannot determine if the states are set at the right time. How would you define this problem? I know how to solve it, I am just trying to understand if encapsulation is involved at all in this problem. Without public functions this problem wouldn't exist in the first place, but is the possibility of settings states at the wrong time a form of broken encapsulation?
-
Are you asking if you might hit a brick wall while driving your car? Yes you might. Nonetheless your car is not faulty (at least before you hit the wall).
The car is fine, except for one nut behind the wheel.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
I am writing an article on best practices and in this article I am trying to formulate an hypothesis for which public functions eventually lead to most of the code design issues. It's not public functions per se, but more about inter-objects communication (messaging). Established that encapsulation works fine for data abstract types, how would you define the situation in which stateful objects with well defined behaviours, do not have control on their states? Let's say in the best case scenarios, I have a well defined object with well defined behaviours, like Walk() and Run() but doesn't have control on when it walks and when it runs. Other objects will control when this object walks or runs. Let's now say that this object is used in a spaghetti codebase, where the reference to this object is injected indiscriminately. The object could potentially find itself walking or running at the wrong times. What I am trying to say is that encapsulation ensures the validity of the states, but cannot determine if the states are set at the right time. How would you define this problem? I know how to solve it, I am just trying to understand if encapsulation is involved at all in this problem. Without public functions this problem wouldn't exist in the first place, but is the possibility of settings states at the wrong time a form of broken encapsulation?
What you are dealing with is called reaction programming .. your object needs to react to things .. anything from collisions to just communicating when asked. It's well described here along with the usual 3 ways to deal with it Reactive programming - Wikipedia[^] Now take care Object-oriented Reactive Programming is not Reactive Object-oriented Programming there is a big difference between those two you need to decide which you are doing and the difference between them. From what you said I think what you are after is Observer pattern - Wikipedia[^]
The Observer pattern addresses the following problems:
- A one-to-many dependency between objects should be defined without making the objects tightly coupled. - It should be ensured that when one object changes state an open-ended number of dependent objects are updated automatically. - It should be possible that one object can notify an open-ended number of other objects.Now in programmer jargon speak we call observer pattern programming as "Omnipotent god programming" because there will exist an object or function that observes and controls everything. It is often used in games programming but it is not well suited to real world situations where you can't encapsulate all options and you need to "think" about what is going on. As an example DNS attacks on websites work because they break the observer pattern of the internet standards .. to deal with the attack you need to know past history and apply some logic :-)
In vino veritas
-
The car is fine, except for one nut behind the wheel.
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
I really like this analogy and I will steal it for my article. However argument is that encapsulation eventually doesn't solve the problem its meant to solve and it's flawed. I know it's controversial, but after some research, I found out I am not the only one who got to this conclusion Object-Oriented Programming: A Disaster Story – Brian Will – Medium[^]. The controversial part is that people can argue that Encapsulation does its job (like in the case of the car), but OOP doesn't help, with its flexibility, to not break the car. If I can break the car easily, what's the point of the encapsulation to start with? Of course Encapsualtion as hiding of complexity is absolutely valid. Hence I think this problem I am trying to formalise, which is the possibility to set a valid state at the wrong time, may need another name. I will link the article here before to make it public, as I'd like your feedback.
-
I really like this analogy and I will steal it for my article. However argument is that encapsulation eventually doesn't solve the problem its meant to solve and it's flawed. I know it's controversial, but after some research, I found out I am not the only one who got to this conclusion Object-Oriented Programming: A Disaster Story – Brian Will – Medium[^]. The controversial part is that people can argue that Encapsulation does its job (like in the case of the car), but OOP doesn't help, with its flexibility, to not break the car. If I can break the car easily, what's the point of the encapsulation to start with? Of course Encapsualtion as hiding of complexity is absolutely valid. Hence I think this problem I am trying to formalise, which is the possibility to set a valid state at the wrong time, may need another name. I will link the article here before to make it public, as I'd like your feedback.
I think you intended this reply for Carlo. If I mention @CPallini here, he should be alerted. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
-
I think you intended this reply for Carlo. If I mention @CPallini here, he should be alerted. Cheers, Peter
Software rusts. Simon Stephenson, ca 1994. So does this signature. me, 2012
Peter and @CPallini, I know it's a long shot, but if you have 10 minutes to read a first draft of my article, I would like to know if it makes sense to you and in this case give me some feedback. The Quest for Maintainable Code and The Path to ECS - Seba's Lab[^] password: readme. I don't want this article to be too abstract, I know that I assume that people know what ECS is (It's not an article about explaining it), but nevertheless I need to know if I face things so abstractly that is hard to see how they are applied in real life. I will gather more significant anecdotes before to publish it.
