Some advise on the following code
-
Hello I have the "following" code:
controller = Controller.BuildSingleRow(_sheet);
_animator = Animator
.WithStartupInfo(_controller, PlayMode.Normal, 1f);I have used a static method in the Controller class to setup some method of build pattern, I was going to use a constructor but a static instantiation won it for me. Is this bad to do this? Thanks :-D
-
Hello I have the "following" code:
controller = Controller.BuildSingleRow(_sheet);
_animator = Animator
.WithStartupInfo(_controller, PlayMode.Normal, 1f);I have used a static method in the Controller class to setup some method of build pattern, I was going to use a constructor but a static instantiation won it for me. Is this bad to do this? Thanks :-D
Seems OK, depends on the usage.
-
Hello I have the "following" code:
controller = Controller.BuildSingleRow(_sheet);
_animator = Animator
.WithStartupInfo(_controller, PlayMode.Normal, 1f);I have used a static method in the Controller class to setup some method of build pattern, I was going to use a constructor but a static instantiation won it for me. Is this bad to do this? Thanks :-D
Read up on static constructors [^]
Never underestimate the power of human stupidity RAH
-
Read up on static constructors [^]
Never underestimate the power of human stupidity RAH
I read through it and I can see how that would be useful however "perform a particular action that needs performed once only", I intended those methods to be used more than once and to increase the usability of the code. So when people see:
Controller.BuildSingleRow(_sheet);
They realise that it constructs the object set to a single row sprite sheet... It seems ok to me but im sure there is someone out there who would slap me in the face... :laugh:
-
I read through it and I can see how that would be useful however "perform a particular action that needs performed once only", I intended those methods to be used more than once and to increase the usability of the code. So when people see:
Controller.BuildSingleRow(_sheet);
They realise that it constructs the object set to a single row sprite sheet... It seems ok to me but im sure there is someone out there who would slap me in the face... :laugh:
It seems related to the Abstract Factory and Factory Method Design Patterns, but not as complex.
-
Hello I have the "following" code:
controller = Controller.BuildSingleRow(_sheet);
_animator = Animator
.WithStartupInfo(_controller, PlayMode.Normal, 1f);I have used a static method in the Controller class to setup some method of build pattern, I was going to use a constructor but a static instantiation won it for me. Is this bad to do this? Thanks :-D
It is not bad if there is a good reason why the 'constructor' shouldn't actually be a constructor in language terms. For example, if Controller is a pseudo-factory class that can actually build several different final classes in these methods, or the build methods need differentiation by name for clarity. If this is the only 'BuildXxx' method and it returns an instance of Controller, it should be a constructor (and the class should probably be named with the 'single row' aspect) – after all, that's what a constructor is, a static method that returns a new instance of the class, and people expect to instantiate classes that way. One small point to bear in mind is that any sort of reflection-based instantiation is not likely to find your static method. You may well not be doing any of that though.