Object-Oriented Programming

In Caché, %RegisteredObject is the base class for transient objects - objects that exist only in memory and are not stored in the database. This is the correct inheritance for creating a transient class.

All five options are valid class keywords in Cache ObjectScript. Clientdatatype defines a custom data type class, Abstract prevents instantiation, super references the superclass, classtype defines the class category, and final prevents further inheritance or overriding. These keywords control class behavior and inheritance patterns.

Data type classes in Cache ObjectScript cannot be directly instantiated (they're abstract by nature) and automatically include methods for validation and translation when used. However, they CAN contain properties to define the data structure, and they CAN be inherited to create specialized data types. The claimed answer A and C are correct.

In Cache ObjectScript multiple inheritance, class keywords are inherited only from the first superclass in the inheritance list. Keywords from subsequent superclasses are not inherited. This prevents conflicts when multiple superclasses define conflicting keywords. The inheritance is determined by the order of superclasses in the class definition.

When a superclass lacks a no-argument constructor, subclasses must explicitly call a superclass constructor with matching arguments using super(...). Bottom2 fails to do this, causing compilation to fail because the implicit super() call cannot find a valid constructor in Top. The Top class only has Top(String s), so Bottom2's constructor must explicitly call super(s) or super(someString).

Cohesion measures how focused and single-purpose a class is. High cohesion means a class performs one logical task. Hiding implementation details is encapsulation, interface-only interaction is loose coupling, and treating objects as multiple types is polymorphism.

Fields in Java are not polymorphic - they bind to the declared type (Mammal), so m.name returns 'furry '. Methods ARE polymorphic and use the actual object type (Zebra), so m.makeNoise() returns 'bray'. This is a key distinction between field access and method invocation in Java's inheritance model. Even though the object is a Zebra, field access is determined at compile time based on the reference type.

Direct access to another class's public variables violates encapsulation principles. ClassB should protect its data with private fields and provide access through getter/setter methods, making ClassB responsible for its own data management. When ClassA directly uses ClassB's public variables, ClassB has weak encapsulation because it exposes its internal implementation details.

In Java, 'extends' is valid only when both X and Y are classes, or when both X and Y are interfaces. A class cannot extend an interface (it implements it), and an interface cannot extend a class. This rule maintains the type system's consistency - inheritance relationships must be between the same kind of type.

The code tests Java's method overload resolution with varargs. sifter(aa) calls sifter(A[]... a2) matching -4. sifter(ba) matches sifter(B[] b1) NOT sifter(B[]... b1) because Java prefers non-varargs over varargs when both match - giving -3. sifter(7) matches sifter(Object o) as 7 autoboxes to Integer then widens to Object - giving -4. Final result: -434.

Java's access modifiers follow this order: private (most restrictive) → default (package) → protected → public (least restrictive). When overriding a method, the subclass cannot make it more restrictive than the parent. A protected method can be overridden as protected or public, but NOT private (too restrictive) or default (package-private).

During Java serialization, transient fields are explicitly ignored and not included in the serialized output. The transient keyword is used specifically to mark fields that should not be serialized. Static fields are also not serialized, but the question specifically asks about which fields are ignored, and transient is the key mechanism for this purpose.

Java Beans must have a no-argument constructor (empty constructor) to enable instantiation by containers and frameworks. They should follow encapsulation principles by having no public fields - all data access should be through getter and setter methods. Both requirements are part of the Java Bean specification, making option C correct.