Amino Object Oriented Programming Review
Contents
(WRT = with respect to)
Types Of Programming
Software
coding can be divided into 2 main “camps” – “structured programming” and
“object-oriented programming”
Structured
programming is a theoretical description of a coding paradigm that states that
a program can be coded using any combination of 3 structures: Loops,
Conditional Statements, and Sequential Statements [1].
This is analogous to the digital engineering ability to build logic systems
using only a few distinct types of logic gates (except of course being able to
make anything from nand-gates!) In structured programming, one typically starts
programming “at the top” – ie. the highest level of the program (like the main
function) and then code “down” - in terms of higher detail. Most languages
“support” structured programming – C, C++, Java, etc. in that a person that
likes to code this way (with only these three structures) can do so, without
utilizing other features of the language. Structured programming usually has
methods and data. Data and methods can be made “global”. Typically data and
names in structured programs have to have unique names.
Object
Oriented programming (OOP) on the other hand adds another structure: the
Object. This is a loose term for the idea of bundling data and methods
together. The internals of an object may very-well seem to be “structured”
however the benefits of OOP can be exploited in terms of applying design
“semantics” to types and behavior.
OO Basics
Object Orientation involves the bundling of data (attributes, state, etc) and the methods that operate on that state. This introduces a valuable typing mechanism – not only can I have numbers, strings, and collections of those (ie. structs) I can add methods that focus on one set of data. This may seem trivial, but it allows one method of type restriction: the compiler. Compilers can now have the added responsibility of telling a coder that something is wrong before the program runs. Of course this can be circumvented, but utilizing this advantage, and the others of OO, allows an organization to build into their software process componentization of code and more robust build procedures. This of course still requires communication between team members, and a configuration management system, but now folks can share data and methods OF THE SAME NAME and have things build and run fine, because the compiler knew how to handle the names that looked the same but really belonged to different objects.
We’ll introduce some language-independent terms here:
Class – a classification for “types” of data that can be collections of data and methods;
Method – a class special message/method/function/procedure (which ever term you’re familiar with) that “knows” about the class attributes;
Attribute – a data element “contained” by the class – ie’ it occupies some kind of memory that the class has been allocated.
We’ll
also introduce terms specific to OOP (these represent the three main features
of OO languages):
Inheritence
– the ability of a class to “borrow” data/methods from some other class;
Polymorphism
– The ability of a class to “override” data/methods that it borrowed from an
inherited class. (AKA.Overloading)
Encapsulation
– being able to group methods and attributes together – the essence of the
class.
We’ll
also introduce some terms regarding “exposure” of attributes, methods, and
classes to other program entities:
Public
– the attribute/method/class can be accessed by outsiders to the class;
Protected
– the attribute/method/class can be accessed only by classes/methods in the
local namespace;
Private
– the attribute/method/class can only be accessed by the class itself.
Told by: Julian L. Morgan.
Question: What is the difference between an object
methodologist and a terrorist?
Answer: You can negotiate with the terrorist.
Author unknown:
An OO surgeon would hand the scalpel to the patient and say: "now perform this operation on yourself!".
See also this Sun page on OOP
Amino Philosophy WRT OOP
Everything is based on an interface. Interfaces should only use types that are either primitive types, structs that use primitive types and/or interfaces, interfaces, arrays of interface types, etc. The idea is that the project defines the types and methods, and these map (within the implementation) to a specific library, implementation, procedure, etc. Any questions?
References:
[1] Structured Programming Explanation
Last revised: Feb 25, 2003