Object-oriented programming languages include SmallTalk, C , Java programming languages, and C # (a language provided in Microsoft .NET development environment). These languages support data and operational code packages in accordance with the requirements of abstract data types (commonly referred to as classes). In object-oriented programming languages, packaging capabilities are sufficient for moderate sizes. As long as the software module is maintained by a separate programmer, the package is fully sufficient for providing some intrinsic advantages. However, the package is not sufficient to support software repeated use and distributed systems. In object-oriented techniques, the basic examples are changed to the separation of the allowable relationship. Figure 1 shows a paradigm for object-oriented technology, which is divided into smaller segments called objects (Object). Each object contains some data of the system, and the program encapsulates these data. In other words, these data can only be accessed by using programs directly related to the data. In this way, the system is separated into independently changing modules. Any change in data performance simply affects the direct object of encapsulating the data. Object uses messages to each other. The message may affect the state - in other words, it is to change the data - but can only change it by a package that is closely related to the local data. For small procedures, object paradigms are valid for isolation changes. However, this paradigm is not perfect for all possible use situations. Object-oriented technology is now widely used. Generally speaking techniques come from academia, object-oriented technologies from commercial organizations. It actually has a lot of interesting origins to object technology, even dating back to the beginning of computer science. Today's object technology is now a commercial software paradigm with rule status. In fact, each software producer provides an object technology solution and provides a lower constructor of the component, allowing interaction between software vendors in different software environments. Object-oriented architecture For primary software development practitioners, object-oriented is lack of software architectural methods. This lack is in many ways in many ways. From the IO (object-oriented) thinking, the design of object-oriented software [Wirfs-BROCK 1990] is designed to start, including the concept of software architecture, including the collaboration map (Collaboration Diagram, it needs a chapter to speak Clear) Discovery Subsystem. In the next decade, there is almost no thing about the architecture in the object-oriented community. The main OO methodology is small in the chapter of the architecture. They are all blurred reflections of Wirfs-Brock architecture concept. Due to virtually there is virtually no monographs about the architecture, most OO practitioners have only the most basic architectural guidance. They have no reason to think that the architecture is very important. This attitude leads to a lot of confusion in the OO project, because the team members must do their best to manage the complexity and scalability of the OO method designed to design. In general, the OO method contains successful object model techniques, and most of these models are ultimately converted to programming objects. This method is called a model-based method. In order to understand the architecture, it is considered that each decomposition object is inevitably become a major obstacle to all OO developers need to overcome. In architecture models, specific objects are constrained instead of programming objects. They may be, may not be converted into programming objects, which is determined by the developer's own decision. OO is also contradictory in other small places and architectures, which is related to project culture. OO encourages project team equality, so all decisions are democratic. There is no architecture role in such a project because the difference in decisions made between the members of the development team is small. OO encourages the development of "bad-is-better" in the development, in fact, this is a philosophy against architecture.
