3 ms·

The Hit class may be a Singleton and only instantiated once. Creating a class is like 3 actual lines. Also at least in Java the Hit class can be an inner class

The Hit class may be a Singleton and only instantiated once. Creating a class is like 3 actual lines. Also at least in Java the Hit class can be an inner class of the Person class. It just feels like name spacing in that case. It is needless complex if the code is simple. This solution is more flexible that just a pure function. If you have different players who use different hit strategies how do you handle that with just a pure function? Lots of if statements in the function? Passing in lambdas in every case you call the function? Then you could curry the function and call it something different too and that works I guess. OOP shines when you have lots of different ways things can work in different combinations. OOP is a tool like other programming paradigms, you use it when it solves your problem better than the other ways.

geofft 8y ago
Ultimately the answer is to use a language in which passing a function reference is as easy as writing a singleton that implements an interface and passing a reference to that. (Or easier—in any language with decent function-passing support, writing a function and referencing it is generally going to be easier because fewer things are happening.) OO makes sense if the different types of behavior map to object identities and inheritance trees, because it generates a chain of implicit if statements that capture this logic. If they don't—e.g., a hit changes behavior depending on whether the attacker is proficient in the weapon, rather than depending on the weapon class or attacker class itself—you're likely better off writing the if statements yourself.
gameswithgo 8y ago
Languages that force you to use the singleton pattern really ought to just let you write A FUNCTION
- jryan49 8y ago
  A lot of OOP languages have added method references, and lambdas in this day and age.
abernard1 8y ago
> If you have different players who use different hit strategies how do you handle that with just a pure function? Lots of if statements in the function? Passing in lambdas in every case you call the function? I'll list a few strategies I've seen in different contexts: 1) Clojure has "protocols", which is a strategy of doing polymorphism where the verb is charge instead of the noun. 2) Rust has trait objects, where you have to implement the polymorphic behavior you want for a separate player type but the data is separate from the behavior and not interlinked or owned by the class. You can implement the behavior in the scope of the module where it is used. 3) You already mentioned this, but lambdas in Javascript or functors in C++ satisfy a lot of specialization requirements. All 3 of these approaches are different ways of approaching the problem of different behavior on the same data. The key thing with them is that it allows domain specific behavior to be decoupled from an owning object. There may be reasons that OO is more suited to a problem (as you mention), but I tend to agree with the author's post around the dogma of using OO everywhere. In the article, the author also mentions a quote around encapsulation > Encapsulation is an object-oriented programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. In my opinion, this view of binding the data and behavior together stems from an idea that data is scary and can be changed at any time. In an immutable, pass-by-value, functional world, those getters and setters and indirection is just another thing in my way from composing the data together with collections tools I am very familiar with. I think it was Neal Ford who said that "OO encapsulates moving parts, whereas functional programming removes moving parts." I think that's very appropriate in this context. In a data-first view, you model what properties and data shapes you care about in your records, and then you create little functions that connect those things together; in OO, you create the links first through methods (even if those have interfaces), and you're stuck with those connections anywhere you want to pass the object.

geofft 8y ago

Ultimately the answer is to use a language in which passing a function reference is as easy as writing a singleton that implements an interface and passing a reference to that. (Or easier—in any language with decent function-passing support, writing a function and referencing it is generally going to be easier because fewer things are happening.) OO makes sense if the different types of behavior map to object identities and inheritance trees, because it generates a chain of implicit if statements that capture this logic. If they don't—e.g., a hit changes behavior depending on whether the attacker is proficient in the weapon, rather than depending on the weapon class or attacker class itself—you're likely better off writing the if statements yourself.

gameswithgo 8y ago

Languages that force you to use the singleton pattern really ought to just let you write A FUNCTION

jryan49 8y ago
A lot of OOP languages have added method references, and lambdas in this day and age.

abernard1 8y ago

> If you have different players who use different hit strategies how do you handle that with just a pure function? Lots of if statements in the function? Passing in lambdas in every case you call the function? I'll list a few strategies I've seen in different contexts: 1) Clojure has "protocols", which is a strategy of doing polymorphism where the verb is charge instead of the noun. 2) Rust has trait objects, where you have to implement the polymorphic behavior you want for a separate player type but the data is separate from the behavior and not interlinked or owned by the class. You can implement the behavior in the scope of the module where it is used. 3) You already mentioned this, but lambdas in Javascript or functors in C++ satisfy a lot of specialization requirements. All 3 of these approaches are different ways of approaching the problem of different behavior on the same data. The key thing with them is that it allows domain specific behavior to be decoupled from an owning object. There may be reasons that OO is more suited to a problem (as you mention), but I tend to agree with the author's post around the dogma of using OO everywhere. In the article, the author also mentions a quote around encapsulation > Encapsulation is an object-oriented programming concept that binds together the data and functions that manipulate the data, and that keeps both safe from outside interference and misuse. In my opinion, this view of binding the data and behavior together stems from an idea that data is scary and can be changed at any time. In an immutable, pass-by-value, functional world, those getters and setters and indirection is just another thing in my way from composing the data together with collections tools I am very familiar with. I think it was Neal Ford who said that "OO encapsulates moving parts, whereas functional programming removes moving parts." I think that's very appropriate in this context. In a data-first view, you model what properties and data shapes you care about in your records, and then you create little functions that connect those things together; in OO, you create the links first through methods (even if those have interfaces), and you're stuck with those connections anywhere you want to pass the object.