Question

I’ve always been taught that if you are doing something to an object, that should be an external thing, so one would Save(Class) rather than having the object save itself: Class.Save().

I’ve noticed that in the .Net libraries, it is common to have a class modify itself as with String.Format() or sort itself as with List.Sort().

My question is, in strict OOP is it appropriate to have a class which performs functions on itself when called to do so, or should such functions be external and called on an object of the class’ type?

Answer 1

Great question. I have just recently reflected on a very similar issue and was eventually going to ask much the same thing here on SO.

In OOP textbooks, you sometimes see examples such as Dog.Bark(), or Person.SayHello(). I have come to the conclusion that those are bad examples. When you call those methods, you make a dog bark, or a person say hello. However, in the real world, you couldn’t do this; a dog decides himself when it’s going to bark. A person decides itself when it will say hello to someone. Therefore, these methods would more appropriately be modelled as events (where supported by the programming language).

You would e.g. have a function Attack(Dog), PlayWith(Dog), or Greet(Person) which would trigger the appropriate events.

Attack(dog)      // triggers the Dog.Bark event 
Greet(johnDoe)   // triggers the Person.SaysHello event 

---

As soon as you have more than one parameter, it won’t be so easy deciding how to best write the code. Let’s say I want to store a new item, say an integer, into a collection. There’s many ways to formulate this; for example:

StoreInto(1, collection)    // the "classic" procedural approach
1.StoreInto(collection)     // possible in .NET with extension methods
Store(1).Into(collection)   // possible by using state-keeping temporary objects

According to the thinking laid out above, the last variant would be the preferred one, because it doesn’t force an object (the 1) to do something to itself. However, if you follow that programming style, it will soon become clear that this fluent interface-like code is quite verbose, and while it’s easy to read, it can be tiring to write or even hard to remember the exact syntax.

---

P.S.: Concerning global functions: In the case of .NET (which you mentioned in your question), you don’t have much choice, since the .NET languages do not provide for global functions. I think these would be technically possible with the CLI, but the languages disallow that feature. F# has global functions, but they can only be used from C# or VB.NET when they are packed into a module. I believe Java also doesn’t have global functions.

I have come across scenarios where this lack is a pity (e.g. with fluent interface implementations). But generally, we’re probably better off without global functions, as some developers might always fall back into old habits, and leave a procedural codebase for an OOP developer to maintain. Yikes.

Btw., in VB.NET, however, you can mimick global functions by using modules. Example:

Globals.vb:

    Module Globals
        Public Sub Save(ByVal obj As SomeClass)
            ...
        End Sub
    End Module

Demo.vb:

    Imports Globals
    ...
    Dim obj As SomeClass = ...
    Save(obj)