0
\$\begingroup\$

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?

\$\endgroup\$
2
\$\begingroup\$

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 ;)

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.