
To my experience I can classify a Product into two types Configurable and Cogs Product.
Configurable product
A Configurable product is a product that is wired to a particular algorithm or logic. What really changes are the actual parameters that feeds the logic. Usually those parameters are written as XML configuration file or in tables whatsoever.
Configurable products are fast to develop and easier to test. The reason is that you collect certain requirements and develop this product as per these requirements. The challenge is to make your product as generic as possible so it can fit as many of your clients.
Example
Say I have a product that can draw a map of customers usage of electricity in a given year. This product is configured to take as an input
Customer Table Name, the table should contain
Location field which represents the location of the customer and the a
Load field to create the legend. So you might have the Location field named as
CustomerLocation or
Customer_Location or
Customer_Position or
Customer_Lat_Lon doesn't matter. As long as you configure the product correctly you don't need to change your Customer Table name or its fields.
However, the product won't work if you have for example the
Load field in a table while the customer data is in another table, because this violate the infrastructure of the product.
Cogs Products
Think of Cogs product as a
framework application replaceable Cogs (Classes). So the product is a collection of classes that talk to each other via the
Interfaces ONLY. And its important the word interface in this context. Oriented approach plays a major rule in the cogs product. Clients can write their own logic that Implements those interfaces and literally replace the built in logic with their own.
Cogs product require a neat
UML design and a decent knowledge of
Design Patterns.
Lets have an example.
Example
Lets take again our product in the example above and alter it a bit. The product have a class called
DrawMap that Takes in its constructor
ICustomer interface. ICustomer interface has method called
getLoad and
getLocation. The beauty of this design is that I can write my own Customer class lets call it
MyWeirdCustomer that implements ICustomer and write the methods getLoad/getLocation which reads from a table or file or whatever and return the load and location respectively. Feed that object to
DrawMap class and TADA. It works. The reason is that
DrawMap doesn't care what your class is or how it is reading the load or how it is calculating the location. Whether you are asking Google Earth to geocode your location or have your location as native X/Ys; What DrawMap only cares about is that you implements
ICustomer and that you have the function
getLoad/getLocation.
The best approach is to merge the Cogs Product with Configurable one giving your client the ability to customize their code and have a configurable product. Having a hybird like product