One fundamental object oriented concept is:
an object is asked to perform a pre-defined activity
it chooses to do that activity in a slightly different way depending on what kind of object it is.
The following code is not object oriented, due to all the hard coding of special if cases for each type of property.
for (int i = 0; i < properties.length; i++)
{
Property property = properties[i];
ShapeProperty propertyType = property.getPropertyType();
if (propertyType == ShapeProperty.LENGTH)
{
length = property.toString();
attributes.put(BoxTag.IMAGE_LENGTH, new LengthBoxTag(length));
}
else if (propertyType == ShapeProperty.WIDTH)
{
width = property.toString();
attributes.put(BoxTag.IMAGE_WIDTH, new WidthBoxTag(width));
}
else if (propertyType == ShapeProperty.DEPTH)
{
depth = property.toString();
attributes.put(BoxTag.IMAGE_DEPTH, new DepthBoxTag(depth));
}
else if (propertyType == ShapeProperty.ROTATION)
{
degrees = property.toString();
attributes.put(BoxTag.IMAGE_ROTATION, new RotationTag(degrees));
}
else if (propertyType == ShapeProperty.BITMAP)
{
:
}
else if (propertyType == ShapeProperty.STYLE)
{
:
}
}
So this code uses the old way of programming, which is:
Check what kind of object or variant you have.
Modify program behaviour depending on what kind of object it is, despite the object being the most likely thing that knows what its attributes are.
for (int i = 0; i < properties.length; i++)
{
ShapeProperty p = properties[i];
attributes.put(p.getTagKey(), p.getTagValue());
}
Exception
The code could quite rightly reside in an adapter, which takes a set of ShapeProperties and generates BoxTag objects, for use as an integration message format. Otherwise, every ShapeProperty would have to know how to generate the integration format (which is not it's core function). Of course, you need to have comments to direct the developer to the adapter method in case new ShapeProperty classes are added, but at least all the obscure BoxTag conversion code is together.
