Using Decorator to create a Dataset class

I've used Decorator to create a Dataset class used to build a Dataset Basic Empty (ConcreteComponent) and Iris class (ConcreteDecorated) used to populate it.


Decorator allows a user to add new functionality to an existing object
without altering its structure

For example, Iris has a its own way to load and store the data in a dataset structure. I've also added the name features to track the string name of their features.

My purpose is to add more ConcreteDecorator, like Iris, that they have a own way to load and store file/data and to track the name features. The code runs, but my "doubts" is that a dataset is an empty table (define only the data structure) and the population depends on a concrete decorator that uses it. It seems to me that does not respect the SOLID principles (for example DIP). What do you think about this simple implementation?

Component

public interface Dataset
{ 
    public double Distanza(int i, ArrayList centroide);     
    public double getCella(int i, int j);
    public void inizializzaTabella();   
    public void stampaDataset();
    public void setColonna( ArrayList colonnaValori);
    public ArrayList> getTabella();
    public int getnFeature(); //ok
    public int getnRecord() ;
    public void setnFeature(int nFeature); 
    public void setnRecord(int nRecord);    
    public void setTabella(int Colonna, Double Valore); 
    public String getNomeDataset(); 
    public void setNomeDataset(String nomeDataset);
    public double[][] toMatrix();
    public ArrayList getFeatureUsate(); 
    public void setNomiFeature(String[] nomiFeature);

}

Concrete component

```
public class DatasetConcreto implements Dataset
{
private int nFeature;
private int nRecord;
private ArrayList featureUsate; // quelle selezionate
private String nomeDataset;
private String[] nomiFeature;

//public double Tabella [][];
private ArrayList> Mat;

public double Distanza(int i, ArrayList centroide)
{

The interface

Only some small hints: You are using ArrayList but a List, Collection or a Set is more open for extensions (D and O in SOLID). The interface is a big one, nFeature and nomeDataset should have its own interface (I in SOLID). Using setTabella you can add a null-value but toMatrix can not return a null-value, this breaks the SVOT (S and L in SOLID).

The implementation

Only some small hints: You have a list (A singular) of lists (B plural) but the lists (B plural) can have different lengths. If the columns length of row1 differ from the length in row2 you can not say if row1 or row2 tell the truth - this breaks the SSOT (S in SOLID) - at least when you use the toMatrix() you have to decide who tell the truth and it is more than a function to a matrix.

The decorator

Only one hint: A decorator decorates exactly one object but the field to store the dataset is not final, you can switch the object, you modify the decorator what is not allowed (O in SOLID).

I stop right now because I think it is a little bit more than small hints :)

EDIT: Do not be confused, S in SOLID means SRP(!) and SVOT and/or SSOT is a decision what kind of SRP to use.

StackExchange Code Review Q#154241, answer score: 4