Object-orientation is a way of thinking, not a programming language.

A paradigm is a way of viewing something.

One can program in an OOP (Object Oriented Progarmming) way in C.

C allows it.

C does not support it.


Thinking outside the box is a way of thinking about a different paradigm.

The word "paradigm" comes from the Greek «παραδειγματική» meaning an "example" or "pattern".

Where exactly is the box?

The real (concrete) world is where you are.

The abstract (conceptual) world is where you model and solve problems.

Any simple problem is solved directly in the real world, so modeling may not be necessary.

Difficult problems that still must be solved need to be abstracted to a model and solved using the model before mapping the modeled solution back to the real world. Hopefully, the model helps solve the problem.

To do this, we must model problems.

• structural characteristics of objects - what it knows , data-oriented , properties , attributes
• behavioral characteristics of objects - what it does , process-oriented , methods , operations
• relationships between objects - how objects relate to one another

A declarative construct is data-oriented.

A declarative system is a system where the specification is the solution.

A data model is declarative. A procedural construct is process-oriented.

A paradigm is a pattern or example of something.

• function-driven paradigm
• data-driven paradigm
• object-oriented paradigm

The functional paradigm emphasizes functions and variables that can be assigned a value only once.

• Given some input, what is the output.
• Let f(x) = 2 * x + 1.
• If x is 3, what is f(x)?
• f(3) is 2 * 3 + 1 which is 7.

The emphasis is on code. Functional paradigms work well for most scientific and engineering applications.

The data-driven paradigm emphasizes the structure and relationship of data without too much concern of what will be done with the data.

This was started with the entity-relationship model (1976) and relational database technology (early 1970's).

"The business keeps changing, but the data relationships stay constant.". Belief: If we can just structure the data right, everything will fall into place.

The emphasis is on data. data-driven paradigms work well for many business applications.

Some people prefer one paradigm over another.

Advice: You should use the best tool for the job.

Saying: If all you have is a hammer, everything looks like a nail. (attributed to various sources)

So, if you need to put a screw in, you hammer it in.

But, a better tool, such as a screwdriver, might make the job both easier, faster, and improve the quality of the work.

If all you know how to use is a spreadsheet, every problem solution attempt is done with a spreadsheet.

In the 1980's, an entire market for memory upgrades was motivated by making it possible for people using spreadsheets to solve bigger and bigger problems, regardless if the spreadsheet was the best tool for the job.

Note: A spreadsheet is a simple functional language.

If all you know is email, then every problem can be solved with email.

For systems design, programming, data science, and problem solving in general, there are many tools suited to many different problems.

When solving problems, keep in mind that there may be a better or easier way to do what you are trying to do.

• Create a data model, use SQL.
• Operate on the data using code, such as COBOL (mainframe world) or Visual Basic or C# (workstation world).

A better solution might combine code and data.

The result is objects, a combination of code and data.

Object can more easily model business processes as is needed for business process reengineering.

• presentation layer (user interface)
• business rule layer (code - COBOL, Visual Basic, etc.)
• database layer (data models and SQL)

• presentation layer (HTML and JavaScript, client workstation browser)
• business rule layer (ASP using VBScript, web server)
• database layer (SQL Server, database server)

As objects are concept-centric, objects can more easily model business processes.

In the 1990s' Michael Hammer, with a Ph.D. in computer science, applied object-oriented ideas to business - which had never defined itself. BPR (Business Process Reengineering) is applying object-oriented methods to business problems.

Perhaps the most startling notion that arises from process-centered planning is the suggestion that long-range forecasting is a waste of time. ... It is becoming increasingly clear that the best strategy is not one that tries to divine the future but one that responds rapidly to the present. Hammer, M. (1996). Beyond reengineering. New York: Harper Business., p. 203.

Even if the implementation is done with SQL and Visual Basic, the concepts are useful.

Object-oriented databases are not yet ready for prime time.

So, you end up implementing many projects using a relational database server with code that accesses the database.

A common way is to use a relational database, interface using object-oriented Java. Then, you can create or generate a Java class to interface to the relational database, with methods to access and change the database.

You can automate the generation of such Java classes (e.g., from Visual Basic). Then, create a subclass that inherits from the Java class. You can then override certain methods to provide other behavior (I call it semantic actions), so that you can easily generate a new superclass, but leave the subclass alone (unless something in the database changes too much).

The biggest problem here is that Java is strongly typed, so you have to be careful getting data into and out of the database.

Objects allow us to abstract both structural (data) and behavioral (code) aspects of the real world that is being modeled. Encapsulation is hiding certain internals an exposing only certain parts via a well-defined interface.

A module encapsulates code and data and provides a well-defined interface.

Converting a module into an object allows the module to be cloned. Class inheritance is where a subclass inherits call characteristics of a superclass from which it is derived.

A subclass can override certain characteristics using virtual methods.

A subclass instance is a superclass instance, but a superclass instance is not a subclass instance.

If we have a class A, and we drive a subclass B from it, then B might add new thing, but A will not have those new thing.

One type of polymorphism is that you can pass a subclass B to a method that expects a parameter of class A. Thus, each derived subclass can do certain things differently, but still be handled by that method that expects a parameter of class A.

Attributes and operations can be of the following types.

• public - everyone can access them
• private - no one can access them
• protected - only derived classes can access them
• published - means you can access them at design time using the property editor

A module is code that makes only a subset of it's data and code accessible to the outside world.

Module cohesion is the degree to which modules interact.

Module coupling is the degree of interaction between two modules.

The same goals are useful for classes.

• Top-down view: An object is an instance of a class.
• Bottom-up view: Objects allow modules to be cloned.

Note: This ignores the important areas of inheritance and polymorphism, but that can be delayed until later.

---