Is there some literature on this type of programming?

Question

In college I took on a class on modern physics, in which we learned about special relativity. I was completely blown away by how different frames of reference could actually ob

Answer 1

It seems to me like you're implementing functional programming in an OOP way. Regardless of the Physics explanation about "special relativity" , The entire idea of OOP is basically encapsulation - You want to objects to know themselves how everything should be done. Basically what you're saying here is "no , there is only data and functions that work on the data" . What if the deck changes? you get a new Dealer? how will you know which dealer should be created to deal the new deck?

If you thought about a "switch" statement , then you're hammering OOP concepts into a functional programming template.

Answer 2

This design pattern can work well, particularly if the operations do not mutate the original data objects. In .NET, for instance, LINQ and its associated extension methods can be seen as general operations for dealing with enumerations, so that the enumerations themselves do not need to know how they may be used. The methods do not, however, mutate the collections being enumerated, but merely provide a new way to interpret, filter and group the enumeration.

If the functionality is mutating the original objects, however, then I tend to prefer that functionality to be encapsulated as methods on the object. That way the object is responsible for maintaining its own invariants and you insulate more of the implementation details from the clients of the object. The more implementation detail you must leak in order to work with the object, the more opportunity there is for it to be used incorrectly and cause bugs.