Object-Oriented Technology and Programming

X": True False False False True False ROR_Z"s False False True nd -add Most object-oriented languages have the following key characteristics. ts.activi modifier cted_ob lame]. se int ("please select exactl To OPERATOR CLASSES ---

3 slides · 2 min read · Domain 8

Slide 1

Encapsulation

Encapsulation is also referred to as data accidentally access other data, which is hiding. A class defines only the data it needs a great security capability, and as we've to be concerned with. When an instance mentioned, referred to as data hiding or of that class, which is referred to as an encapsulation. object, is run, the code will not be able to

Inheritance

The concept of a data class makes it possible to define subclasses of data objects that share some or all of the main (or super) class characteristics. If security is properly implemented in the high-level class, then subclasses should inherit that security.

The same is true of objects derived not from a class but from another object. The keys are to properly implement security in the high-level class objects so that the subclasses can inherit them properly. It is very important to create objects that have good security characteristics because these can be inherited by further objects.

Polymorphism

Allowing an object to "take many forms" based on how it is used means that changes to an object do not have to ripple out into every application's program that uses that object. For example, an object called "customer" may be defined to contain a variety of information such as names, addresses, points of contact, and so on. Sales applications using that object might need to know about credit limits and previous order histories but would not need to deal with invoice processing or problems with late payments.

Different Data Types

Objects of differing data types can be processed differently, depending on that data type. Instantiating an object from a prior object ensures that the new object inherits attributes and methods from the original.

The customer object might be modified to support the credit limit data and methods (such as Set, Modify, or Get), and only those apps that need to use it must be changed. In non-OOP environments, adding a field to a customer record may require every software element that reads or writes that record type to be modified to include the new field, even if it is not used by that application's logic or function.

The changing characteristics of an object created in such a way may change the operation of the modified object. From a security perspective, this may have negative implications that must be carefully assessed, because secure methods may be lost through polymorphism and changing characteristics.

Test this domain