Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>OK, there are a few things to cover here.</p> <p>First: why do you need to express commonality between <code>PointLight</code> and <code>Spotlight</code>? Is it </p> <ol> <li>Because there are clients who simply want to use them as a <code>Light</code>, and don't care which variety they get?</li> <li>Because they share some implementation and you don't want to duplicate?</li> </ol> <p><strong>Because Clients need to treat Lights uniformly</strong></p> <p>This is Interface inheritance, also known as subtyping. Composition doesn't apply here - because there's nothing to compose. You can realise this in two ways: which you choose depends largely on your language.</p> <ul> <li>If you're using Java/C# this would usually be achieved by defining an Interface (<code>ILight</code>) that exposes all the common characteristics of Lights. Clients would depend only on the interface, not the implementations of it. <code>PointLight</code> and <code>SpotLight</code> would each implement the interface.</li> <li>If you're not using a language with first class Interfaces, declare Light as an abstract base class with <code>PointLight</code> and <code>SpotLight</code> inheriting from it.</li> </ul> <p><strong>Because you want to share implementation</strong></p> <p>There are generally two approaches to achieving this:</p> <ul> <li>Implementation inheritance. Define class <code>Light</code> and implement common behaviour in it. Declare <code>PointLight</code> and <code>SpotLight</code> as inheriting from <code>Light</code>, overriding/adding behaviour as required.</li> <li>Composition. Define classes <code>PointLight</code> and <code>SpotLight</code> without inheriting from a common superclass. Implement a third class (which you'd still probably call <code>Light</code>) that implements the common behaviour. Both <code>PointLight</code> and <code>SpotLight</code> would include an instance of 'Light` and delegate to it for the shared behaviour.</li> </ul> <p>For your specific example there's relatively little to choose between Implementation inheritance and Composition. Issues with the former arise when the inheritance hierarchy gets deeper. It's also notoriously error prone in languages that support multiple implementation inheritance (e.g. the fragile base class problem). On the other hand, Implementation inheritance means less typing: the language autoamtically delegates to the shared behaviour, whereas with Composition you need to write the delegation methods.</p> <p><strong>Summary</strong></p> <p>Note also the above are not mutually exclusive: you could, for example:</p> <ul> <li>Declare an Interface <code>ILight</code> that both <code>SpotLight</code> and <code>PointLight</code> implement</li> <li>Share common behaviour using either implementation inheritance or composition</li> </ul> <p>Fundamentally you need to be clear what you're trying to achieve. </p> <p>hth.</p>
    singulars
    1. This table or related slice is empty.
    1. POGame engine design choice
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USsfinnie
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POGame engine design choice
      singulars
      1. PTQuestion
    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
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for a great answer! I think my main taught about this was to achieve a bit of both from your main points. Lights are treated equally in a container, and I want to share some implementation between the lights, methods like set_position() for example.
      singulars
      1. PO
      1. USMorgan Bengtsson
    2. CONo worries. Shout if you need more info.
      singulars
      1. PO
      1. USsfinnie
 

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