Considering the entire point of public/protected/private encapsulation is to abstract the class so it's easy to use, why does the programmer also have to decide if a method is callable from blueprints? Shouldn't all public methods/variables be visible in blueprints?
How should I determine if a member should be visible in blueprints? Should I only add the macro when they're strictly needed? Should I aim to make blueprint interfaces even more abstract than the corresponding C++ interface?
Shouldn't all public methods/variables be visible in blueprints?
The point of encapsulation is not only ease of use, but also to decouple parts to create a more robust and maintainable system. The idea to only expose certain parts of your code to others has proven to be one of the best practices in software development, so I think it is only natural for EPIC to unclude such a mechanism into their c++-blueprint system.
The other reason I can think of is that the Unreal Engine was built to be used in really big dev teams, with a lot of code. And maybe it is only me, but I find the "create a new blueprint node" popup very cluttered as it is. Adding hundreds of additional variables and methods might not be a good idea.
How should I determine if a member should be visible in blueprints? Should I only add the macro when they're strictly needed?
I don't think there is a general answer to that, just do what feels right for you and your team. I personally try to only expose stuff to blueprints or c++ if it is absolutely needed, but sometimes I expose my stuff anyway out of lazyness ;)
