In AP Computer Science A, a behavior is what instances of a class can do, or what can be done with them, and it is defined by the class's methods. Behaviors pair with attributes (the data stored in instance variables) to make up the blueprint a class provides for its objects.
A behavior is the "action" half of a class. Per the CED, attributes are the data related to a class (stored in variables), while behaviors refer to what instances of a class can do, or what can be done with them, and they're defined by methods (EK 1.7.A.2). When you call myAccount.deposit(50.0) or str.substring(0, 3), you're invoking a behavior.
Think of a class as a blueprint with two columns. One column lists what every object has (attributes like a balance or a title), and the other lists what every object can do (behaviors like deposit or checkOut). A class is the formal implementation of both the attributes and behaviors of an object (EK 1.12.A.1), so when you create an object, it comes with all the behaviors its class defined. You don't have to see the method's code to use a behavior, either. API documentation tells you what a class's behaviors are and how to call them, which is exactly how you use library classes like String and Math without ever reading their source.
Behavior is one of the core vocabulary words the CED uses to describe object-oriented programming, and it threads through both Unit 1 and Unit 3. In Topic 1.7, LO 1.7.A asks you to identify the attributes and behaviors of a class found in API libraries, so reading documentation and spotting "here's what this object can do" is literally a learning objective. In Topic 1.12, LO 1.12.A asks you to explain the class-object relationship, and that explanation hinges on the blueprint defining attributes and behaviors. Then in Unit 3, the perspective flips. Instead of using behaviors someone else wrote, you write them yourself as methods, and LO 3.3.A adds access control, deciding whether a behavior is public (callable from outside) or private (an internal helper). If you can't name the difference between an attribute and a behavior, Unit 3 class design will feel like guesswork.
Keep studying AP® Computer Science A Unit 1
Attribute (Units 1 & 3)
Attributes and behaviors are the two halves of every class. Attributes are the data an object stores in variables, and behaviors are the methods that act on that data. A BankAccount's balance is an attribute; deposit is a behavior that changes it.
Library and API Documentation (Unit 1)
API specs exist to tell you a class's attributes and behaviors without showing you the code. Reading a method signature in documentation is reading a behavior's contract, which is how you use String or Math methods correctly on the exam.
Inheritance and Class Hierarchies (Units 1 & 3)
Per EK 1.12.A.2, common behaviors of related classes get pulled up into a superclass, and subclasses inherit them without rewriting the code. Inheritance is basically behavior reuse organized as a family tree.
Data Encapsulation (Unit 3)
Encapsulation hides an object's attributes behind private and exposes carefully chosen public behaviors instead. Outside code never touches balance directly; it asks the object to deposit or withdraw. Behaviors become the only doorway into the data.
You won't get a question that just says "define behavior," but the concept is everywhere. Multiple-choice questions ask you to describe the class-object relationship, and the correct answer almost always uses the blueprint language of attributes and behaviors (a class defines them; an object is one specific instance with them). Design-flavored MCQs, like modeling a Book that can be checked out or returned, test whether you can sort a description into attributes (title, author, ISBN) versus behaviors (checkOut, return). On the FRQ side, Question 1 (Methods and Control Structures) and the class design question are entirely about implementing behaviors as methods. The 2018 FRQ with the StringChecker interface and the 2026 FRQ with the Space class's getColor method both hand you a behavior's contract (the method header and comment) and ask you to write or use code that fulfills it. Your job is to read a behavior's specification and either implement it or call it correctly.
Attributes are what an object HAS; behaviors are what an object DOES. Attributes are data stored in variables (like balance or title), while behaviors are defined by methods (like deposit or checkOut). Quick test: if it's a noun describing the object's state, it's an attribute. If it's a verb describing an action, it's a behavior. Exam questions about class design often hinge on sorting a scenario's details into these two buckets.
A behavior is what instances of a class can do, or what can be done with them, and behaviors are always defined by methods.
Attributes are the data half of a class (stored in variables) and behaviors are the action half (defined by methods), and the CED treats these as the two pieces every class blueprint contains.
You can use a behavior without seeing its code because API documentation describes each class's attributes and behaviors, which is how you call methods on library classes like String.
Subclasses inherit the behaviors of their superclass, so common behaviors get written once in the superclass and reused down the hierarchy.
In Unit 3, you control who can use a behavior with access modifiers, where public methods are callable from outside the class and private methods are internal helpers.
A behavior is what instances of a class can do, or what can be done with them, and it is defined by the class's methods. For example, deposit and withdraw are behaviors of a BankAccount class.
Attributes are an object's data, stored in variables (like a balance), while behaviors are an object's actions, defined by methods (like deposit). Per EK 1.7.A.2, this attribute/behavior split is how the CED describes every class.
Almost. A behavior is the concept (what an object can do) and a method is the Java code that implements it. On the exam the terms are used nearly interchangeably, because every behavior in your code is a method.
Yes. Every object of a class gets all the behaviors the class defines, because the class is the blueprint (EK 1.12.A.1). What differs between objects is their attribute values, like two BankAccount objects with different balances, not which methods they can run.
Yes. A private method is a behavior only the declaring class can use, typically a helper method. The behaviors meant for outside code are marked public, which is the core of encapsulation in Topic 3.3 (LO 3.3.A).
Connect this key term to the AP exam workflow: review the course, practice questions, and check related study tools.
Review units, study guides, and course resources.
Check this vocabulary in multiple-choice context.
Apply key concepts in written AP responses.
Estimate the exam score you are working toward.
Review the highest-yield facts before practice.
Put the full course together before test day.