Field = Attribute = Property = Getter = Method = Member. WTF?

! Warning: this post hasn't been updated in over three years and so may contain out of date information.

When I started learning about Object Orientated (OO) programming some 15 years ago, I was taught a set of terms to describe aspects of OO: class, object, method and field. In recent years, I’ve added one more term to the list: property. Whilst in my own mind, these terms have clear meaning, such meaning is not universal.

OO suffers from an identity crises. There is no formal definition of the term and it is used and abused with abandon throughout the programming community. I’ve touched on an aspect of this in previous posts with reference to JavaScript. UML defines an object as “An object is an instance or specific example of a class”, yet JavaScript – which is a class-free language – proudly anoints itself with the OO badge.

Supporters of JavaScript of course argue that an object need not be an instance of a class and that it can instead be derived from a prototype. The problems don’t stop there though. What I’d refer to as methods are also known as member functions, messages and operations. What I’d refer to as fields are also known as member variables, properties and attributes. Most worryingly for me, what I’d refer to as properties are – erroneously in my view – often referred to as “getters & setters”.

Properties – in the sense I use the term – are a late addition to OO. Wikipedia and InformIT (search for the 3rd occurrence of the word) both offer good definitions of the term “property”. Being an older OO language, Java doesn’t have properties. What it offers is a bean convention of prefixing methods with “get” and “set” (amongst others) to enable Java tools to pretend they are properties. These pseudo properties are known as getters and setters. To my mind, it is important to distinguish between first class properties and the method-based getters and setters of Java. Thus my previous comment about it being erroneous to refer to properties as getters and setters. Just to add to the confusion, both getters/ setters and properties are sometimes referred to as assessor methods, though this term has a much more general meaning to others.

Previously I mentioned UML uses the term “attribute” to refer to fields or member variables. Just to confuse things more, C# uses the term attribute to describe what Java calls annotations and ActionScript calls metadata. No doubt other OO languages use other terms too.

So what is the point of this ramble through confusing terms? Well as I often talk about these aspects of OO within my posts, I thought it about time I defined what I mean when I use these terms. In no way am I claiming these are the one and only correct definitions. Also they are not supposed to be detailed descriptions. They are designed to explain how I’m using the terms to other folk who know OO. The following definitions are simply the way I use them and in future I’ll be able to refer back to them in other posts.

A cohesive package of date and the means of manipulating that data. If may be abstract and thus cannot be used to create instance objects, or concrete, in which case in can be used to create instance objects.

A variable associated with a class or object.

A field, method or property of a class or object. Class members – also known as static members – only ever have one copy and are accessed via the class, not via an instance. Instance members have a copy per instance of the class.

A function associated with a class or object.

An instance of a class.

One or two functions or code blocks that are accessed syntactically as if they were a single field. If both the get and set functions are defined, then it can be fully treated syntactically as a field. If only the set function is defined, it may only be written to, not read from. If only the get function is defined, it may only be read from, not written to.

8 thoughts on “Field = Attribute = Property = Getter = Method = Member. WTF?

  1. I think you may be confused about something. You can create classes in JavaScript. Here are two links that came up on the subject:

    Blew my mind the first time someone showed me this; and I know of no JavaSCript code that used this approach (although I assume a lot of the frameworks do so).

    Syntax is a bit different than what you might find in JavaScript or ActionScript, though, but I see no reason why the approach can’t be considered creating classes.

    That said, I find that most people who talk about OO today are actually talking about writing encapsulated code that has no bearing on the academic/pure definition of OO. Most architecture designs I see are more procedural than OO. It used to bug me, but from from a pragmatic standpoint, I decided it doesn’t matter in the day to day grind of getting things done.

  2. Never mind OO programming, my wife and I have an entirely different set of vocab for meals and drinks. Lunch, Dinner and Tea mean quite different things to each of us. Thank god she doesn’t code or we’d be forever talking at cross purposes.

    Great post though – it was quite a long time before I realised how many different names are referring to the same things in OO conversations. Life got a lot easier when I did.

  3. @Jeffry,

    JavaScript is a form of OO as one can create objects based on prototypes. The links you provide show examples of prototypes in JavaScript. What I’ve never come across before is folk calling those prototypes “classes”. I guess there is no formal definition of what a class is though, so I guess there’s nothing to stop them doing so. Seems very wrong to me though.

    @Stray. You are right: confusion over words isn’t limited to just computing, for example the completely different ways in which we Brits and our American cousins use the word “momentarily”. In fact I think even “OO” means “object oriented” in the States and “Object Orientated” here. It may all be confusing at times, but it makes life more interesting 🙂

  4. So true about the confusion over terms. I once heard a programmer describing method overloading as ‘polymorphism’.

    However, I have to disagree with some of your definitions.

    I wouldn’t use ‘object’ to define an instance of a class, because in many languages a class itself is an object. It can be passed as an argument, stored in a variable. Same goes for a function, which is really an object too. To me, the correct term for a class instance is just an instance.

    What you call a ‘field’ sounds like it is conflating two types of values – class variables (one copy) and instance variables (one copy per instance). However, even using the word ‘variable’ is a little misleading, because we programmers tend to call things variables even when they are actually constants.

    I wonder if there will ever be consensus?

  5. @Toby,

    I see what you are saying with class, object and function, but you are slightly mistaken. It is the case that in AS3, the base class is called Object and that there are also classes called Class and Function. You can have an instance of Class, but what you then have is an object that references a class and thus can be used to create new instances of that reference class. Likewise, an instance of Function is not the function itself, but is instead a reference to the function.

    It is technically incorrect to say functions are really objects. In reality, a reference to the function is just be wrapped up inside an object (an instance of the Function class). This is called “boxing” BTW.

    I doubt there ever will be a consensus. I’m not sure if that’s a bad thing ever as such a consensus could end up stifling future innovations.

  6. Hi David

    Actually you are right. I suppose it is safe to call an object something which has been instantiated, and a class itself is not an instance of anything.

    But when you write

    private var class:Class;

    Are you saying that in AS there is no object of type ‘Class’ in memory, but just a pointer? Makes sense, I suppose. And the same with function? I thought Function was a real class with methods like apply() etc.

  7. Nice reading! I laughed a lot! Love how you titled this article. Found it writing JavaScript Confusing Bits. I know your pain. 🙂 I found it weird how people use those terms sometimes. I agree that it is fair enough to refer to Function constructor as class for simplicity. I am confused about “member” though – not sure what is that. Also field and property are the same thing in JavaScript aren’t they?

Comments are closed.