Is using reflection considered unOOPish?

Question

What are the risks of using reflection? Does it go against OOP in any way?

I started using it lightly in a C# project and now I find it practical in many scenarios.

Thank you.

Answer 1

To answer the question in the title: no, not a priori. For example, reflection can be extremely handy when implementing factories to create objects of different (but related) types.

However, these are all implementation details and they should generally be hidden behind a general interface. Reflection also tends to be quite slow so overuse is discouraged. Basically, use it when there's no other (good) solution, and nowhere else.

OOP doesn't really contest with reflection in general. But don't try to implement dynamic dispatching or listeners/callbacks using reflection when OOP would be adequate.

Answer 2

OOP is a technique and a structure, not a religion.

You're not going to be sinning by failing to use it in your project. If you know a better way, go for it. Judicious use of reflection can save you a lot of complexity.

Just make sure it's clean and readable so your teammates don't crucify you. Reflection is powerful, but with great power comes great responsibility, etc.

Answer 3

Normal OO languages like Smalltalk have reflection. People using it consider languages without it practically unusable. Being able to reason at run-time about a program is essential for larger systems.

Answer 4

Reflection can break encapsulation and create coupling between a class and the internal implementation of another class. Used wrongly it can lead to poor OO design, but that's not the same as being not object-oriented. In some respects, it can also be used to implement things that traditional OO code has trouble with, like AOP (aspect-oriented programming). A purist might see this as non-OOP, though I would consider it to be a superset relationship.

Some places that I find reflection to be handy:

• unit testing, accessing internal state to setup or verify data
• attributes, both accessing attribute values and accessing object properties from the attribute
• property validation - writing common validators for various property types
• consuming/converting anonymous types

Except for unit testing, typically I only reflect on public properties/methods so as not to break encapsulation and create coupling to internal implementation.

Answer 5

It depends on what you're doing with reflection... I've used it a lot to enumerate public APIs, and in Java (through the introspection libraries) to do useful things with JavaBeans. Used thoughtfully it's very useful.

I think that issues arise not necessarily when you start using reflection, but when you use it to break encapsulation - peering inside objects to observe and modify otherwise hidden internal state. Unless you're careful tight coupling and fragility can quickly spread through your classes once encapsulation is broken.

Answer 6

All OO programming languages support reflection to a lesser or greater extent. Some encourage its use ( e.g. Smalltalk, at one end of the spectrum) and some discourage it ( e.g. C++, at the other). The relative frequency of use of those two languages to implement the software you use every day may tell you something about the desirability of making heavy use of reflection.

Please note this is not an attempt to start a language war - I am actually something of a Smalltalk fan & intend to do some Squeaking later on this evening.

Answer 7

I'm pro-reflection any time that interfaces just aren't cutting it for you, maybe because of an unforeseen change or because things are just too complicated to specify that rigidly. Keep in mind that duck typing in languages like Python is implemented by what amounts to reflection. You can a method by name only, and it either works or throws. I view reflection as a backdoor to duck typing in a statically typed language. IMHO, unless you believe that duck typing is fundamentally wrong and would never use it, there's nothing wrong with reflection provided the code in question isn't performance-critical.