Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think you should design this by interface contract.</p> <p>I would make your walls, robots and sensors be implementations of various 'things' the UI needs to know about. Only those interfaces should be shared between the UI and your Model.</p> <p>For example, Robot, Sensor should implement an interface called Printable:</p> <pre><code>public interface Printable { Shap getShape(); } </code></pre> <p>Wall should implement an extended interface PrintableTexture</p> <pre><code>public interface PrintableTexture extends Printable { Texture getTexture(); } </code></pre> <p>You could also create and implement data provider type interfaces for angle, direction, etc.</p> <p>For example:</p> <pre><code>public interface RangeProvider { Range getRange(); } public interface DirectionProvider { Direction getDirection(); } public interface SensorProvider { Sensor[] getSensors(); } </code></pre> <p>The main point is that the 'printing' code would then check for what interfaces are implemented by the Printable object (or list of Printable objects) that has been passed to the it and react appropriately.</p> <p>Looking at your comments, I think that PrintableRobot, PrintableWall, etc is a misunderstanding of the fundamental concept of what an interface is. An interface should be more about 'what something provides or how you can use it' versus a concrete implementation of how this is achieved. By putting Robot, Wall, etc in Printable you are giving an indication of implementation.</p> <p>This aside, have you considered the <a href="http://en.wikipedia.org/wiki/Visitor_pattern" rel="nofollow">Visitor Pattern</a>?? You could have each entity implement the accept part of the visitor pattern and have your printing code be a special implementation that only takes what it needs out of a deeper knowledge of what each entity does.... It's not what I would do, but it may suit you...</p>
    singulars
    1. This table or related slice is empty.
    1. POSimplest Way to Hide Part of a Class' public methods/Interface
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USAdrian Regan
    1. USAdrian Regan
    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. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks. I have tried your first suggestion. However, due to each component (Robot, Wall & Sensor) having different properties that are relavent for printing (Robot has a getDirection and Sensor has getRange), I end up having a Printable interface for each: PrintableRobot, PrintableSensor, etc as seen in the bottom of the diagram. I'm not sure if this is good or not.
      singulars
      1. PO
      1. USKevin
    2. COYou could look at the Visitor Pattern, I'll modify my post...
      singulars
      1. PO
      1. USAdrian Regan
    3. COI reasearched and experimented with the visitor pattern. However, I came to the conclusion that the visitor pattern's function is to add functionality to classes, but have this functionality reside in another 'visitor' class. It does not hide the non-GUI methods from the GUI code (the visitor will have a reference to a Robot). Having said that, I will keep the visitor pattern in mind, as I can see how it is applicable to this problem. Thanks.
      singulars
      1. PO
      1. USKevin
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

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