See discussions, stats, and author profiles for this publication at: [Link]
net/publication/292378253
Brief Introduction to COP (Component Oriented Programming)
Article · January 2016
CITATIONS READS
0 2,448
1 author:
Raju Chiluvuri
[Link]
40 PUBLICATIONS 0 CITATIONS
SEE PROFILE
All content following this page was uploaded by Raju Chiluvuri on 31 January 2016.
The user has requested enhancement of the downloaded file.
Brief Introduction to COP (Component Oriented Programming)
Please kindly allow me to briefly illustrate true COP (“Component Oriented
Programming”), in light of the figure below showing component hierarchy for a
City-GIS & the City-GIS application: [Link]
In structured programming one can create records for storing data, such as a
record (or struct in C) to store data related to an employee and another record for
Address, and so on. The record for employee can contain reference to other
records (as sub-records) such as Address, Position, and so on. Also contain a
reference to his manager (an Employee type record), and a reference to an array
for Employee type records for a list of employees reporting to him.
In structured programming, it is not hard to create very large hierarchies of
structures (or records) by using such kind of records. That is, it is possible for a
record to contain multiple variables/fields, each is a reference to either a record
(as a sub-record) or to an array of any type (i.e. primitive type or user defined
type record). It is possible to use this kind of container records as sub-records in
yet another container record. It is possible to create an array of such records,
where the array can be referenced by a variable in another record, and so on.
Likewise, in OOP (Object Oriented Programming) one can create very
large and complex hierarchies of objects. That is, an object can contain multiple
fields (or variables), where each variable may be having reference to either ab
object or an array of objects. One can create arrays of objects and make the
array as a field in another container Object. I am sure, no software developer
should have problem creating such complex hierarchies of either records or
objects. Any large software applications contain such large hierarchies.
We invented first ever GUI-API that is capable of encapsulating any GUI
application in a Class definition. Any custom GUI application (or component such
as City-ATC, City-ER or City-LM) can be implemented as Class definition. An
object instance of the class represents a custom self- contained GUI component
(or an autonomous mini-application). Hence building complex hierarchies of GUI
components is literally no different from building hierarchies of objects, where
each object is a mini-application (i.e. loosely coupled self-contained component).
Also See: [Link]
To achieve such COP (Component Oriented Programming), it is essential
that the GUI API must allow implementing any custom GUI application or any
custom GUI components such as City_GIS, City_ATC or City_ER under a class
definition. Each Class definition for a custom component (e.g. City_GIS,
City_ATC or City_ER) must be self-contained by implementing all the necessary
code such as data access logic, application logic and presentation logic.
In other words, the GUI API must allow encapsulating any GUI application
in a class definition. This allows us to not only design and develop each custom
component individually as an autonomous min-application having exclusive code
base (by keeping the exclusive code base free from spaghetti code) but also
maintain and redesign each custom component individually as an autonomous
min-application having exclusive code base (comprising all the necessary code
such as data access logic, application logic and presentation logic).
No other GUI-API in the world (including desktop GUI-APIs such as
Windows-API or Java/Swing) is capable of implanting simple applications such
as City_ATC or City_ER as a class definition. It is impossible to either find or
implement a class definition that encapsulating even a small custom GUI
component of size such as City_ATC or City_ER. Hence to include such
components as sub-components in a container application (e.g. City_GIS for
Bangalore), developers are forced to create spaghetti code by merge code bases
implemented for these two GUI components.
Once the code bases are merged (resulting in spaghetti code) to create
container GUI application, it is must harder to redesign and test this kind of
spaghetti code compared to redesigning and testing each GUI class individually
(free from spaghetti code). This kind of spaghetti code grows exponentially as
more and more GUI components are added to this application. But COP
eliminates this kind of spaghetti code.
In COP, each of the self-contained components (e.g. features and
functionality) can be implemented as a class definition having an exclusive code
base (i.e. a set of files exclusively containing code for this component alone). The
component can be not only redesigned by modifying this exclusive code base
but also tested individually as an autonomous mini-application (e.g. to make it as
best as it can be before re-assembling the GUI component).
Please keep in mind: If it is impossible to encapsulate small GUI
applications (or components) as class definitions, we can’t use the components
as objects for building hierarchies of objects. Since these objects represent
components, the hierarchies of objects are nothing but hierarchies of
components. Likewise arrays of these objects are nothing but arrays of self-
contained custom components. Hence, building component hierarchies is literally
same as building hierarchies of objects.
Please keep in mind that: It requires no more than 3 lines of code to plug-
in each of the custom GUI components (by using respective class definition) as a
subcomponent to build container components or insert in an array to build array
of components. Since each GUI component is custom designed for a target
application, so the exclusive code base for its class implements all the necessary
application logic, so it requires no more customisation or configuration.
Hope this illustrates, how COP eliminating spaghetti code from complex
GUI applications, created by literally plaguing-in GUI component to build larger
and larger GUI components and the application (as a large hierarchy of
components). Each class/component can have exclusive code base that allows
designer of the custom component to redesign and test the component
individually (free from spaghetti code). Since over 90% of the application code is
implemented in such classes, over 90% of the application code is free from
spaghetti code.
Since the TAB-Obj in the PDF file is an Object, which can be used as a
sub-component by another Object such as Pie-chart. Since one can input any
Object as a Title for Pie-chart, one can pass this TAB-Obj (provided it is scaled to
fit the space given for title). Hope you could see the power of our patented COP.
Power of COP (Component Oriented Programming):
If 100 software developers created and tested 100 software components
(e.g. City-ATC, City-ER or City-LM), each of the components can be literally
assembled (or plugged-in) within minutes (by implementing about 3 lines of code)
for building larger and larger components and finally the application. Removing
these 3 lines of code effectively unplugs each of the components.
Each component can have an exclusive code base (i.e. a set of files), so
that it can be redesigned and tested individually (free from spaghetti code). Each
component can be designed, build and tested individually to make it as best as it
can be before plugging-in into the application.
If this component doesn’t fit perfectly into the application or if it is not
collaborating with other components as expected, it can be refined and tested
individually little-by-little until it fits and performs perfectly within the application.
Since each component has exclusive code base, it can be redesigned and
tested individually, free from any spaghetti code). The application is evolved (e.g.
for future releases or upgrades) by evolving each of the components.
Any component having exclusive code base can be refined and tested
individually at a fraction of the cost and time (at any time in the future), for
example to add more and more features or to satisfy evolving needs.
If a better new component (e.g. for City-ER) is created (or available) at
any time in the future, the old component can be replaced by the new component
within minutes by replacing or editing the 3 lines of code.
Pioneer-soft also invented CASE-Tools that can automate most of the
tasks for creating and maintaining couplings between the GUI components, so
that they can properly collaborate and communicate with each other. A sample
tool is at: [Link]
[Link]/CBD/Sample_SoA_CASE_tool.html
View publication stats