On 7/3/21 11:01 AM, Bonita Montero wrote:
>>> If you're doing a dynamic_cast you're switching upon the type of the
>>> class. This switching should be better done inside the class with class
>>> -dependent code - with a virtual function call.
>
>> Wrong. Application level logic should stay in the application level
>> code. That is the only scalable option.
>
> Virtual function calls are more scalable.
Wrong, the NUMBER of functions needed grows way to fast to be scalable.
It also requires GLOBAL changes in API to implement local algorithms.
The act of adding the function could well require recompiling millions
of lines of code over many applications if the base class is commonly use.
Imagine what would happen if someone decided that string needed a new
function that made ALL code that uses it to need to be recompiled. This
is an X.0.0 type of change.
>
>>>> As an example, say you have a collection of animals, and you want to
>>>> extract all the dogs out of it. You could add to Animal and Dog an
>>>> isDog
>>>> function, (and then need to change Animal again for each new type of
>>>> thing you might want get, lousy encapsulation) or you can use a
>>>> dynamic_cast to check if this animal is a Dog.
>
>>> the isDog-function would be faster.
>
>> But then it also needs isCat, isHorse, isSnake, isMammel, isReptile,
>> and so on.
>
> Maybe, but that's much faster. Dynamic downcasts are slower.
>
>> The virtual function method says that you need to change Animal EVERY
>> TIME you define a new type of animal for the system. This breaks
>> encapsulation, ...
>
> No, it is encapsulation.
No, it BREAKS encapsulation. If adding a new type of animal requires a
change in the animal base, the base is not properly encapsulated.
Note, the RTTI interface that is provided built into C++ provides that
encapsulated interface that allows you to detect this without needing to
make these changes.