Ever wonder what we're really talking about when we say an object "does something" in code? Most people hear "object" and think of a thing — a box, a user, a button on a screen. But the procedures that an object performs are called methods*, and that one word quietly runs a huge chunk of the software you use every day.
I know it sounds simple. But here's the thing — a lot of beginners mix this up with properties, or functions, or classes, and then everything downstream gets confusing. So let's actually talk about it like humans.
What Is a Method
A method is just a procedure or behavior that belongs to an object. Not the data inside it — the doing* part. Now, if you've got a Dog object, bark() is a method. But eat() is a method. Also, the dog's name or age? Think about it: those are data. The stuff the dog does* is the method.
In practice, the procedures that an object performs are called methods because they're tied to that specific object. You don't just call bark() floating in space. On the flip side, you call myDog. bark() — the behavior lives with the thing.
Methods vs Functions
This trips people up. A function is a standalone procedure. A method is a function that's attached to an object. Same mechanics underneath, different home.
Look, a function might be calculateTax(income). In practice, a method would be myCart. calculateTax() — the cart knows how to tax itself. That's the shift. The procedure is now part of the object's identity.
Methods vs Properties
Properties are what an object has. Easy to say, easy to forget when you're staring at a stack trace at 2 a.Methods are what an object does*. m.
A User object might have name (property) and logout() (method). That's why one describes state. The other changes state, or talks to something else, or returns something useful.
Why It Matters
Why does this matter? Because most people skip it and then wonder why their code turns into spaghetti.
When you understand that the procedures that an object performs are called methods, you start designing systems that make sense. The behavior travels with the data. Think about it: you're not writing a giant file of random functions hoping they line up. You're giving each object its own toolkit.
And here's what goes wrong when people don't get it: they write "god objects" with a thousand methods, or they scatter logic across free functions and lose track of what owns what. Real talk — I've inherited codebases like that. They're painful.
Turns out, naming matters too. If your team calls everything a "handler" or a "manager" but they're really just methods on an object, new devs waste weeks decoding the slang.
How It Works
The meaty part. Let's break down how methods actually function in object-oriented code, and how you write them.
Defining a Method
You put the procedure inside the object's definition. In most languages — Python, JavaScript, Java, C# — it looks like a function, but it sits inside the class or object.
class CoffeeMaker:
def brew(self):
print("Heating water...")
print("Pouring over grounds")
Here, brew is a method. That's the whole trick. The self part (or this in JS) is how the method reaches back into its own object. The procedure that the coffee maker performs is called brew, and it knows it belongs to a coffee maker.
Calling a Method
You don't run it like a normal function. You tell the object to do its thing.
myMaker = CoffeeMaker()
myMaker.brew()
That dot is the signal. "Hey object, run your procedure." The procedures that an object performs are called by reaching through the object first.
Parameters and Return Values
Methods can take input and give output, just like functions. Think about it: a bankAccount. transfer(to_account, amount) method moves money and probably returns a receipt or a boolean.
The difference is the method already knows about the account it lives in. You don't pass the source account — it is the source.
Instance Methods vs Class Methods
Worth knowing: most methods are instance methods — they work on one specific object. But some are class methods*, which belong to the whole class, not one instance.
In Python you'd see @classmethod. In JavaScript, sometimes a static method. In real terms, these are still procedures an object-related thing performs, but they don't need a specific myDog to exist. They run at the class level.
If you found this helpful, you might also enjoy how long is the ap calc ab exam or describe the process of primary productivity..
Encapsulation and Visibility
Good object design hides some methods. They're "private" — internal procedures the object uses but you don't call directly. The public methods are the ones you're meant to use.
So when we say the procedures that an object performs are called methods, we really mean the useful, intended* behaviors. Behind the scenes there might be ten more doing cleanup you'll never see.
Common Mistakes
This section is where most guides get it wrong by being too clean. Let's be honest about the mess.
Mistake one: calling everything a method when it's actually a property with a getter. If user.name just returns a string, that's not a procedure. But user.getFullName()? That's a method — it does work.
Mistake two: putting method logic in the wrong object. I've seen Invoice.sendEmail() when the email service should own that. The invoice knows its data; it shouldn't know SMTP. The procedure an object performs should match what the object is.
Mistake three: side effects nobody expected. A method called getTotal() shouldn't also delete a row. If the procedures that an object performs are called something innocent but do something wild, that's how bugs hide.
And the big one — people think "method" means complex. A one-line procedure is still a method if it belongs to the object. Day to day, it doesn't. Don't over-engineer.
Practical Tips
What actually works when you're writing or reading code:
- Name methods like verbs.
calculate,send,validate,render. If you can't make it a verb, it might be a property. - Keep one method focused. If your
process()method has forty lines and three responsibilities, split it. The procedures that an object performs are called clearer when each does one thing. - Watch the dot chain.
user.account.settings.theme.update()means four objects each ran a method. That's fine — until one is null. Then it's a nightmare. - Use the language's conventions. Python uses
snake_casefor methods. JavaScript often usescamelCase. Match the codebase, not your mood. - Don't expose private methods unless you have a real reason. The public surface should be small and honest.
Honestly, the best tip is this: when you write a method, say out loud "this object will now [verb]." If that sentence sounds stupid, the method's in the wrong place.
FAQ
What are the procedures that an object performs called in Java? They're called methods. Java is strictly object-oriented, so any behavior attached to a class or object instance is a method, not a free-standing function.
Is a method the same as a function? No. A function is independent. A method is a function defined inside a class or object and called on an instance. Same underlying idea, different scope.
Can an object have no methods? Sure. That's usually called a data object or DTO (data transfer object). It just holds state. But in true OOP, most useful objects have at least a few methods describing what they do.
Why do some languages call them member functions? C++ and a few others use "member function" because a method is literally a function that's a member of a class. It's the same concept with older terminology.
Do methods always change the object?
No. Many methods just read data and return a result. getArea() on a Rectangle doesn't change the rectangle — it reports on it.
Closing
So the next time someone asks what the procedures that an object performs are called, you can just say methods — and actually mean it. It's a small word, but once it
clicks, it changes how you read and write code. You stop seeing objects as passive bags of data and start seeing them as things that do stuff — small, named units of behavior you can reason about, test, and trust.
The confusion around terminology isn't just academic. When teams mix up methods, functions, and properties, they write code that's harder to manage and easier to break. But when everyone agrees that the procedures an object performs are called methods — and treats them with the respect of clear naming and narrow scope — the whole system gets calmer. Bugs have fewer places to hide, and new developers spend less time guessing what an object is actually for.
In the end, object-oriented programming is less about rigid rules and more about a habit of mind: give things names, let them act, and keep those actions honest. Master that, and the rest follows.
