Object-Oriented Programming

Constructors can be overloaded by defining multiple constructors with different parameter lists, allowing objects to be initialized in different ways.

Abstract classes cannot be instantiated directly. They serve as base classes and must be inherited by concrete classes that implement all pure virtual functions.

To solve this question, the user needs to know the concept of access modifiers in object-oriented programming and their default level assigned to the members of a class.

Now, let's go through each option and explain why it is right or wrong:

A. Public: This option is incorrect. Public access modifier allows members of a class to be accessible from anywhere in the program. However, it is not the default access level assigned to members of a class.

B. Protected: This option is incorrect. Protected access modifier allows the members of a class to be accessible within the class and its subclasses. However, it is not the default access level assigned to members of a class.

C. Private: This option is correct. Private access modifier allows the members of a class to be accessible within the class only. It is the default access level assigned to the members of a class if no other access modifier is explicitly specified.

D. Default: This option is incorrect. Default access modifier allows the members of a class to be accessible within the package only. It is not the default access level assigned to the members of a class.

The Answer is: C

Overloading occurs at compile-time when functions with the same name have different parameters. Overriding happens at runtime when a derived class provides a new implementation for a base class virtual function.

A function template in C++ defines a general set of operations that can be applied to various types of data passed as parameters. While a class template defines a family of classes, a function template specifically represents operations (functions). Therefore, 'Both a and c' is incorrect.

C++ does not support virtual constructors. Object construction requires knowing the exact type at compile-time. Virtual destructors exist and are important for proper cleanup of derived class objects through base pointers.

In role-based access control systems like Pega, access roles defined at a parent class level automatically inherit down to all child classes. This inheritance persists unless explicitly overridden by a more specific access rule defined at the child class level. Other options miss this conditional override.

In PRPC, pz prefix properties (Pega-provided protected) are read-only and cannot be modified by developers or users. px properties are public and can be modified, while py properties are your custom properties that you can modify. The pz layer is Pega's protected code that shouldn't be altered.

Ordinary work objects inherit from the Work-Object- base class in PRPC. Covered work objects inherit from Work-Cover- class, not Cover-Object-. Folders can contain multiple covered work objects, and folders themselves are work objects (Work-Folder- class), so options C and D are false.

In Pega's covering feature, both the Cover (parent) and Covered (child) work objects must belong to the same ClassGroup. This requirement ensures proper inheritance and processing rules apply consistently. AccessGroup and WorkPool control different aspects of security and work routing.

Direct Inheritance is mandatory when creating a class - every class must specify its direct parent class using direct inheritance. Pattern Inheritance is optional and provides additional fallback mechanisms for rule resolution beyond the direct inheritance chain.

Pattern inheritance works by removing the trailing dash segment and moving up the hierarchy. For MICO-Finance-, removing the trailing dash gives Mico-Finance as the pattern inheritance parent. This is how Pega's pattern inheritance algorithm navigates the class structure.

In Pega's access control inheritance model, when an access role is specified at a parent class level, it automatically applies to that parent class AND all its child classes throughout the class hierarchy. This cascading inheritance ensures consistent permissions across related classes. However, if a child class has an explicit access rule that overrides the inherited role, the child's specific rule takes precedence for that class.

Pega property types starting with pz are protected system properties that cannot be modified. Properties starting with px are standard Pega properties that can be modified, and py properties are also editable. The pz prefix designation is specifically reserved for locked, read-only system properties that maintain platform integrity.

In Pega's class hierarchy, ordinary work objects inherit from the Work-Object- base class, making option B true. Covered work objects inherit from Work-Cover- class, not Cover-Object-. Folders can contain multiple covered work objects, and folders themselves are typically organizing structures rather than work objects.