Note that there are some explanatory texts on larger screens.

plurals
  1. POScala the default way to create objects that require a complex construction process
    primarykey
    data
    text
    <p>I think its always useful to know the default practices that the language designers intended, and the default practices towards which they target language improvements, even if one later deviates from those conventions. In Scala all fields have to be initialised in the constructor of the class they're declared in. This is a a significant restriction. Secondary constructors are also restricted. Any temporary variables in a constructor need to be placed in an inner method or closure, to avoid unwanted fields, which can make the body of a constructor look messy. All this militates against using constructor bodies. The override val/var syntax needed even when assigning to abstract variables from a super class remove some of the advantage of using derived classes for the sake of construction.</p> <p>A companion object has access to all the fields of its class. However for construction this is not the advantage that it might first appear, as all fields must be initialised in the constructor of the class. So it would seem the natural practice is to use a method in an object to do any processing of the classes variables, creating a temporary mutable collection for each immutable collection in the class, listbuffer being the default and then pass all the values and collections into a bodiless constructor. The factory can be in any object or even class but might as well be in the companion object unless there's a good reason otherwise. Objects can't take type parameters but their factory methods can if needed. And of course you can have as many factory methods as you need quasi-constructors and they can reuse any common algorithms.</p> <p><strong>Is this correct?</strong></p> <p>In response to the request for an example, here's a constructor I'm in the process of porting across to Scala from C#, note the multiple type parameters are gone in Scala:</p> <pre><code>public class GridC : GridBase&lt;HexC, SideC, UnitC, ISegC&gt; { public Geometry&lt;HexC, SideC, UnitC, ISegC&gt; geomC { get; private set; } internal GridC(Scen scen, int gridNum, int xDim, int yDim, int xOff, int yOff, Terr terr = Terr.Plain): base(gridNum, scen, 10.0) { this.geomC = scen.geomC; xIntLeft = xOff + 1; yIntBottom = yOff; xIntRight = xDim * 2 + 1 + xOff; yIntTop = yDim * 2 + 2 + yOff; Coodg hexCoodg; for (int x = xOff; x &lt; xDim * 2 + xOff; x += 2) { for (int y = yOff; y &lt; yDim * 2 + yOff; y += 2) { if (x % 4 == y % 4) { hexCoodg = new Coodg(num, x + 2, y + 2); HexC hexC = scen.hexCs.NewHexC(hexCoodg); SideC sideC; MiscStrat.sixDirn.ForEach(i =&gt; { Coodg sideCoodg = hexCoodg + Cood.DirnTrans(i); sideC = sides[sideCoodg]; if (sideC == null) scen.sideCs.NewSide(hexC, i); else scen.sideCs.SetHex2(sideC, hexC, i); }); } } } } </code></pre> <p>The above sub class is created purely to provide a constructor for the following base class edited just to show the parts relevant to construction;</p> <pre><code>public class GridBase&lt;HexT, SideT, UnitT, SegT&gt; : IGridBase where HexT : Hex where SideT : Side where UnitT : Unit where SegT : ISeg { public int num { get; private set; } int IGridBase.num { get { return num; } } IListsGeom&lt;HexT, SideT, UnitT&gt; iLists; public HexList&lt;HexT&gt; hexs { get { return iLists.hexs; } } public SideList&lt;SideT&gt; sides { get { return iLists.sides; } } public Geometry&lt;HexT, SideT, UnitT, SegT&gt; geom { get; private set; } public int xIntLeft { get; protected set; } public int xIntRight { get; protected set; } public int yIntBottom { get; internal set; } public int yIntTop { get; internal set; } public double scale { get; private set; } protected GridBase(int num, IListsGeom&lt;HexT, SideT, UnitT&gt; iLists, double scale) { this.num = num; this.iLists = iLists; this.scale = scale; } } </code></pre> <p>The constructor creates a simple uniform Hex grid. Other constructors were required that used a completely different algorithm and others will be created that require a related but more complex algorithms. I'm not an expert but my impression is that factories are used a lot less in C#.</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.
 

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