This page contain information about Version 2.0 Alpha status, opinions, comments, results of the testing...

6 Comments

  1. Mixed use of arrays and typed Lists

    Methods sometimes use arrays as type for arguments and return value, and sometimes typed lists (List<T>). We should clarify if this has a purpose, or if not use only one style (typed lists).

  2. Add wildcard when using (Java) generics

    In Java to make the code more extensible it is better to add the ? wildcard when using generics. For example a List<IInputItem> can only contain IInputItems, but a List<? extends IInputItem> all IInputItems and subclasses of it.

  3. IElementSet modification

    Replace the methods:

    double getVertexXCoordinate(int elementIndex, int vertexIndex);
    double getVertexYCoordinate(int elementIndex, int vertexIndex);
    double getVertexZCoordinate(int elementIndex, int vertexIndex);
    double getVertexMCoordinate(int elementIndex, int vertexIndex);
    boolean hasZ();
    boolean hasM();
    

    With:

    public enum SpatialDimension { X, Y, Z, M }
    public boolean hasSpatialDimension(SpatialDimension dim);
    public double getVertexCoordinate(int elementIndex, int vertexIndex, SpatialDimension dim);
    
  4. Use interface for values instead of Object directly

    To increase flexibility yet keep some control over what is exchanged as values an interface should be used instead of working with a List<Object> directly (which can contain anything).

    For example this IValues interface:

    public interface IValues {
        public IExchangeDefinition getExchangeDefinition();
        public List<? extends Object> getValues();
        public void setValues(List<? extends Object> values);
    }
    

    Could be used in IOutputItem:

        public IValues getValues() {...}
    

    The definition of the IValues interface is part of the standard, so some methods developers can rely on to exist could be introduced. And the interface can be more easily changed and subclassed in an SDK when required.

  5. Separate the exchange definition from the exchange item

    Introduce an IExchangeDefinition interface to separate the definition of WHAT will be exchanged or is requested for, from the objects that contain the data (input and output items). The definition can also be included in the Values themselves (see my previous comment) to make them self-describing.

    public interface IExchangeDefinition {
        public IValueDefinition getValueDefinition();
        public ITimeSet getTimeSet();
        public IElementSet getElementSet();
    }
    
  6. Add the describesSameAs() method to the IExchangeItem interface, to avoid having to break the Law of Demeter when comparing two exchange items.

    public interface IExchangeItem extends IIdentifiable, IDescribable {
        public IExchangeDefinition getExchangeDefinition();
        public ILinkableComponent getComponent();
        public boolean describesSameAs(IExchangeItem otherExchangeItem);
    }