Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think that you should also consider how the collections are going to be used and how the data is obtained:</p> <ul> <li>If they are simple result sets to be displayed on a page (for example), then using standard collections seems reasonable - and you can then use lots of standard libraries to manipulate them.</li> <li>On the other hand, if they are mutable and any changes need to be persisted (for example), then encapsulating them within your own classes might be preferable (which can then write changes to databases, etc).</li> </ul> <p>How do you get and persist your data? If it is stored in a database, then maybe you can use SQL to select LastConnections by customer and/or service and/or month, rather than having to maintain the datastructures yourself (and just return simple lists or maps of connections or counts of connections). Or maybe you don't want to run a query for each request, so do need to keep the whole datastructure in memory.</p> <p>Encapsulation is generally a good thing though, particularly as it can help you to adhere to the <a href="http://en.wikipedia.org/wiki/Law_Of_Demeter" rel="nofollow noreferrer">Law of Demeter</a> - maybe you can push some of the operations that you will perform on the collections back into the AllConnections class (which is effectively a DAO). This can often help unit testing.</p> <p>Also, why is extending HashMap considered evil here, considering that you only want to add a trivial helper method? In your code for AllConnections, AllConnections will always behave in the same way as a HashMap - it is polymorphically substitutable. Of course, you are potentially locking yourself into using HashMap (rather than TreeMap, etc), but that probably doesn't matter since it has the same public methods as Map. However, whether you would actually want to do this really does depend upon how you intend to use the collections - I just don't think that you should automatically discount implementation inheritance as <em>always</em> bad (it just usually is!)</p> <pre><code>class AllConnections extends HashMap&lt;String, CustomerConnections&gt; { public LastConnection get(String custId, String srvUrl) { return get(custId).get(srvUrl); } } </code></pre>
    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. 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