“Object-oriented design is the roman numerals of computing.” – Rob Pike
I never use the word “object” when discussing program design. I try to avoid it as much as possible because the word “object” too often depends on surrounding context for disambiguation.
When someone says “Object” do they mean Class or “Instance of a Class”? What if they are talking about a language that doesn’t have classes but does have objects? Maybe they are talking in the context of a language that has record types (i.e. a structure that has fields but no methods) in addition to object types (i.e. both fields and methods in a single structure)? Maybe the “object” is an interface-type object only?
It’s really hard to answer those questions, because some languages have Classes (C++, Java), some lack Classes but do support objects through prototyping (JS ES5), some have records in addition to classes (both of which are treated as objects), some have records only, and there is at least one language which supports both classes and objects, but an Object is not the same thing as “An instance of class”.1
So be clear when you want to talk about “Objects” in the context of program design. Choose unambiguous words instead of relying on context to establish the meaning of the word “Object”. You can use Class, Instance, Interface, Implementation, Record, PoD2 and more, depending on the programming language in use; why settle for a word that, sooner or later, someone is going to require clarification on?