Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <blockquote> <p>1.a. Make methods static and call (by all classes and concurrent threads) directly as MyMethods.someMethod();</p> <p>1.b. Make methods non-static and at the time to call them, instantiate the whole class by MyMethods mm = MyMethods(); mm.someMethod();</p> </blockquote> <p>The choice between these two depends on the functionality of <code>MyMethods.class</code>. If <code>MyMethods</code> is supposed to be stateless then it's a good approach to go with <code>static</code> methods. Otherwise, if one method call depends on another and <code>MyMethods</code> have states (i.e. non-final fields) then use the second option.</p> <blockquote> <p>Use Strategy pattern stated at <a href="https://en.wikipedia.org/wiki/Strategy_pattern" rel="nofollow">https://en.wikipedia.org/wiki/Strategy_pattern</a> (code attached here with).</p> </blockquote> <p>Use this pattern if <code>MyMethods</code> are to be extended with different classes for different purposes and if you select which code to run depending on your context. As the <em>wiki</em> says, if you the algorithm to be used is not known before the runtime (depends on some conditions) this is the way to go. According to your specification of <code>MyMethods</code> you do not have such problems. </p> <blockquote> <p>Use dependency injection stated at <a href="https://en.wikipedia.org/wiki/Dependency_injection#Java" rel="nofollow">https://en.wikipedia.org/wiki/Dependency_injection#Java</a></p> </blockquote> <p>Same answer as above. The thing with <em>dependency injection</em> is in <em>inversion of control</em>. A class that uses <code>MyMethods</code> does not know about actual the implementation of <code>MyMethods</code>, but the injection of real implementation is delegated to some higher-level authority. It abstracts external dependencies from the context where it is going to be used. Again, if <code>MyMethods</code> are to be stateless and constant (not planned to change, and the behavior of methods within the class does not depend on the context where they are used) you do not need these patterns as it would just mean over engineering.</p> <p>I would conclude that you should use <em>Strategy</em> or <em>DI</em> pattern if logic of <code>MyMethods</code> depends on the context from which they are run. If this is constant (e.g. Java's <code>Math</code> class does not care who or in what context someone calls <code>sqrt()</code>, <code>max()</code> or <code>pow()</code>) then static methods are the way to go.</p> <hr> <p>Regarding problems:</p> <p>Problems you stated are not present when you use <code>MyMethods</code> with <code>static</code> methods. You will have to test whether your methods return correct values for particular arguments and that's it. I don't believe that there would be much more trouble testing actual implementation of <code>Strategy</code> in <em>Strategy pattern</em> or implementation of interface that are injected through <em>Dependency injection</em>. What might be harder is testing the classes that use strategy because sometimes it's not easy to recreate the context in which particular strategy will be executed as it often depends on user input, but it's definitely not impossible. Dependency injection is, as far as I'm concerned, great for testing because you can separate unit under test from dependency which you can easily mock.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload