0

What is the stand on initiating the class from its own static method? Are there any good practices about this?

I feel need of initiating a class from its static method while implementing a job scheduler as a backend of a GUI application. I can always make a util method instead of static method but realized i do not have a strong opinion on this.

What principles i should follow on this?

closed as too broad by JimmyJames, BobDalgleish, Robert Harvey Jun 20 at 18:29

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • I am curious why object-oriented design concerns are broad for software engineering stackexchange. – CanCode Jun 20 at 20:20
  • I would say this is on the line of too-broad; i.e. any given answer-er will be forced into using scope limiting assumptions. – esoterik Jun 20 at 22:31
3

Do you mean having a static factory method on the class itself? This is a pattern used in various places, usually combined with a private constructor so that the class can only be created via the factory method.

A case I've often seen it used for is where a class can be created in different ways that are insufficiently explicit from constructor parameters alone; it works quite well for that. Another is situations where creation can fail, although in that case a separate factory is also an option and may be better.

An example of what I'm talking about:

public class Result<TData, TError>
{
    public bool Succeeded { get; }
    public TData Data { get; }
    public TError Error { get; }

    public static Result<TData,TError> Success(TData data) => 
        new Result<TData,TError>(true, data, default(TError));

    public static Result<TData,TError> Failure(TError error) => 
        new Result<TData,TError>(false, default(TData), error);

    private Result(bool succeeded, TData data, TError error)
    {
        Succeeded = succeeded;
        Data = data;
        Error = error;
    }
}
  • So basically, "It exists"? – Robert Harvey Jun 20 at 18:29
  • Pretty much; it's not a very complex pattern. OP seemed uncertain whether it was legitimate to use, so figured I'd mention it's not that uncommon. – Errorsatz Jun 20 at 18:31
  • "Common" is overrated. – Robert Harvey Jun 20 at 18:31
  • Would you say it's a bad pattern? I can see it being questionable for cases where the factory is doing heavy lifting, but for something like DateTime it's pretty suitable. – Errorsatz Jun 20 at 18:33
  • 1
    You've written a very simple discriminated union (DU). The key thing is that it is a well behaved DU as it is immutable. Using static factories, rather than constructors, completely makes sense in such scenarios. Static factories fail horribly though the moment either the factory or the resultant object has mutable state, or worse external side-effects. And that, @CanCode, is the principle you should use here: only use statics for side-effect free, immutable code. – David Arno Jun 20 at 22:31

Not the answer you're looking for? Browse other questions tagged or ask your own question.