There are a fair number of principles being violated here that have nothing to do with SOLID. Understand that SOLID isn't a comprehensive list of every useful principle. Even Uncle Bob himself has published principles beyond SOLID that are worth considering.
You have indicated that you only want to focus on SOLID violations but that narrow view is causing confusion about ISP.
Specifically, does it make sense to ask for
fur_color in your only client:
The principle in play here is abstraction. Does the
pet_printer client have the right to not know exactly what pet it's printing? Can it require that pet types do the heavy lifting here?
Well abstraction isn't a SOLID principle but it's still a good one. If you were following it then you wouldn't be asking to know the type of pet you have and
pet_printer could ask for
fur_color and sometimes get "Not Applicable" as a result. This value rejects the assumption that all pets have fur without forcing you to change the question. Such values have a long tradition in computer science and mathematics. It's why we have numbers like zero and negatives.
Do that and every pet subtype can answer the question of fur color. Thus clients asking about fur color don't have to know the subtype.
If that doesn't satisfy you then you need to dive deeper into what your client is doing. It's trying to print a pet. It's getting confused because it's trying to deal with subtype specific details that it doesn't know without asking about subtype.
Clients that do that violate an OOP principle that it should be easy to add new types without changing old code. That runs you into a SOLID principle called Open Closed Principle (OCP). This is a fancy way to say it sucks to have to change old, tested, battle proven code to add something new.
A design that lets you add
parrots without changing
pet_printer would be preferable.
The worst violation of this is your
print_pet_type method. I'm not saying switches are evil but why are you building a type hierarchy and then not using it? Give each pet a
type method and your switch can go poof. Now
pet_printer doesn't have to know if
I would strive for a design that would leave pet printer knowing as little about the pet as possible and allow it to focus on how it's printing: to the console, to a log, to paper, to the screen...
Do that and your ISP principle issue falls away because the
pet_printer doesn't know what fur is. The subtype decides if it's going to say anything about fur when it gets asked what details need to be printed.
Don't follow SOLID in a vacuum. The SOLID principles rest on the backs of older principles. Without them SOLID is a lot of pointless confusion that happens to spell a spiffy sounding word.