According to the JavaBeans naming convention, which of the following method names correctly follows the standard for a simple read accessor on a customer property?

Introduction / Context:
The JavaBeans specification defines standard naming conventions for properties, events, and methods so that frameworks and tools can automatically discover and manipulate beans using reflection. For simple properties, getter and setter names follow predictable patterns. This question asks you to identify which method name best follows the JavaBeans standard for a read accessor on a customer related property.

Given Data / Assumptions:

• We are dealing with JavaBeans style components that expose properties through getters and setters.
• Read accessors for non boolean properties normally begin with get followed by a capitalised property name.
• Boolean read accessors may use is as an alternative prefix.
• Other verbs such as add, put, or delete are used for different kinds of operations, not for simple property access.

Concept / Approach:
Under the JavaBeans convention, a property called cust or customer would typically have a getter named getCust or getCustomer and a corresponding setter named setCust or setCustomer. Tools such as introspection utilities or frameworks like JavaServer Faces rely on these naming patterns to locate properties automatically. The method name must start with get, have at least one additional character, and capitalise the first letter of the property name. Methods starting with add, put, or delete imply other behaviours such as adding listeners, placing values in collections, or deleting records, and are not treated as simple property getters.

Step-by-Step Solution:
Step 1: Recall that for a simple non boolean property, the getter pattern is getXxx, where Xxx starts with a capital letter.Step 2: Examine option C, getCust, which matches this pattern for a property named cust.Step 3: Evaluate option A, addSize, which suggests adding something rather than reading a property and does not follow the get prefix convention.Step 4: Evaluate option B, putDimensions, which implies inserting or updating dimensions rather than reading a property.Step 5: Evaluate option D, deleteRep, which represents an action to remove something, again not a standard getter name. Therefore, getCust is the only proper JavaBeans getter among the options.

Verification / Alternative check:
References on JavaBeans and frameworks that use beans, such as older JSP and JSF examples, consistently show getters such as getName, getCustomer, or getId. Reflection based property editors look specifically for methods with the get prefix and a matching set prefix for setters. If you rename a getter to use add or put, property discovery fails. This confirms that the canonical getter name for a property like cust must start with get.

Why Other Options Are Wrong:
Option A, addSize, follows a common pattern for adding listeners (for example addPropertyChangeListener) or items to a collection, not for reading a property value. Option B, putDimensions, sounds like a mutator that stores dimensions but does not match JavaBeans getter naming. Option D, deleteRep, refers to deletion of some representation and does not read anything. None of these names would be recognised as a standard property getter by JavaBeans introspection.

Common Pitfalls:
A common mistake is inventing method names that are descriptive but break framework conventions, causing tools to miss properties or events. Another pitfall is inconsistent capitalisation of property names, which can confuse reflection based code. Sticking closely to JavaBeans patterns for get, set, and is helps ensure that your components integrate smoothly with libraries, GUI builders, and data binding frameworks that expect these naming rules.

Final Answer:
Correct answer: getCust