Extensibility Models

What are the different models/patterns used to make a software extensible? Our focus is on executable software!

An executable, is a main process, that calls many function, an executable is is primarily, one loop, one algorithm. To make an executable do more, give it more input.

Data loss issues Many application (information systems, business applications, directories, apt-get) collect, maintain and later report about data and information.

An algorithm -how an operation is performed- heavily relies on the data structure (i.e. who knows what) encapsulation or information hiding will eventually fail you, data always have a structure, on which an algorithm depend, encapsulation, information hiding, and responsibility based OOD will help you a lot, but sooner or later, a shift in responsibility assignement will lead to a change in the algorithm, or even more significant, a change in the require algorithm -due to a change in policy for example- will lead to a change in responsibility assignement

Extending an application, making it do more, definitely means adding new responsibilities to this piece of executalbe, this definitely mean, you either added new data type or extending existing data, adding more responsibilities to existing objects + the algorithm that will interface those changes to you. Or you added a new algorithm, a new way to interact with data, or a new derived data

Moral is, algorithm and data are tied together, a change in one will lead to a change in the other, concepts like Generic programming, and dynamic typic help in tieing the algorithm to only the data characteristics is absolutely relies upon. But again, an algorithm relies on a specific data structure, if it's not in the data it received to work on, it won't work.

So how is this related to data loss, extending data or modifying a data structure to fit a new algorithm might require, moving/maping an existing data stock to a new format. This process if not well planned can lead to data loss.

Extensibility through integration I like to think, that integration is also extensibility, you can make an application do more, by integrating another application into it. For example, my car plays music cause it can integrate a stereo!

This is not true extensibility, the application is not doing more, you actually created a new abstract program that combine the features of many programs, but if one pogram is an obvious host, then we can easily pretend that this is extensibility

Interpreters Interpreters are born extensible, view LanguageOrientedProgramming . I believe creating a language every time you to create a program is absolute waste of time and effort, a loop is a loop, a branching statement is a branching statement, how many different implementations of the same thing do we need, use an object oriented interpreted programming language every time you think you need to create a language. You will only work on creating new ADT instead of creating a language, you can spend more time picking the right OOP language that will help you

Dynamic linking Instead of adding a new line into the main loop, add a new line into the definition of a function eventually called by the main loop.

Extensibility through parametrization Modifying the default behavior of an application, can bew viewed as an extensibility mechanism, this is usually done, by provided parameters to almost every aspect of the program, nothing is hard coded. Here the algorithm is static (is not exetensible) by different data values, give the illusion that the application is extensible. The parameters is the small mini languages that the program speak, the more parameters a program have the more flexible and more complex it gets. At the two extremes we can see a program that only receives one parameter and do just one thing, and an intepreted OO languages which can receive a completer program as a script -- AliMotaz