Object-Oriented Programming FileMaker Analogy

Modified on September 13, 2014.

An analogy of object-oriented programming concepts using FileMaker Pro.

Note: FileMaker is not the best tool for making OOP analogies, this is just a first step in explaining the concepts.

FileMaker terms: database, table, record, field, script.
FileMaker databases consist of tables with records; records have fields; FileMaker scripts act on records and fields.

Object-Oriented Programming terms: object, instance, class, properties, methods, getters, setters, inheritance, encapsulation, and polymorphism.

Class = a FileMaker database table

Object = Instance (of a class) = a record

Instantiate = create a new record in that table

Properties = fields
Example: Name, Address, City, State, Zip

Methods = how you manipulate a class = things you can do to a table = scripts
Example: FileMaker scripts to Add_Party, Update_Party, Delete_Party, Set_Status, Show_Name

Getters = get the value from a field / calculation / script result
(aka get the value of variable in the class)
A getter method does not take any parameters and always returns a value.
Example: a FileMaker script acting on a particular table (class), Get_Status

Setters = set the value in a field / calculation / script result
(aka set the value of variable in the class)
A setter method always takes a parameter and never returns a value.
Example: a FileMaker script acting on a particular table (class), Set_Status

Inheritance = every subtype table (class) inherits the fields (properties) and scripts (methods) of its supertype table (class); classes inherit from other classes.

Example: If Party is the supertype and Vendor, Customer and Employee are the subtypes, then the Vendor, Customer and Employee tables (clases) inherit the fields (properties) and scripts (methods) of the Party table (class). But a new record in the Party table does NOT “inherit” because it is an Object and not a Class and only Classes inherit from other Classes.

Encapsulation = for a given set of properties/data in a class, all of the code which can directly manipulate that data is embedded (as methods) in that same class. Class B can read Class A properties, copy them, and tell class A to change them, but Class B can’t directly change Class A without Class A knowing about it.

Example: When Class B calls upon Class A, Class B should make no assumptions about how Class A is implemented.

Polymorphism = OOP concept that calling a method on a subtype/sibling class can give you a different output than when that same method is called on the supertype/another sibling of that class.

Example: If Party is the supertype and Vendor, Customer and Employee are the subtypes, polymorphism means that for Vendor, Customer and Employee subtype tables running the Show_Name script (method) on a record (object) gives you different results depending on the table; Customer->Show_Name = ‘Customer ‘ + Name, Vendor->Show_Name = ‘Vendor ‘ + Name, Employee->Show_Name = ‘Employee ‘ + Name.

Special thanks to Deepali Gokhale of infoCypher Data Consulting, LLC for her help with this analogy.