I know that C++ defines things called destructors, which are automatically executed when an object is destroyed. Is finalize( ) similar to a destructor?
Java does not have destructors. Although it is true that the finalize( ) method approximates the function of a destructor, it is not the same. For example, a C++ destructor is always called just before an object goes out of scope, but you can’t know when finalize( ) will be called for any specific object. Frankly, because of Java’s use of garbage colle ction,there is little need for a destructor.
Search This Blog
Java :Question with Answer
You say that once created, String objects are immutable. I understand that, from a
practical point of view, this is not a serious restriction, but what if I want to create a string that can be changed?
You’re in luck. Java offers a class called StringBuffer, which creates string objects
that can be changed. For example, in addition to the charAt( ) method, which obtains
the character at a specific location, StringBuffer defines setCharAt( ), which sets a
character within the string. However, for most purposes you will want to use String,
not StringBuffer.
practical point of view, this is not a serious restriction, but what if I want to create a string that can be changed?
You’re in luck. Java offers a class called StringBuffer, which creates string objects
that can be changed. For example, in addition to the charAt( ) method, which obtains
the character at a specific location, StringBuffer defines setCharAt( ), which sets a
character within the string. However, for most purposes you will want to use String,
not StringBuffer.
Why does String define the equals( ) method? Can’t I just use ==?
The equals( ) method compares the character sequences of two String objects for
equality. Applying the == to two String references simply determines whether the two
references refer to the same object.
equality. Applying the == to two String references simply determines whether the two
references refer to the same object.
When should I make an instance variable private?
There are no hard and fast rules, but here are two general principles. If an instance
variable is to be used only by methods defined within its class, then it should be made private. If an instance variable must be within certain bounds, then it should be private and made available only through accessor methods. This way, you can prevent invalid values from being assigned.
variable is to be used only by methods defined within its class, then it should be made private. If an instance variable must be within certain bounds, then it should be private and made available only through accessor methods. This way, you can prevent invalid values from being assigned.
The javadoc Tags
Tag Meaning
@author Identifies the author of a class.
@deprecated Specifies that a class or member is deprecated.
{@docRoot} Specifies the path to the root directory of the current documentation. (Added by Java
2, version 1.3.)
@exception Identifies an exception thrown by a method.
{@inheritDoc} Inherits a comment from the immediate superclass. (Added by Java 2, version 1.4, butnot currently implemented.)
{@link} Inserts an in-line link to another topic.
{@linkplain} Inserts an in-line link to another topic, but the link is displayed in a plain-text font.(Added by Java 2, version 1.4.)
@param Documents a method’s parameter.
@return Documents a method’s return value.
@see Specifies a link to another topic.
@serial Documents a default serializable field.
@serialData Documents the data written by the writeObject( ) or writeExternal( ) methods.
@serialField Documents an ObjectStreamField component.
@since States the release when a specific change was introduced.
@throws Same as @exception.
{@value} Displays the value of a constant, which must be a static field. (Added by Java 2,version 1.4.)
@version Specifies the version of a class.
@author Identifies the author of a class.
@deprecated Specifies that a class or member is deprecated.
{@docRoot} Specifies the path to the root directory of the current documentation. (Added by Java
2, version 1.3.)
@exception Identifies an exception thrown by a method.
{@inheritDoc} Inherits a comment from the immediate superclass. (Added by Java 2, version 1.4, butnot currently implemented.)
{@link} Inserts an in-line link to another topic.
{@linkplain} Inserts an in-line link to another topic, but the link is displayed in a plain-text font.(Added by Java 2, version 1.4.)
@param Documents a method’s parameter.
@return Documents a method’s return value.
@see Specifies a link to another topic.
@serial Documents a default serializable field.
@serialData Documents the data written by the writeObject( ) or writeExternal( ) methods.
@serialField Documents an ObjectStreamField component.
@since States the release when a specific change was introduced.
@throws Same as @exception.
{@value} Displays the value of a constant, which must be a static field. (Added by Java 2,version 1.4.)
@version Specifies the version of a class.
Java : Fundamental Question and Answer
To address the issues of portability and security, why was it necessary to create a
new computer language such as Java; couldn’t a language like C++ be adapted? In
other words, couldn’t a C++ compiler that outputs bytecode be created?
While it would be possible for a C++ compiler to generate bytecode rather than
executable code, C++ has features that discourage its use for the creation of
applets—the most important feature being C++’s support for pointers. A pointer is the
address of some object stored in memory. Using a pointer, it would be possible to access resources outside the program itself, resulting in a security breach. Java does not support pointers, thus eliminating this problem
new computer language such as Java; couldn’t a language like C++ be adapted? In
other words, couldn’t a C++ compiler that outputs bytecode be created?
While it would be possible for a C++ compiler to generate bytecode rather than
executable code, C++ has features that discourage its use for the creation of
applets—the most important feature being C++’s support for pointers. A pointer is the
address of some object stored in memory. Using a pointer, it would be possible to access resources outside the program itself, resulting in a security breach. Java does not support pointers, thus eliminating this problem
Java : Fundamental Question and Answer
Does the use of a code block introduce any run-time inefficiencies? In other words,
does Java actually execute the { and }?
No. Code blocks do not add any overhead whatsoever. In fact, because of their ability
to simplify the coding of certain algorithms, their use generally increases speed and
efficiency. Also, the { and } exist only in your program’s source code. Java does not,per se, execute the { or }.
does Java actually execute the { and }?
No. Code blocks do not add any overhead whatsoever. In fact, because of their ability
to simplify the coding of certain algorithms, their use generally increases speed and
efficiency. Also, the { and } exist only in your program’s source code. Java does not,per se, execute the { or }.
Java : Fundamental Question and Answer
You state that object-oriented programming is an effective way to manage large programs. However, it seems that it might add substantial overhead to relatively
small ones. Since you say that all Java programs are, to some extent, object-oriented,does this impose a penalty for smaller programs?
No. As you will see, for small programs, Java’s object-oriented features are nearly
transparent. Although it is true that Java follows a strict object model, you have
wide latitude as to the degree to which you employ it. For smaller programs, their
“object-orientedness” is barely perceptible. As your programs grow, you will integrate
more object-oriented features effortlessly
small ones. Since you say that all Java programs are, to some extent, object-oriented,does this impose a penalty for smaller programs?
No. As you will see, for small programs, Java’s object-oriented features are nearly
transparent. Although it is true that Java follows a strict object model, you have
wide latitude as to the degree to which you employ it. For smaller programs, their
“object-orientedness” is barely perceptible. As your programs grow, you will integrate
more object-oriented features effortlessly
Semantic Data Model
A semantic data model in software engineering is a technique to define the meaning of data within the context of its interrelationships with other data. A semantic data model is an abstraction which defines how the stored symbols relate to the real world. A semantic data model is sometimes called a conceptual data model.
The logical data structure of a database management system (DBMS), whether hierarchical, network, or relational, cannot totally satisfy the requirements for a conceptual definition of data because it is limited in scope and biased toward the implementation strategy employed by the DBMS. Therefore, the need to define data from a conceptual view has led to the development of semantic data modeling techniques. That is, techniques to define the meaning of data within the context of its interrelationships with other data. As illustrated in the figure. The real world, in terms of resources, ideas, events, etc., are symbolically defined within physical data stores. A semantic data model is an abstraction which defines how the stored symbols relate to the real world. Thus, the model must be a true representation of the real world
The logical data structure of a database management system (DBMS), whether hierarchical, network, or relational, cannot totally satisfy the requirements for a conceptual definition of data because it is limited in scope and biased toward the implementation strategy employed by the DBMS. Therefore, the need to define data from a conceptual view has led to the development of semantic data modeling techniques. That is, techniques to define the meaning of data within the context of its interrelationships with other data. As illustrated in the figure. The real world, in terms of resources, ideas, events, etc., are symbolically defined within physical data stores. A semantic data model is an abstraction which defines how the stored symbols relate to the real world. Thus, the model must be a true representation of the real world
Generic data model
Generic data models are generalizations of conventional data models. They define standardised general relation types, together with the kinds of things that may be related by such a relation type. Generic data models are developed as an approach to solve some shortcomings of conventional data models. For example, different modelers usually produce different conventional data models of the same domain. This can lead to difficulty in bringing the models of different people together and is an obstacle for data exchange and data integration. Invariably, however, this difference is attributable to different levels of abstraction in the models and differences in the kinds of facts that can be instantiated (the semantic expression capabilities of the models). The modelers need to communicate and agree on certain elements which are to be rendered more concretely, in order to make the differences less significant.
Geographic data model
A data model in Geographic information systems is a mathematical construct for representing geographic objects or surfaces as data. For example, the vector data model represents geography as collections of points, lines, and polygons; the raster data model represent geography as cell matrixes that store numeric values; and the Triangulated irregular network (TIN) data model represents geography as sets of contiguous, nonoverlapping triangles
Entity-relationship model
An entity-relationship model is an abstract conceptual data model (or semantic data model) used in software engineering to represent structured data. Entity relationship models (ERMs) produce a conceptual data model of a system, and its requirements in a top-down fashion. There are several notations for data modeling. The actual model is frequently called "Entity relationship model", because it depicts data in terms of the entities and relationships described in the data.
Data Structure Diagram
Example of a Data Structure Diagram.
A data structure diagram (DSD) is a diagram and data model used to describe conceptual data models by providing graphical notations which document entities and their relationships, and the constraints that binds them. The basic graphic elements of DSDs are boxes, representing entities, and arrows, representing relationships. Data structure diagrams are most useful for documenting complex data entities.
Data structure diagrams are an extension of the entity-relationship model (ER model). In DSDs, attributes are specified inside the entity boxes rather than outside of them, while relationships are drawn as boxes composed of attributes which specify the constraints that bind entities together. The E-R model, while robust, doesn't provide a way to specify the constraints between relationships, and becomes visually cumbersome when representing entities with several attributes. DSDs differ from the ER model in that the ER model focuses on the relationships between different entities, whereas DSDs focus on the relationships of the elements within an entity and enable users to fully see the links and relationships between each entity.
A data structure diagram (DSD) is a diagram and data model used to describe conceptual data models by providing graphical notations which document entities and their relationships, and the constraints that binds them. The basic graphic elements of DSDs are boxes, representing entities, and arrows, representing relationships. Data structure diagrams are most useful for documenting complex data entities.
Data structure diagrams are an extension of the entity-relationship model (ER model). In DSDs, attributes are specified inside the entity boxes rather than outside of them, while relationships are drawn as boxes composed of attributes which specify the constraints that bind entities together. The E-R model, while robust, doesn't provide a way to specify the constraints between relationships, and becomes visually cumbersome when representing entities with several attributes. DSDs differ from the ER model in that the ER model focuses on the relationships between different entities, whereas DSDs focus on the relationships of the elements within an entity and enable users to fully see the links and relationships between each entity.
Database model :Types of data models
A database model is a theory or specification describing how a database is structured and used. Several such models have been suggested.
* Flat model: This may not strictly qualify as a data model. The flat (or table) model consists of a single, two-dimensional array of data elements, where all members of a given column are assumed to be similar values, and all members of a row are assumed to be related to one another.
* Hierarchical model: In this model data is organized into a tree-like structure, implying a single upward link in each record to describe the nesting, and a sort field to keep the records in a particular order in each same-level list.
* Network model: This model organizes data using two fundamental constructs, called records and sets. Records contain fields, and sets define one-to-many relationships between records: one owner, many members.
* Relational model: is a database model based on first-order predicate logic. Its core idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values.
* Flat model: This may not strictly qualify as a data model. The flat (or table) model consists of a single, two-dimensional array of data elements, where all members of a given column are assumed to be similar values, and all members of a row are assumed to be related to one another.
* Hierarchical model: In this model data is organized into a tree-like structure, implying a single upward link in each record to describe the nesting, and a sort field to keep the records in a particular order in each same-level list.
* Network model: This model organizes data using two fundamental constructs, called records and sets. Records contain fields, and sets define one-to-many relationships between records: one owner, many members.
* Relational model: is a database model based on first-order predicate logic. Its core idea is to describe a database as a collection of predicates over a finite set of predicate variables, describing constraints on the possible values and combinations of values.
Data Model
A data model in software engineering is an abstract model that describes how data are represented and accessed. Data models formally define data elements and relationships among data elements for a domain of interest. According to Hoberman (2009), "A data model is a wayfinding tool for both business and IT professionals, which uses a set of symbols and text to precisely explain a subset of real information to improve communication within the organization and thereby lead to a more flexible and stable application environment.
Database Design :Design process
The process of doing database design generally consists of a number of steps which will be carried out by the database designer. Not all of these steps will be necessary in all cases. Usually, the designer must:
* Determine the relationships between the different data elements
* Superimpose a logical structure upon the data on the basis of these relationships.
Within the relational model the final step can generally be broken down into two further steps, that of determining the grouping of information within the system, generally determining what are the basic objects about which information is being stored, and then determining the relationships between these groups of information, or objects. This step is not necessary with an Object database.
The tree structure of data may enforce a hierarchical model organization, with a parent-child relationship table. An Object database will simply use a one-to-many relationship between instances of an object class. It also introduces the concept of a hierarchical relationship between object classes, termed inheritance
* Determine the relationships between the different data elements
* Superimpose a logical structure upon the data on the basis of these relationships.
Within the relational model the final step can generally be broken down into two further steps, that of determining the grouping of information within the system, generally determining what are the basic objects about which information is being stored, and then determining the relationships between these groups of information, or objects. This step is not necessary with an Object database.
The tree structure of data may enforce a hierarchical model organization, with a parent-child relationship table. An Object database will simply use a one-to-many relationship between instances of an object class. It also introduces the concept of a hierarchical relationship between object classes, termed inheritance
Database Design :Physical database design
The physical design of the database specifies the physical configuration of the database on the storage media. This includes detailed specification of data elements, data types, indexing options and other parameters residing in the DBMS data dictionary. It is the detailed design of a system that includes modules & the database's hardware & software specifications of the system.
DatabaseDesign :Logically structuring data
Once the relationships and dependencies amongst the various pieces of information have been determined, it is possible to arrange the data into a logical structure which can then be mapped into the storage objects supported by the database management system. In the case of relational databases the storage objects are tables which store data in rows and columns.
Each table may represent an implementation of either a logical object or a relationship joining one or more instances of one or more logical objects. Relationships between tables may then be stored as links connecting child tables with parents. Since complex logical relationships are themselves tables they will probably have links to more than one parent.
In an Object database the storage objects correspond directly to the objects used by the Object-oriented programming language used to write the applications that will manage and access the data. The relationships may be defined as attributes of the object classes involved or as methods that operate on the object classes.
Each table may represent an implementation of either a logical object or a relationship joining one or more instances of one or more logical objects. Relationships between tables may then be stored as links connecting child tables with parents. Since complex logical relationships are themselves tables they will probably have links to more than one parent.
In an Object database the storage objects correspond directly to the objects used by the Object-oriented programming language used to write the applications that will manage and access the data. The relationships may be defined as attributes of the object classes involved or as methods that operate on the object classes.
Database :Conceptual schema
Once a database designer is aware of the data which is to be stored within the database, they must then determine where dependancy is within the data. Sometimes when data is changed you can be changing other data that is not visible. For example, in a list of names and addresses, assuming a situation where multiple people can have the same address, but one person cannot have more than one addresses, the name is dependent upon the address, because if the address is different then the associated name is different too. However, the other way around is different. One attribute can change and not another.
Database :Conceptual schema
Once a database designer is aware of the data which is to be stored within the database, they must then determine where dependancy is within the data. Sometimes when data is changed you can be changing other data that is not visible. For example, in a list of names and addresses, assuming a situation where multiple people can have the same address, but one person cannot have more than one addresses, the name is dependent upon the address, because if the address is different then the associated name is different too. However, the other way around is different. One attribute can change and not another.
Subscribe to:
Posts (Atom)