Sasa is a highly driven full stack software developer with background in finance and accounting. A relentless problem solver who is passionate about finding elegant solutions to problems at hand.
Isn't the first example breaking the Encapsulation principle of OOP? I rarely ever use public properties, they are almost always protected or in some cases private.
I'd put these interfaced properties that you propose in Abstract classes rather than in Interfaces. Makes more sense in my opinion, Interfaces should stay stateless and remain the messaging contract. :)
Sasa is a highly driven full stack software developer with background in finance and accounting. A relentless problem solver who is passionate about finding elegant solutions to problems at hand.
You can call it however you want but if another object can directly (on properties) change the state of your object, that object is not encapsulated :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Isn't the first example breaking the Encapsulation principle of OOP? I rarely ever use public properties, they are almost always protected or in some cases private.
I'd put these interfaced properties that you propose in Abstract classes rather than in Interfaces. Makes more sense in my opinion, Interfaces should stay stateless and remain the messaging contract. :)
Encapsulation Is Not Information Hiding
You can call it however you want but if another object can directly (on properties) change the state of your object, that object is not encapsulated :)