Objects Are Dictionaries

One definition of "objects" or "object oriented programming" is that objects are "glorified maps" (dictionary structures). Note that no distinction between class and object is made here, as it is assumed to be a language-specific feature rather than part of the definition of ObjectOrientedProgramming. (A class is a static dictionary or pre-compiled dictionary in this view.)

This "dictionary" (map) comparison roughly comes about as a combination of RobertMartin's "jump table" definition of OOP, and an observation that in dynamic OOP languages, objects and classes are basically dictionaries (AKA, associative arrays, hash tables, maps) where the method name is the key, and the result (value cell) is one of:

An attribute value
Algorithm (method code)
Pointer to an algorithm
Pointer to another dictionary

In statically-typed languages, you simply have a more complex or compound key (method name plus parameter signature) and some access limitations or rules. Aside from "prototype" languages or techniques (which are still considered "inheritance" by most, but use a kind of mitosis {clone} approach), the one extra thing besides the dictionary is the "search path" to the parent(s). If the item is not found in the current dictionary (object), then the search path is checked for other dictionaries that contain the method/attribute (or message) name. However, I am not sure that such a search path is necessary to be considered "OO" because of the above-mentioned clone approach. However, it is popular among languages considered OO. But it can simply be considered a "parent pointer" entry in the dictionary, a reserved attribute.

With this view, an object or class is the dictionary, and ObjectOrientedProgramming is the process of creating software using *combinations* of these dictionaries (with an inheritance path).

So you are saying that a class is a list of methods?

It is not a list, because it's not ordered.

What's the big news and why introduce a new term, i.e., dictionary?

It is to establish a "working terminology" for use in certain discussions, such as ArgumentsAgainstOop and TableOrientedProgramming. I did not invent the term Dictionary (DictionaryDataStructure). It is one of the common DataStructures. They are also known as "maps".

The fundamental flaw here is that if you put everything in terms of data structures, then of course a data structure oriented approach such as TOP will fit best.

Seeing everything as a data structure is just a way of looking at things. It does not necessarily change the nature of what is being observed or implemented. Besides, how is seeing everything as data structures worse than seeing everything as objects or everything as syntax?

Why must we see everything as X? I doubt you could find many OOP developer insist that we see everything as objects.

I thought I remember some OO proponents claiming they do. However, your question begs the issue of how things *should* be seen. That is outside the scope of finding a definition for OO.

I agree there are OO proponents who claimed such a thing, but what's the point even if you could convince them not everything is an object? Where's the benefit? OO means "Object Oriented", not "Objects Only". As for how things should be seen, it smacks of BigDesignUpFront. Even though I do practice XP complete, I find that by doing the simplest thing possible and refactor properly, I only need to think about how things should be done, never caring about how things should be seen. How about you start with telling us how seeing everything as a data structure help us develop systems better?

Such a discussion is for TableOrientedProgramming, not here. This topic is about a definition, not benefits.

As far as what such a view does "help", data structures are relatively well defined. Thus, it gives one a common framework in which to compare things if using it in a definition. I will consider other alternative definitions, but usually I find them vague. I am just trying to climb out of vagueness by using something we (hopefully) all agree on: DataStructure definitions. Whether I succeed or not is topic 2.

I have never met any developer who thinks that a DB table is an object, it is just that it is very convenient to access the table through objects, though.

I *have* heard OO proponents say that their objects "hide" (encapsulate) the table so that they can still think in terms of objects. No survey has been presented here for how developers actually think, let alone how they should think.

Encapsulating the DB table is what I meant by convenient, as I don't have worry about what DB I am using,

In practice this does not work unless you are only using the DB for bare-bones persistence, which some OO practitioners do.

and something I don't even care what datatype I am using for a particular column.

I can do that without objects, but this is not the proper topic.

I think the question is why cast everything in terms of data structures? There are already existing of definitions of objects or class you can use, such as AclassIsNothingButaCyclicDependency.

I smell more battles over whose OO definition is better. This topic once ranged for about 4 months on comp.object. A dictionary-like viewpoint ("jump-tables") received as many votes as any other presented. (By the way, I criticize AclassIsNothingButaCyclicDependency as being too static a definition in there.)

So what? Who cares? We build systems using languages based on OOP paradigm, we don't build anything based on popularity contests of OO definition.

I find it easier to discuss things if the definitions are agreed to by both parties, even if all that can be mustered is a working definition for the scope of the discussion.

If OOP paradigm leads to languages that make us more productive, great. If you can show us how any X-oriented paradigm will make us even more productive, even better! [Another topic] But why must that start with the definition of OO? When I learn the OO paradigm, no book ever starts with a definition on structure/procedural programming.

I thought I have seen some such definitions offered, but don't have any references for you at the moment. Again, definitions are important for coherent discussions in my experience.

From my experience, arguing about definitions usually bring more heat than light. Perhaps you can show us how a concise definition helps us solve problems or develop systems.

This topic is about definitions, not about getting benefits. If you think settling on definitions to improve communications is not important, then we cannot go any further.

{Perhaps some of the above discussion can be moved to WhyBotherHavingClearDefinitions? or the like. I have seen some debate about whether it is worth it or not.}

(See e.g. StandardDefinitions.)

{Under ObjectOrientedProgramming, this definition is listed as one of many, which is what is being suggested, isn't it?}

"Objects have very similar properties to maps (dictionaries)" - It's not quite the same statement, but leans the same way.

(Moved Python dictionary-to-class discussion to PythonLanguage)

I am moving "benefit" issues to DataStructureCentricViewDiscussion

Another way of putting it is: objects are data structures with methods (procedures) attached to them. Shouldn't the word dictionary be reserved for the book dictionary?

"Map" is probably a more common term than "dictionary", though they are used interchangeably in the wild. Your description doesn't tell us which data structure.

Or objects are records with methods (oberon calls them advanced records, or extended records).

"Record" is not a formal data structure. It means different things in different language/tools.

Classes in C++ are like Cee Structs with methods. Structs are equivalent (or very close to) records in oberon/delphi/modula. A struct in Cee can directly be compared to a record in delphi. Even a php associative array could have methods if you extended the php language. Instead of adding methods to structs, you could add methods to the associative array.

  array['something'].callMethod()

instead of the more procedural

  callProc(array['something'])

Object orientation can also be considered a terse syntax sugar that wraps or abstracts structured programming and procedural programming underneath the hood - it's a bit higher level than procedural and is a syntax sugar over top of it. Object purists would disagree and they see it as a whole new technology, or a new snake oil entirely different than procedural programming. I don't see it this way at all - I see it as an extension of structured procedural programming. Once you understand it is just an extension to procedural structured programming, you cannot hate OOP if you enjoy procedural programming, because OOP is procedural programming!

I tend to agree (see MergingMapsAndObjects). However, I'm bothered by "extension of procedural". I'd probably classify it as a functional concept in that functions (behavioral units) are or can be manipulated just like any other "kind" of programming "object". Actually, raw machine language allowed such, but a separation began to form around the Fortran era, probably to prevent errors. Ways to have dynamic references without the rawness of machine language took a while to sink in to mainstream languages. -t

One advantage of the map-based definition over many of the others is that it considers objects merely as a coding convenience (code packaging) and does NOT assume objects are intended to be used for a specific purpose, such as fitting the "real world" or wrapping "data structures" behind behavioral interfaces. It's a wider view of OO; and if one dispenses with such "purpose" views, then map-ism naturally follows. Think about it. --top

CategoryDefinition