Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Without knowing the surrounding code, I'd suggest putting any construction logic in a factory object. If that's overkill, then I'd say your code is fine. Pulling it out of the loop and into a helper method is really just adding another layer of indirection which is not only harder to read, but it's also less efficient since you're introducing another method call on the stack.</p> <p>Using a factory object is good if your class is really not interested in how things are created, but rather just needs one or more instance of something. That way, the factory is responsible for the creation of the object and you get a nice separation of concerns.</p> <p>I wouldn't recommend creating a proxy structure that only has the purpose of setting the properties of your instance. I think it's an anti pattern because it favors inheritance over composition and it does so solely for the purpose of code re-use. But doing this means you're locking yourself to that specific implementation, which is likely not what you want. Just because your textfield <em>has</em> certain value, doesn't mean that it <em>is</em> a different type.</p> <p>This is how your code could look when using the factory pattern, first out, the format factory:</p> <pre><code>public interface FormatFactory { function getInstance():TextFormat; } public class TitleFormatFactory implements FormatFactory { public function getInstance():TextFormat { var format:TextFormat = new TextFormat(); format.size = 10; format.font = "Arial"; format.color = 0xfff200; return format; } } </code></pre> <p>Factories may or may not be parameterized:</p> <pre><code>public interface TextFieldFactory { function getInstance(text:String, position:Point, format:TextFormat):TextField; } public class TitleFactory implements TextFieldFactory { public function getInstance(text:String, position:Point, format:TextFormat):TextField { var title:TextField = new TextField(); title.selectable = false; title.wordWrap = true; title.text = text; title.x = position.x; title.y = position.y; title.setTextFormat(format); return title; } } </code></pre> <p>Lastly, this is how you'd use the code:</p> <pre><code>var formatFactory:FormatFactory = new TitleFormatFactory(); var titleFactory:TextFieldFactory = new TitleFactory(); var format:TextFormat = formatFactory.getInstance(); for (var i = 0; i &lt; arrThumbPicList.length; i++) { var position:Point = new Point(106, 331 + 55 * i); var title:TextField = titleFactory.getInstance(text, position, format); container.addChild(title); } </code></pre> <p>Besides being readable, a huge benefit is that you can now swap the implementations of the factories and thus changing what kind of components you're using, without having to change your actual logic. All you have to do is change the references to the factories.</p> <p>Also, by separating the concerns you make it easier to focus on one aspect of your code and thus run less of a risk of introducing errors and if you still do, those are often easier to spot and fix. More-over, it's much easier to unit test code when you separate concerns and more importantly, creation logic from business logic.</p>
 

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