I think this is truly reflect, which is one weakest point of OOP concept.
Imho, a similar reason to avoide the OOP programming as possible.
Because even with the lightest object we are attach our functions to the data, and part of these data are protected also. So handling this data is bit painfull because always need to care about lifecycle of object not just the the data.
Data with operations defined on that data is not limited to OO. For example, FP monads indistinguishable from OO classes - data with operations defined on them. The only thing that actually matters is the immutability of data. As long as data immutable, one can consider private data a "context", i.e. few more input parameters to the function.
You right. But when you attach operations to data, then you also faced to another problem, when that data is came from outer source then it need to be attach to operations, and when to send it, then need to detach from operations.
Software engineer, lifelong learner, language enthusiast & avid reader — Get my free 7-day email course to refactor your coding career: bit.ly/csarag-lessons
Location
Colombia 🇨🇴 (not Columbia)
Work
Content, Courses & Training for .NET teams — Helping teams to write maintainable & performant code
Real world objects have both functionality (you can tell it to do something by calling one of its functions) and state (it stores data as attributes and relationships to remember what state it is in).
Real world objects also have lifecycles - we can try to simplify an application by pretending that real world objects don't have lifecycles but then you would be breaking Einstein's simplicity theorem which goes something like "Make things as simple as possible but simpler" i.e. not too simple that it's no longer correct!
Assuming objects are 100% immutable may satisfy our puritanical mathematical desires and fit nicely into "set theory" but it's just a theory that's best kept for the theoretical mathematics lectures at university - meanwhile, back in the real world, we need to cope with the fact that objects aren't always immutable and so we need to be able to write software that can represent thousands or millions of real world mutable objects and the interactions between them.
OOP allows you to encapsulate the functionality and the state of a real world object inside a software object that is defined by a class. It also allows incredible amount of reuse via inheritance (making sure, of course, that the correct balance of inheritance vs composition is always achieved).
In other words OOP is the most programatically efficient way to code if you want your software objects to be as close as possible to the real world objects that they represent.
Many developers love this concept and have discovered that OOP's ability to model real world objects via encapsulation, inheritance and polymorphism means that as their applications grow the complexity of the source code grows close to linearly instead of exponentially as with most other paradigms that came before and after it.
It is sounds good, but at the end of the day we are combined and inherit of some class, where we are hope ( have hidden part ) to solve our problem, but in a real world object never same as the picked one. Or in other example: we just want to make a documentation with code example, and some tricky reason - company are mandatory use excel and word for work. So we pick a word to make our document. Which is unreadable ( don't count how professional we are on word use ) because word separated our document to unified page sized, because that program is depend on old print to something to paper. Now we are try to save our planet and don't use paper for every uninformative documentation ( I hope ), but we are still using word. Why? because we just want a banane but get the whole jungle.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
Think of a normal modern JS/TS codebase. E.g. any Next JS, Solid, Vue... whatever.
You'll probably find near to zero OOP, however you'll sure come across functions that are not exported, that act just as a helper of some other function, their reason to exist is solely to help other function within the same file.
You can, conceptually, refer to them as private functions, equivalent to a private method for all intents and purposes of this context. You won't be testing these, either.
As a rule of thumb, if the only reason to have the keyword "export" in a function is so you can import it for testing purposes, you're doing something wrong.
Easy way to explain it is that we don't test steps (functions/methods), we test the rigour of the algorithms (input A = output B) to ensure our software keeps working as expected, wether the algorithm has 2 or 95 steps is none of our business from the testing perspective.
This explanation is just to show an example of the same situation without involving the programming paradigm to avoid getting ourselves into the weeds here. These are two completely separated discussions.
Don't forget the WebComponent where you need to be use OOP pattern.
But what is the deep concern of private method in OOP? Maybe we would like to show just a minimal public interface to the outer word, and protect that function to called from out side. So technically enough to test the public part of our Object. Under Object development maybe we set protected method to public, so we can write a test for that. Later if our object are stable, we can move that part to protect. Or we can use Symbol key for that function which we don't want to use public, but these Symbol we share to test, but not for in our lib.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
The method of Schrödinger 😂😂 No, don't do that, it just makes things more complicated for no reason. If you test all use-cases of your public functions/methods you're implicitly testing all the private ones at the same time and if not, the coverage will tell you exactly what you are missing.
Lastly I can't honestly consider web-components as part of the "modern" ecosystem. They're a standard API, yes, but a bad one nevertheless.
If you don't use framework, then WebComponent will be really handy. I created a markdown-viewer WebComponet which is part of my game development process, and that is fine. I try to skip using JS framework. Maybe check out my game development: dev.to/pengeszikra/javascript-grea...
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
But... why? There are JS frameworks literally created with game development in mind. Phaser, Pixi, Babylon, PlayCanvas... Or even Three.js if you want to toy around at a lower level.
If it's for learning purposes it's fine but if you're serious with your development and want to achieve a production-ready product... Why reinvent the wheel?
I am big fun of Mr. Doob. But Three.js for example are created 2010 so that is based on OOP pradigm, Phaser also. Each of these game engine are based on WebGL. But my initial ida is: the simple vanila HTML/CSS is much more useful to represent card game in 3D. Because on WebGL really hard to make a well formated text on 3D plane. Also problematic to make a simple card which rounded corner.
Please show me another card game, where you saw the deck as real 3D object maded by cards.
So that why I spend work to create a this way.
The state handling is also important to every complex game flow handling. My previous game used by react have much harder state management, compared to this one. Where I can use a one simple function with Proxy to handle my states, and that is working perfectly, because that state don't attach directly to a view as in React. So I can use my code even on server side also.
My last goal is to compare how large or small code/css need to be make for creating a this type of game.
Summary: I would like to pushing forward our way of working and thinking.
Tech Lead/Team Lead. Senior WebDev.
Intermediate Grade on Computer Systems-
High Grade on Web Application Development-
MBA (+Marketing+HHRR).
Studied a bit of law, economics and design
Location
Spain
Education
Higher Level Education Certificate on Web Application Development
I think this is truly reflect, which is one weakest point of OOP concept.
Imho, a similar reason to avoide the OOP programming as possible.
Because even with the lightest object we are attach our functions to the data, and part of these data are protected also. So handling this data is bit painfull because always need to care about lifecycle of object not just the the data.
Data with operations defined on that data is not limited to OO. For example, FP monads indistinguishable from OO classes - data with operations defined on them. The only thing that actually matters is the immutability of data. As long as data immutable, one can consider private data a "context", i.e. few more input parameters to the function.
You right. But when you attach operations to data, then you also faced to another problem, when that data is came from outer source then it need to be attach to operations, and when to send it, then need to detach from operations.
Serialization does not depend on OO or FP. There is no need to "attach" or "detach" methods either.
That's a good point Peter. Everything lives inside an object. Thanks for your comment.
Real world objects have both functionality (you can tell it to do something by calling one of its functions) and state (it stores data as attributes and relationships to remember what state it is in).
Real world objects also have lifecycles - we can try to simplify an application by pretending that real world objects don't have lifecycles but then you would be breaking Einstein's simplicity theorem which goes something like "Make things as simple as possible but simpler" i.e. not too simple that it's no longer correct!
Assuming objects are 100% immutable may satisfy our puritanical mathematical desires and fit nicely into "set theory" but it's just a theory that's best kept for the theoretical mathematics lectures at university - meanwhile, back in the real world, we need to cope with the fact that objects aren't always immutable and so we need to be able to write software that can represent thousands or millions of real world mutable objects and the interactions between them.
OOP allows you to encapsulate the functionality and the state of a real world object inside a software object that is defined by a class. It also allows incredible amount of reuse via inheritance (making sure, of course, that the correct balance of inheritance vs composition is always achieved).
In other words OOP is the most programatically efficient way to code if you want your software objects to be as close as possible to the real world objects that they represent.
Many developers love this concept and have discovered that OOP's ability to model real world objects via encapsulation, inheritance and polymorphism means that as their applications grow the complexity of the source code grows close to linearly instead of exponentially as with most other paradigms that came before and after it.
It is sounds good, but at the end of the day we are combined and inherit of some class, where we are hope ( have hidden part ) to solve our problem, but in a real world object never same as the picked one. Or in other example: we just want to make a documentation with code example, and some tricky reason - company are mandatory use excel and word for work. So we pick a word to make our document. Which is unreadable ( don't count how professional we are on word use ) because word separated our document to unified page sized, because that program is depend on old print to something to paper. Now we are try to save our planet and don't use paper for every uninformative documentation ( I hope ), but we are still using word. Why? because we just want a banane but get the whole jungle.
Think of a normal modern JS/TS codebase. E.g. any Next JS, Solid, Vue... whatever.
You'll probably find near to zero OOP, however you'll sure come across functions that are not exported, that act just as a helper of some other function, their reason to exist is solely to help other function within the same file.
You can, conceptually, refer to them as private functions, equivalent to a private method for all intents and purposes of this context. You won't be testing these, either.
As a rule of thumb, if the only reason to have the keyword "export" in a function is so you can import it for testing purposes, you're doing something wrong.
Easy way to explain it is that we don't test steps (functions/methods), we test the rigour of the algorithms (input A = output B) to ensure our software keeps working as expected, wether the algorithm has 2 or 95 steps is none of our business from the testing perspective.
This explanation is just to show an example of the same situation without involving the programming paradigm to avoid getting ourselves into the weeds here. These are two completely separated discussions.
Don't forget the WebComponent where you need to be use OOP pattern.
But what is the deep concern of private method in OOP? Maybe we would like to show just a minimal public interface to the outer word, and protect that function to called from out side. So technically enough to test the public part of our Object. Under Object development maybe we set protected method to public, so we can write a test for that. Later if our object are stable, we can move that part to protect. Or we can use Symbol key for that function which we don't want to use public, but these Symbol we share to test, but not for in our lib.
The method of Schrödinger 😂😂 No, don't do that, it just makes things more complicated for no reason. If you test all use-cases of your public functions/methods you're implicitly testing all the private ones at the same time and if not, the coverage will tell you exactly what you are missing.
Lastly I can't honestly consider web-components as part of the "modern" ecosystem. They're a standard API, yes, but a bad one nevertheless.
If you don't use framework, then WebComponent will be really handy. I created a markdown-viewer WebComponet which is part of my game development process, and that is fine. I try to skip using JS framework. Maybe check out my game development: dev.to/pengeszikra/javascript-grea...
But... why? There are JS frameworks literally created with game development in mind. Phaser, Pixi, Babylon, PlayCanvas... Or even Three.js if you want to toy around at a lower level.
If it's for learning purposes it's fine but if you're serious with your development and want to achieve a production-ready product... Why reinvent the wheel?
I am big fun of Mr. Doob. But Three.js for example are created 2010 so that is based on OOP pradigm, Phaser also. Each of these game engine are based on WebGL. But my initial ida is: the simple vanila HTML/CSS is much more useful to represent card game in 3D. Because on WebGL really hard to make a well formated text on 3D plane. Also problematic to make a simple card which rounded corner.
Please show me another card game, where you saw the deck as real 3D object maded by cards.
So that why I spend work to create a this way.
The state handling is also important to every complex game flow handling. My previous game used by react have much harder state management, compared to this one. Where I can use a one simple function with Proxy to handle my states, and that is working perfectly, because that state don't attach directly to a view as in React. So I can use my code even on server side also.
My last goal is to compare how large or small code/css need to be make for creating a this type of game.
Summary: I would like to pushing forward our way of working and thinking.
Please do create a new post with your discoveries and comparisons, I am looking forward to reading them all! 😁
thx, I will