Sunday, July 11, 2010

Membuat Program Tanggal di Java

Lagi duduk2 sambil nunggu final piala dunia,,, tiba2 kepikiran untuk posting... Kali ini mw buat "Program Tanggal di Java", disini saya membuat programnya dengan netbeans, sebenarnya gak jauh beda buat program java di netbeans n bukan netbeans, asalkan paham konsepnya. Ok deh dari pada basa-basi lagi mending langsung aja.. pertama buka netbeans anda dan ikuti aturan pembuatannya. Setelah anda ikuti aturan pembuatannya anda tuliskan source code seperti dibawah ini.

import java.text.SimpleDateFormat;
import java.util.Date;

/**
*
* @author Administrator
*/
public class Tanggal {

public static void main(String[] args) {
Date tanggal = new Date();

SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd");
System.out.println(sdf.format(tanggal));
sdf = new SimpleDateFormat("HH:MM:ss");

System.out.println(sdf.format(tanggal));
}
}

Lalu anda jalankan program dengan mengklik Run-Run MainProject(F6). Dan berikut adalah hasil programnya.



read more...

Wednesday, July 7, 2010

Cara BackUp Driver

Beberapa hari yang lalu ditawarin instal ulang laptop, tapi dengan catatan drivernya gak da, jadi waktu otak-atik om goole coba2 nyari deh di Internet, driver untuk BackUp driver, eh.. ternyata ada, n lumayan software yang ditawarkan, salah satunya adalah software DriverMax3.4. DriverMax 3.4 termasuk software yang paling mudah dalam pengoperasiannya. Cara pakainya mudah.

Pertama-tama anda persiapkan dahulu software DriverMax 3.4, anda dapat mendownload DISINI.

1. Instal program DriverMax 3.4 seperti software pada umumnya.

2. Setelah selasai bisa langsung mulai BackUp Driver Laptop kamu, berikut tahapan2nya.
  • Arahkan kursor anda pada driver BackUp And Restore dan pilih BackUp Drivers. Simpan pada space yang tidak akan dihapus seperti di partisi D atau E jika mempunyai partisi E.
  • Ok, anda siap untuk mengistal Ulang Laptop Atau Komputer Anda.
  • Setelah anda selesai menginstal ulang, anda instal kembali Driver Max 3.4, Lalu arahkan kursor anda pada Driver BackUp And Restore dan anda Pilih Restore, ikuti saja selanjutnya, dan menuggu beberapa menit, driver anda kembali seperti biasa.
Ok... Selamat Mencoba

read more...

Tuesday, July 6, 2010

Displaying an Object’s State

Being able to view the state of an object is vitally important to class development, client use, and code maintenance. Being forced to index and display individual values is too tedious and far too time-consuming. MATLAB provides a decent display mechanism for scalars, arrays, and structures. Our classes deserve no less. As we have seen, MATLAB does not provide a good built-in display for objects, but now we know how to tailor functions to do whatever we want. All we need to know is the name of the built-in function.

1. DISPLAYING OBJECTS
MATLAB’s two primary display functions are display.m and disp.m. The biggest difference
between them is a connection between display and the semicolon operator. When a semicolon terminates a command, MATLAB does not call display. The opposite statement is also true. If a command does not end in a semicolon, MATLAB calls display. This behavior is very convenient and makes display a good overload candidate. Otherwise, all we will continue to see is the following cryptic message:
>> shape = cShape
shape =
cShape object: 1-by-1

Of course, we could also overload disp, sprintf, num2str, and evalc; however, these functions pale in convenience and importance to display . Developing a general solution for the other display functions does not add much value.

The function display is overloaded the same way any other function is overloaded. A customized member function named display.m is added to the class directory. After that, whenever display needs to operate on an object, the tailored version of display.m will be found. This is true when called directly as in display(shape), or indirectly by leaving off the semicolon.

1.1 WHAT SHOULD BE DISPLAYED?
The question of what to display might sound like a trick question, but it is not a trick. It isn’t easy to answer either. Unlike structures, objects have both public and private variables. Also different from structures, a public variable might be read-only, write-only, or read-write. There are also at least two audiences for the displayed information, clients and developers. The number of options makes it difficult to settle on a universal implementation for display.

In cShape, for example, developers might find it convenient to display stored HSV color values along with calculated RGB values. Developers and clients alike might like to see the value of mScale from time to time. Violating encapsulation by allowing client code to depend on private variables is a bad idea, but is it really a violation to allow a client to display internal states during client code debug and development? For some data and some developers, it might be okay. Once we nail down the kind of information to display, the implementation becomes easier. When deciding what should be displayed, there are at least three information categories or user-related topics to consider:

• value information for public member variables
• class membership lists and permissions
• class development and debug-related data

The first category represents a view that should look similar, if not identical, to a structure’s display. This helps extend the illusion of a class as a structure. Instead of structure elements, the display includes public member variables. We will call this the standard view. The second category represents a view that provides a brief summary of the interface, a summary that can often be used in lieu of help. The display for the second category should include a list of public member variables along with their type. A list of valid assignment values is also useful. The environment commands set(0) and get(0) can serve as a model for the display. The third category is intended primarily for class developers engaged in code development or maintenance.

This view is impossible to specify rigorously but should probably include all public member variables and often includes a large selection of private member variables. We will call this view developer view. For the first two views, MATLAB provides some guidance in the form of displays that exist elsewhere. For developer view, there really is no precedence. Developer view’s format is also more difficult to pin down because it is largely a matter of taste. Some developers prefer a standard structure-like display, some prefer a whos
-like format, and some prefer a format that provides even more detail. In fact, different formats can be useful during different stages of development. Developer view demands flexibility, and indeed, we can organize class variables and display to support flexibility.

Adding flexibility isn’t completely related to display. Part of the motivation is to reveal more ways that objects are fundamentally different from structures and develop some insight into how those differences might be exploited. Providing a design for display that allows almost unlimited flexibility serves many purposes. If we want to model the second-view category after get(0) and set(0), we need to develop tailored versions of these two functions. Once developed, get(cShape) and set(cShape) would display the appropriate lists. Like display, get and set are also members of the group of eight. The chapters in this section take on the group of eight one at a time. This chapter is devoted to display. Chapter 8 is devoted to get and set.

In any display, variables come in only four flavors:
• public member variables
• read-only public member variables
• write-only public member variables
• private member variables

There is almost universal agreement that standard view should include public member variables. After all, public variables are public for a reason and one of the best ways to advertise their availability is via display. Most also agree that the standard display should not include private variables. In some classes, it might make sense to include selected private variables, but generally, private variables are private for a reason. Omitting them from the standard view helps keep them private.

It is harder to reach a consensus on read-only and write-only variables. Part of the reason why it is difficult to decide is the observation that MATLAB’s structure display has no provision for such “oddly behaved” elements. We don’t have a firm foundation on which to base our opinions because read-only and write-only do not exist for structures. Perhaps the interface design can shed some light on these variables. In most situations, read-only and write-only permissions flow naturally from the class design and its interface definition. In a well-designed class with an intuitive interface, the idea of writing a value into a read-only variable should never occur. Even if the interface is not perfect, a client can display a read-only value even if it isn’t included in the standard display view.

This alone justifies including read-only variables in the standard view. Write-only variables are much less common. When the interface definition designates a variable as write-only, we should probably respect the designation. For this reason, we will not include write-only variables in the standard view. Modifications to standard display policy can always be addressed on a case-by-case basis.

Andy H. Register
read more...

Changing the Rules … in Appearance Only

Near the end of the previous chapter, I alluded to the fact that MATLAB gives us a way to tailor standard dot-reference syntax to suit the needs of our objects. In the eyes of our clients, dotreference tailoring makes an object look like a structure. This gives objects an enormous boost. If objects look like structures, using objects rather than structures is completely transparent. Transparency is a good thing because it gives us immediate access to a very powerful tool we can use to protect the integrity of our code, encapsulation.

The good news is that MATLAB allows dot-reference tailoring. In this chapter, we will develop a set of member functions that implement the tailoring in a way that allows objects to mimic structures. We will take advantage of a pair of standard, but relatively unknown, functions, subsref.m and subsasgn.m. The built-in versions operate on structures. Tailored versions, as long as MATLAB can find them, operate on objects. From Chapter 3, we know MATLAB will find them as long as they exist in the class directory as member functions. As tailored member functions, subsref.m and subsasgn.m are so critical to object-oriented programming that they share a place beside the constructor in the group of eight.

1. A SPECIAL ACCESSOR AND A SPECIAL MUTATOR
The reason these very important functions are not well-known is that outside the realm of object oriented programming, they are almost never called by name. MATLAB classifies these functions as operators in the same way it classifies symbols like +, -, /, and ~= as operators. There are many operators (see Table 4.1), but the distinguishing feature is syntax. When MATLAB encounters an operator, it orders the arguments and converts the operator’s symbol into a function call. Unless you understand what it means to be an operator, you might not realize what is going on behind the scenes. Shortly we will specifically examine subsref.m and subsasgn.m operators. First, let’s take a brief side trip to discuss operators and introduce a technique called operator overloading.

1.1 A SHORT SIDE TRIP TO EXAMINE OVERLOADING
Most of the symbols you can type from the keyboard have special meaning. The meanings behind +, -, /, and ~= are clear. These special symbols are called operators. When MATLAB interprets a line of code, it maps every operator to an m-file. Table 4.1 lists the mapping from symbol to mfile. From the command line, you can display a similar list using help ops. If you look at the list you see conversions like + => plus.m and <= => le.m. We can call these unctions by name, but we almost never do because operator syntax is a lot easier.

Stop for a minute and consider the implications. Every operator maps to an m-file, and the execution of every m-file is determined based on the search path. That means we can redefine the operation of any operator. All we have to do is create a new m-file with the same name as the operator and put it in a directory with a higher search-path priority. For objects, we simply put the tailored operator function in the class directory. Since MATLAB searches for member functions before it searches for built-in functions, the tailored function has higher priority. Clients use normal operator syntax, and MATLAB conveniently finds the appropriate function.



Object-oriented terminology calls this technique operator overloading, and every function in Table 1.1 can be overloaded. When MATLAB encounters operator syntax, it collects variables into argument lists and calls the operator’s function. Once you know the name of the operator’s function, you can display the function’s help information to get a description of the arguments. For example, the statement c = a + b; converts to the function equivalent c = plus(a, b);.

Operator overloading represents an important subset of general function overloading. General function overloading allows a class to customize the operation of virtually any function by including a tailored copy of the function in the class directory. Thus, any discussion of overloading involves two functions, the function doing the overloading and the function being overloaded. Let’s refer to the function doing the overloading as the tailored version and to the function being overloaded as the original version.
With very few exceptions, MATLAB allows a class to overload any function. The original function might exist as a built-in function or as a function on the path. If we jump ahead and consider inheritance, the original function might also exist as a parent-class function. In short, once a class overloads a function, the location of the original isn’t too important.

Given the ability to overload almost any function, you are also given the responsibility of doing it wisely. Unfortunately, this is an area where experience is the best guide. There are few hard-andfast rules, but there are some things to consider. Original functions are generally well understood, and overloading works best when the behavior of the tailored version can be inferred from the behavior of the original. The argument syntax of an original function is also well-known, and the tailored version should match the syntax very closely. This is particularly true for operator overloading because you can’t control the conversion from operator syntax to function call. The implementation examples and the group of eight represent a good resource for examining operator and function overloading. As we progress through the example code, you will be building experience.
read more...

Thursday, July 1, 2010

MATLAB’s Requirements

MATLAB forces very little on us in the way of requirements. This is both good and bad. To the good, it means that we have a lot of freedom to make the implementation match our particular need. It also means that we do not have to devote a lot of time toward learning an intricate set of requirements, nor do we have to devote effort toward implementing the requirements with our code.

To the bad, it means we must blaze our own trail without the benefit of requirements to keep us on track. Loose requirements provide enough rope to hang ourselves. It is too easy to weave a path that is difficult to maintain. In this chapter, we will learn how to meet requirements in a way that supports the needs of the group of eight. This helps keep MATLAB object-oriented programming on the straight and narrow.

A. VARIABLES, TYPES, CLASSES, AND OBJECTS
In every specialty, there are certain words that carry special meaning. At first glance, the sheer number of special words associated with object-oriented programming appears overwhelming. The sad fact that these words are sometimes misused does not help the situation. An additional burden comes in understanding slight differences among words that appear to be describing the same thing. Fortunately, mastering the vocabulary is not difficult. Most of the differences are anchored to the normal programming vocabulary.

In discussing object-oriented programming, the words class and object seem to suffer the most abuse. When you look closely at what these words actually represent, it is easy to understand why. After we carefully define both words, you will be able to follow discussions where the language is sloppy. This knowledge will also allow you to determine the competency of self professed experts.

The easiest way to explain the differences between class and object is to relate them to things you probably already know. Look at the MATLAB command-line listing provided in Code Listing.
1. First, let me reassure you. If the command syntax and results in Code Listing are familiar, you stand an excellent chance of taking full advantage of MATLAB object-oriented programming.
Look carefully at the information displayed by the whos command and you will notice, perhaps for the first time, a heading titled Class . I hope you find this particular word choice very interesting. You might complain that char and double are not classes but rather types. There’s no cause for alarm. In this particular context, class and type mean almost the same thing. Class is a slightly more specific term, one with special meaning to object-oriented programmers. In fact, the connection between class and type is so close that the term user-defined type is often used as a substitute for class.

You might reasonably wonder why the object-oriented pioneers felt the need to coin a new term. The short answer is that class represents a new category of a variable’s type in the same vein as array, cell, or structure. When we identify a variable as a double, its type attaches certain expectations to the variable. A class is more complicated than one of the simple types like double, char, or integer, but it still represents a type. We are comfortable with many of the simple or built in types because we know what to expect. By comparison, identifying a variable’s type as class is uncomfortable unless we already know what that means. Like me, you have probably forgotten that once upon a time, even the so-called simple types were not so simple. It took time and effort to arrive at a comfortable level of understanding for double, char, and cell. The same is true for class. Before long, the idea of class as simply another variable type will seem natural.

Learning about object-oriented programming will require some time and effort, and we certainly don’t want to take on all of the special properties at once. After all, even with numbers we started with 1, 2, and 3 before moving on to π and e.

Before moving on, go back to the whos display in Code Listing 1 and examine the information associated with variable x . Think about the low-level details that you usually take for granted. Reading from left to right, x is the name of the variable. What is a variable name? The variable’s name provides a human-readable reference to a value stored in memory. The variable’s size is listed as 1×1. From the size, we know that x is scalar. From the variable’s type, double, we know that x is a member of the set of real numbers. The type establishes limits on which functions to use and on the expected accuracy. At a glance, we know how x should behave and we take many details for granted.

So, what is x exactly? Is it a variable? a memory location? a scalar? a real number? … Of course, this is a trick question. Indeed, x represents all of those things and more. For algorithm design, the fact that x is double rather than complex or char is the primary focus. During code implementation, the variable’s name, structure, and indices become increasingly more important. During execution, MATLAB’s memory manager needs to know the physical address, the number of bytes, and so forth. No one is shocked that the meaning of x radically changes depending on context. This is exactly how we naturally cope with complexity. We avoid confusion by choosing to focus only on the features that are important to us right now.

Now I tell you that x is an object . Is it still a variable? Still located in memory? Still a scalar? … Of course! The new information that identifies x as an object does not change the fact that it is still double precision. Saying that x is an object merely attaches yet another feature to the variable x. In the whos display, Class simply puts built-in types and user-defined types on an equal footing. Some programmers might bristle at the use of class to describe common built-in types, but with MATLAB this attitude is misguided. The fact that double array is a class and x is an object opens many interesting options. We will examine many of these options as we progress through the various examples.

Class is simply another description used to organize variables. The choice of the word “class” must imply something, or one of the more common terms would have been used. A class is a formal description of something general, possibly a reusable data structure, an abstract concept, or a tangible thing. While there are often other supporting documents, the ultimate class description exists as class’ executable code. A class defines data elements and defines a set of functions used to operate on the elements. The data represent features or attributes and as a collection form the class’ outward appearance. MATLAB uses a structure to define the data elements. The class’ functions manipulate the data contained in the class’ structure. Functions are implemented using m-files. What makes a class different from a normal structure and set of m-files are the objectoriented rules that associate the data structure and the m-files in a way that they always exist together as a whole. In short, a class defines a data structure and an inseparable set of m-files designed to operate on that structure.

There must also be a difference between a class and an object. Objects relate to classes in the same way variables relate to types. During the course of a program’s execution, objects are created, used, and destroyed. The data structure for each object is unique and exists as a set of values stored in memory. Object x is different from object y because each occupies a different memory location. The structure of the data might be the same but the values can be different. All objects of the same class use the same set of class-specific m-files. The object’s data are always passed into these functions. In this way, the behavior is always consistent with a particular object’s data. In short, an object is a run-time entity that includes a type and individualized data.

Andy H. Register

read more...

Group of Eight in Matlab

MATLAB object-oriented rules dictate only one required function for each class. In practice, there are eight functions so fundamental to MATLAB object-oriented programming that each warrants its own chapter. Apart from each other, any one from this group of eight would be easy to describe, design, and code. Toy classes rarely use more than two or three of the eight, making their design easy. We are not interested in toy classes. In industrial-strength classes, the functions comprising this so-called group of eight always occur together, and each relies on functionality contained in the other members. In Chapter 1, we discussed dependency and coupling and concluded that such reliance requires careful attention to detail. Care is doubly important for the group of eight because these functions implement the most important part of any object, its interface. As you read along and consider the examples, keep the fact of coupling in mind. Sometimes it forces design decisions that become apparent only after the coupling partner is described, designed, and implemented.

As we will soon see, the notion of an interface goes hand in hand with the object-oriented concept of encapsulation. This first major section focuses on object-oriented encapsulation and develops an effective interface strategy. By the end of this section, the advantages of encapsulation along with the access rules enforced by MATLAB should be clear. Every function in the group of eight contributes to encapsulation. If you are wondering about the names of the group-of-eight functions, they are listed below. There are chapters in this section devoted to each member.

Functions belonging to the group of eight are :
  • constructor
  • subsref.m
  • subsasgn.m
  • display.m
  • struct.m
  • fieldnames.m
  • get.m
  • set.m
The required elements are the best place to begin. First, there are not many; and, second, the
required elements should exist in every class we write. After we cover the required elements, we will develop a set of optional elements that allow object-oriented variables to attain a status equal to built-in types. Without these optional elements, object-oriented code is difficult to use and maintain. After the optional elements, we examine strategies for atypical situations. This section covers all of the required and many of the optional object-oriented coding elements.

Andy H. Register

read more...