-1

If we consider a function foo depending on a and b. Would I then write a stateless function as follows:

MyClass

final b;

<returnType> foo(a) {...}

I am asking because foo would depend on the state of the MyClass-object. However, that state is final, and so foo will always return the same result for a given a.

Following the functional paradigm in a dogmatic way, i.e. letting functions only depend on their inputs/arguments, would mean that:

MyClass

<returnType> foo(a, b) {...}

Then, however, foo can be made static. So, would a dogmatic application of the functional style always lead to static methods?

Thank you!

chipsmonster91
  • 41
  • 4
  • 2
    If `b` is final, it can be used within `foo` without adding it as an argument. It *isn't* going to change. Whether you have `x -> x * PI` or `x -> x * 3.14` the difference hardly matters if `PI = 3.14` and it can never be different. – VLAZ Jul 26 '21 at 08:50
  • You can think of `this` (which you will either explicitly write or imply when you refer to the `b` field) in instance methods as the first parameter `foo`. This is sort of how it works in bytecode. It depends on what you think really, and what you think is "dogmatic". Voting to close as opinion based. – Sweeper Jul 26 '21 at 08:51
  • "*So, would a dogmatic application of the functional style always lead to static methods?*" yes but that would be because OOP doesn't model functional approach very well. `static` has a slightly odd place in OO design because it's an admittance that not only objects and their state matters. And function programming fully embraces that, so *technically* if you were to represent FP via OO, then pretty much all methods should be static. But that's because Java doesn't (really) have free functions. – VLAZ Jul 26 '21 at 08:52
  • @VLAZ Thank you. And that would also be ok if b is not a constant value like PI, right? It only matters that it is immutable. That means, I can instantiate MyClass with some b and then it would be ok? – chipsmonster91 Jul 26 '21 at 09:01
  • Slight caveat: just because a field is `final` doesn't mean that it represents a constant value. A very clear example would be a `final List x`: while you can't reassign a *different* `List` object to `x`, the *content* of the `List` can in fact change! For a truly constant value you'll need *both* a `final` field and an immutable type (such as `String`). – Joachim Sauer Jul 26 '21 at 09:15
  • @chipsmonster91 yes, I used Pi as an example. It could be anything else that will remain the same for the execution of the application. E.g., `final startTime` can record the time the application was started and would not change. Yes, next execution it would but we're interested in things that don't change *during* the execution. A more practical example might be a DB name that comes from config at startup. If you change the database, you need to restart but in the mean time it's always the same. – VLAZ Jul 26 '21 at 09:19
  • It's a `final` field, not a `static final` one, so its value may even be different for each instance of the class. – Hoopje Jul 26 '21 at 09:30

1 Answers1

1

Depending on the exact terminology, you could say that a dogmatic application of functional style always leads to static methods. However, in my view, dogmatically following some style is always a bad idea.

I would say, that in an object oriented programming language like Java, every method has an implicit additional parameter containing the this reference, that is, the reference to the object of which the method is called. If you adopt this view, then it is still "functional style" if you call non-static methods.

Note that you wouldn't even be allowed to call simple getters, otherwise.

Hoopje
  • 12,677
  • 8
  • 34
  • 50