Interview questions 3 Flashcards
- In Java, what are some differences between object types (classes) and primitive types?
Primitive types have no behavior (i.e. methods) of their own; all object types have at least the methods defined in the Object class.
Values of primitive-type arguments are passed directly on the stack when invoking methods;
similarly, primitive-type local variables are allocated directly on the stack. On the other hand, object-type fields, variables, and parameters actually contain references (pointers) to those object instances, located in the heap; thus, object-type arguments and local variables
appear on the stack as references, but the contents of the objects themselves remain in the heap.
For primitive types, equality/inequality are always tested for in terms of value, using the traditional relational operators: == , != , > , < , >= , and <= . For object-types, the == and != operators are tests for equality and inequality (respectively) of reference value, or identity—that is, whether two object references refer to the same object in the heap. In general, to compare for equality or inequality of state (i.e. content value) of objects, we must override the equals method.
- In general terms, explain how the following ternary expression is evaluated:
a ? b : c
The value of the ternary expression is dependent on the value of the first argument— the boolean expression preceding the question mark: if its value is true , then the value of the entire expression is taken from the second argument (following ? and preceding : ); otherwise, the value is taken from the third argument (following the : ).
What do we mean when we say an object of some class (e.g. String ) is immutable?
Immutability means that an object’s state is not allowed to change after initialization (which
ends on completion of the constructor execution). Immutability allows us to reason more
confidently about the state of an object in use, and may also allow the compiler to optimize
access to that object.
? What are some
advantages/disadvantages to immutability? A
Classes that have immutable instances
use the final modifier on all instance fields,
and thus don’t supply setters for
such fields
(the absence of setters for final fields is enforced by the compiler).
Aside from String , what are some other classes with
immutable instances?
Apart from String , the most widely used examples of immutable classes in the Java standard library are the wrapper classes ( Boolean , Byte , Character , Double , Float , Integer , Long , Short ) and other subclasses of Number ( BigInteger , BigDecimal ). The java.util.regex.Pattern class and all of the classes in the java.time package (introduced in Java 8) are immutable as well. In the Java standard library, as well as many 3 -party libraries, it’s quite common for classes that are instantiated using the builder pattern or some variation of the factory pattern (including, for these purposes, static factory methods) to have immutable instances; however, it is not required for implementations of such patterns to produce immutable objects. On the other hand, the classes that implement the builders themselves (e.g. StringBuilder ) are virtually always mutable
? What are some classes with mutable instances?
n the Java standard library, as well as many 3 -party libraries, it’s quite common for classes that are instantiated using the builder pattern or some variation of the factory pattern (including, for these purposes, static factory methods) to have immutable instances; however, it is not required for implementations of such patterns to produce immutable objects. On the other hand, the classes that implement the builders themselves (e.g. StringBuilder ) are virtually always mutable. Other mutable classes include almost all of the classes in the Java collections framework. (Note that there are some specialized subclasses—many instantiated through static factory methods of the Collections utility class or static factory methods of the List , Set , and Map interfaces—that produce immutable sets, lists, and maps.) UI controls are usually mutable, to permit changing their state (including enabling/disabling, hiding/showing, selecting/unselecting, filling/clearing, etc.) during execution. Entity classes in ORM frameworks (e.g. Room, Hibernate/JPA) are generally implemented to be mutable. On the other hand, the corresponding DAO/repository classes (the final implementations of which are generally constructed by the ORM itself) are usually immutable, since they are intended to be used as stateless service classes.
- In comparing Java objects for equality, how do the expressions object1.equals(object2) and
object1 == object2 differ in functionality?
For primitive types (which have no methods, and which thus can’t use the equals method),
the == operator is a value comparison: it compares the actual primitive values (with any
appropriate automatic widening performed first) for equality. However, in Java, all object
fields and variables are actually references (essentially, pointers) to the object instances on
the heap. When we use the == operator to compare object instances, it’s still a value
comparison, but of reference values; that is, it returns true if the compared references both
refer to the same location. In practical terms, this is an identity comparison: Are the referredto instances actually a single instance—that is, do they have the same identity?
The equals method provides a mechanism for comparing the state (contents) of two object
instances. Note, however, that this functionality is not implemented automatically: a class
that needs this kind of comparison between instances must override the equals method to
do so, or inherit an equals implementation that is sufficient for the task. (The equals
implementation in the Object class is generally not sufficient for comparison of instance
state: for example, if we have 2 instances of the Object class, obj1 and obj2 ,
obj1.equals(obj2) simply returns the value of obj1 == obj2 , which—as stated above—is
an identity comparison.)
What is encapsulation? What are some benefits of encapsulation?
Encapsulation is the practice of organizing code in a modular fashion (for example, in Java classes), so that data elements (e.g. fields) are packaged together with the subroutines (methods) that perform operations on those elements, and so that access to the data by code outside a given module is restricted or prevented. In terms more specific to Java, the fields of a well-encapsulated class are private , and any access to such fields (if required) is permitted only via the methods of the class
What are some benefits of encapsulation
A well-encapsulated class gives no direct outside access to its internal state; thus, that state is much less susceptible to unintended side-effects (or deliberate mischief) of implementation code in other classes. Encapsulation allows the class implementation to change, with minimal impact on consumers, as long as the public interface (the signatures, return types, exceptions, and modifiers of the class’s public methods) and functional behavior remains unchanged.
. Explain the difference(s) between composition and inheritance.
In inheritance (more specifically in this context, implementation inheritance, where a class extends another class), the subclass has an is-a relationship with the superclass. It inherits the superclass’s behaviors, and may be treated as an instance of the superclass type. In composition, the new class doesn’t extend the existing class of interest, but instead includes a field of the existing class type; in other words, the relationship between the new class and the existing class is has-a, rather than is-a.
What is a JavaBean?
The ‘beans’ of JavaBeans are classes that encapsulate one or more objects into a single standardized object (the bean).
This standardization allows the beans to be handled in a more generic fashion, allowing easier code reuse and introspection. This in turn allows the beans to be treated as software components, and to be manipulated visually by editors and IDEs without needing any initial configuration, or to know any internal implementation details.
What are some important lifecycle methods in Android apps?
The main entry point of an Android application is the Application.onCreate method.
In an Activity , the basic lifecycle methods are:
onCreate
Invoked only once after the activity instance is instantiated, when it enters the created state. On completion, the activity is moved to the started state.
onStart
Invoked when an activity enters the started state. On completion, the activity is visible, and moves to the resumed state.
onResume
Invoked when the activity enters the resumed state. In this state, the user can interact with the activity; thus, any final processing that must be performed to make the user interface ready should be performed in this method.
onPause
Invoked in the paused state, during which the user cannot interact with it (e.g. when the activity is being moved to the background to display the carousel of open apps).
onStop
Invoked when the activity moves to the stopped state. In this state, the activity is
completely hidden by another activity.
onRestart Invoked when a previously stopped activity is displayed again. After this method completes, the activity is in the created state, in which onStart will be invoked again.
onDestroy :Invoked prior to Android destroying a stopped activity—which may be because the activity is being closed, or because it must be re-created, following a configuration change.
A Fragment has lifecycle methods similar to those in Activity , as well as others
specifically related to attaching/detaching a fragment to/from a host activity.
what is the primary lifecycle method in a java application
In a Java application, the primary lifecycle method is the main method: For most purposes, we consider the application started when the main method begins execution, and (ignoring for now the possibility that additional threads are started by the application) when main completes, the application terminates.
Most frameworks/platforms for developing and running more advanced Java-language applications define additional lifecycle methods, representing critical points in the execution of a program. In some (such as the Android platform), we don’t even have access to the main method; in those cases, we
write our programs by overriding/implementing other lifecycle methods, and invoking our own methods as appropriate
. In Java source code, what is an annotation?
An annotation is a special source code construct that attaches additional information
inspectable at compile-time or runtime—to the annotated element.
Can you give some examples of annotations, how those
annotations are used, and the purpose they serve?
An annotation type is a special interface type, distinguished from a non-annotation-type interface
by the use of the @ symbol before the interface keyword in its definition. Each annotation type
is defined with a scope (specifying whether a reference in source code to the given annotation
type is included in the byte code, and further into the in-memory content of an initialized class).
An annotation type is also defined with a target, specifying the source code elements (packages,classes, interfaces, constructors, methods, fields, parameters, local variables, or other annotations) that may be annotated with the given annotation type.
An annotation is a reference to a defined annotation type, included in source code via the @ symbol, followed by the name of the annotation type. Such a reference annotates the element that follows the annotation, as long as that element is a supported target (otherwise, a compiletime error will result). For example, if an annotation type that is defined to target methods is used
before a field, this will result in an error.
