Java visual programming and beans

So far, we've seen how valuable Java can be in creating reusable pieces of code. The "Maximum reusable" unit of code has a class because it contains a tightly coupled unit attribute (field) and Unit action (method) that can be reused directly or through inheritance.
Inheritance and polymorphism are the essence of object-oriented programming, but in most cases when we create an application, what we really want most is the component we need most. We want to set these parts in our design just as an electronic engineer creates an integrated circuit block on the board (in the case of Java, it's on a Web page). This seems to be the development of a method for speeding up the programming of this "modular set".
"Visual Programming" was the first success--very successful--thanks to Microsoft's Visual Basic (VB, Visual Basic language), followed by the second generation of Borland company Delphi (a client/Server database application development tool, Java The main inspiration for beans design). The image of the components of these programming tools is visualization, which is indisputable, because they usually show some types of visual components, such as a TextField or a. In fact, visualization typically shows that a component can access a running program with great precision. So part of the visual programming method consists of dragging and dropping a component from a palette and putting it into our form. The application Creation tool writes the program code as we do, which causes the components in the running program to be created.
Simply dragging and dropping components into a form is usually not sufficient to form a complete program. In general, we need to change the characteristics of the component, such as the color of the component, the text of the component, the database of the component links, and so on. Attributes can be modified when they are programmed by reference to properties. We can skillfully dispose of the attributes of our components in the Application builder, and when we create the program, the build data is saved, so when the program is started, the data can be restored.
By now, we may be accustomed to using multiple attributes of an object, which is also a collection of actions. At design time, the actions of a visual component can be represented partially by the event, meaning that "any event can occur on the component." Typically, we decide what events we want to happen, and when an event occurs, connect the code to the event that occurs.
This is a critical part: The Application builder can dynamically ask the component (using the image) to discover the events and widgets supported by the component. Once it knows their state, the application Builder can display the attributes of the components and allow us to modify their properties (when we build the program, save their state), and also display these events. In general, we do events like double-clicking an event and the application builder creating a code and connecting to the event. When the event occurs, we have to write code to execute. The application build tool accumulates a lot of work for us. As a result, we can notice that the program looks like it's supposed to run, and relies on the application builder to manage the details of the connection for us. The reason that visual programming tools are so successful is that they obviously speed up the process of building an application-and, of course, the user interface is as good as part of the application.