Tell me what is the difference between your “abstract class” and general bp class to inherite from with the checkmark “abstract” = true (make you unable to use it in, only childs).
I understand the need in pure virtual functions/pure abstract class, to ensure in compile time you override the interfaces with unique implementation, but what you asking its just common parent with interface.
Where exactly can you say that an BP is abstract?
Edit: found it.
An abstract class is kind of both. Because you can implement functions directly and leave some function abstract.
The thing is that when using an interface, subclasses are not guaranteed to have methods implemented or even declared.
Yeah. Thats another pair of shoes.
Setting up an OOP inspired class hierachy is rather smooth, but refcatoring blueprint classes is a huge irritation in the rectal passage.
As you said, moving declrataions/implementations to the parent class breaks things for sure.
Thats where the BP system definitely need some love.
An abstract method in a class (its the method/function that is abstract, not the BP class), basically just “promises”/“requires” subclasses to have this method implemented with a common name/paramtere signature.
Say, I have a class, called “vehicle”. I add an abstract method called “Beep”.
In the subclasses “Truck”, “Bicycle” and “Car” I would override the Beep function. The implementation in the car class beeps like a car horn. The implementation in “Bicycle” rings like a bike bell and the implementation in the truck class operates the compressor and honks the horn.
Of course, i could have declared the functions in each class directly with no abstract ancestor.
The upshot of the abstract class is now that when I give the implementation job to three different developers, all implement the beep function.
Otherwise, the guy implementing the truck class calls the function “Honk”, the bicycle guy calls his function “RringRring” and the car guy “Meep”.
So, it helps with keeping names consistent across inherited class siblings.
And being “protected”, children can override, but the function is still hidden from the outside.
1 Like
Well, I found this topic because have the same problem. It looks like is difficult to maintain a OOP in blueprints.
So, looking the replys I don’t see how implement protected variables. I am going to make a public and follow a convention to make it a fake protected( I only will not call getters and setters in other blueprint).
This can be easy because it is a “personal only one programmer” project .
I don’t know why protected variables is a bad practice like someone wrote here…
I also stumbled on this topic while searching for a solution. After seeing that there is no easy way to set it up, I think I found a possible workaround.
You can create a private variable in parent BP and new functions that act as getter and setter that you can then set as protected (or, e.g., protected setter, public getter, if you want) that will access this private variable.
Just a note: I am not an experienced UE developer, so please feel free to share if there are any reasons I don’t see why it should not be used this way.
1 Like
Welcome to the community, what is it your trying to do when you notice this?
your workaround doesn’t seem like a terrible method
that said im also only a year or less into my journey on UE and 1.5yr or so programming in general
there’s likely a better method,
naming prefixes like putting _ seems fairly solid
you’d just wanna let the team know don’t modify anything with _ unless you know exactly how it works or //comment on both locations being modified to make a reference of sorts so somebody else knows what’s going on later