Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
The Story of Object-Oriented Programming In object-oriented programming, your program will be split into several small, manageable, reusable programs. Each small program has it’s own identity, data, logic and how it’s going to communicate with the rest of the other small programs. Objects When you think about Objects, you should think about the real world situations. Object-Orientation was intended to be closer to the real world, hence, make it easier and more realistic. What are the Objects?, Well, Objects could be: Something visible for you, like the car, phone, apple, duck, lamp. Something that you can’t touch, like the Time, Event, Account. Objects Each Objects has it’s own attributes, and behavior. Objects are separate from one another. They have their own existence, their own identity that is independent of other objects. What do we mean by attributes? It’s the characteristics or the properties of the Object, like for example, in case of a duck, it’s weight & color. They describe the current state of an object. The state of one object is independent of another. Maybe you will have a duck that’s white and another one is black. What do I mean by behavior? Behavior is things that the Object can do, in case of duck, It can fly. Another example, in case of Account, we can deposit or/and withdraw from any account. Again, Each account is totally independent on the other. We may deposit from an account and withdraw from another account. Class What is a class? Well, a class is the place where you can identify the behaviors and properties of an Object. So, the properties and behavior of an Object, will be defined inside a class. Bank Account Class So, a class is a blueprint, it provides the definition for an Object, the definition says what are the properties and the behaviors of the Object. Let’s take an example, When you build a house, you start making the blueprint, in other words you start defining it’s properties and behaviors, and then, you use this blueprint to build different houses, or more formally, different objects from the same blueprint. So, Objects from the same blueprint, or more formally the same class, share the same properties and behaviors. However, even they share the same Class, each Object instantiated from this Class is independent on the other. Abstraction Abstraction means you start focusing on the common properties and behaviors of some Objects, and we automatically will discard what’s unimportant or irrelevant. What came into your mind when I say “Car”? If we say Car, we didn’t explicitly say if the car is BMW or Audi, if it’s red or black, if it’s small or large. Your mental model of a car might have a color and size, but, it’s unlikely to have a smell or a flavor because those things are irrelevant to the idea of a car. Cars So, we abstracted the idea of what a car means. Abstraction is the heart of Object-Oriented Programming, because it’s what we are doing when we make a class. In case of Cars, maybe you will have different brands like, BMW, Audi, Bugatti, Chevrolet, Citroen and so on. But, we don’t create a class for each brand, instead, we will abstract; focus on the common essential qualities of the idea, and we will write one class called Car. And As a way to discard what’s unimportant, we should focus on how the class should look like for this application under these circumstances at this time. In Other words, you care only about the information that you need in this situation. Later on, maybe you will be having a specific car brand that has a property or a behavior that’s not common between other car brands, and it’s specific to it’s type. In this case, you will have to do of what’s called “Inheritance”, and we will get into it later. Encapsulation Instead of having a procedural, long program, we start to decompose our program into small reusable, manageable chunks. Encapsulation implies the idea of breaking down our program into small miniprograms; classes, where each class has a set of related attributes and behaviors. Encapsulation also implies the idea of hiding the content of a Class, unless it’s necessary to expose. We need to restrict the access to our class as much as we can, so that we can change the properties and the behaviors only from inside the class. Encapsulation But, How can we do that? Start building our blueprints, or classes and define their properties and behaviors. Then, restrict access to the inner works of that class by hiding the attributes and methods so that they’re only accessible from inside the class scope. What’s the difference between Encapsulation and Abstraction? Encapsulation is a strategy used as part of abstraction. When we encapsulate, we abstract away the implementation. Abstraction is a more generic term, and it’s often not possible without hiding the object’s class content by encapsulation; if a class exposes its internal content, thus, it cannot be abstracted. Why should we hide attributes and methods of an object? So other parts of the application won’t change the current object attributes. If we have a bank account object, we can use the deposit and withdraw methods from other parts of the application, and they can change the balance, but the attribute can’t be directly changed from outside the class. Another example, If you have a lamp object, and assigned it’s property called “turnedOff” to true. If there are some other class that have access to this property, they can change it accidentally to false!. And, If we’ve restricted direct access to a piece of data, we only have to worry about this one class, and we don’t have to worry about breaking the other parts of the application that might depends on this piece of data. So, we can more safely change the way the object works. If you have a bank account object, and you want to change how the balance is stored. Then, the other parts of the application don’t have to worry about this change, Why? Because the balance attribute of the account object is already hidden; can’t be accessed directly. Inheritance Abstraction is, instead of creating different classes, we can instead create one generic class that has the common, and essential properties and behavior of those classes, while Inheritance is inheriting these common properties and behaviors, so that we can create a new class, but instead of writing it from scratch, we can base it on an existing class. Inheritance A Person class with a attributes; name and address and phone number. Now, you need to create another one called Customer. It has the same attributes as Person, but it also has additional attributes and methods. So, we are going to inherit from the Person class. And the Customer class will automatically has everything that the Person class has, all its attributes, all its behaviors, without us having to write any code. In addition, If we make a change in the Person class, it will automatically cascade down and affect the inheriting classes. Now, we can add specific properties and behaviors that’s not shared across the inheriting classes in their specific classes. Overriding In Inheritance:- Overriding the Super class methods is not a good case practice when the Super class is a Concrete class. That’s why developers tend to use Interfaces instead. Inheritance defines a relationship So, a Customer IS-A Person, and an Employee IS-A Person, and so on. The term that’s most commonly used for this relationship is, Person class is the Super class, while the customer class is called the Sub class. Or, We can also hear this described as the Parent class and the Child class. Multiple Inheritance In C++, & Python allow you to inherit from more than one Super Class; Multiple Inheritance. But, it can get confusing as it’s much more common to inherit from one Super class. In Java & C#, You only inherit from one Super Class. Types of Inheritance Single Inheritance − A subclass derives from a single super-class. Multiple Inheritance − A subclass derives from more than one super-classes. Multilevel Inheritance − A subclass derives from a super-class which in turn is derived from another class and so on. Hierarchical Inheritance − A class has a number of subclasses each of which may have subsequent subclasses, continuing for a number of levels, so as to form a tree structure. Hybrid Inheritance − A combination of multiple and multilevel inheritance so as to form a lattice structure. Polymorphism Polymorphism; is the state where an object can take the shape of many different forms, and lets us do the right thing at the right time. Polymorphism If you have Animal class, and inheriting classes; Dog, Cat, & Duck. Each of the inheriting classes override the speak method (as each animal has a different voice). Now, we can call the speak method on any animal object, without knowing exactly what class the animal object was instantiated from, and it will do the correct behavior. It’s worth mentioning that the speak method in the Animal class will be triggered unless it’s overridden. Polymorphism is the flexibility, that triggers the correct behavior. Genericity Genericity is one of the most powerful means for obtaining flexibility in programming with statically typed programming languages. Genericity constructs take on very different forms, the choice of which has a considerable impact on expressiveness, modularity, static checkability and efficiency properties of programs. Generics allow the programmer to use the same method for Integer arrays, Double arrays, and even String arrays. Another advantage of using generics is that Individual typecasting isn't required. The programmer defines the initial type and then lets the code do its job. It allows us to implement non-generic algorithms. Generic Programs One of the goals of Object Oriented Programming is genericity. Ideally, generic programs can be written once, compiled once and used for different data types. C++ achieves genericity two ways: 1. Using virtual functions and derived classes to achieve polymorphism. 2. Using templates to mimic polymorphism. Template classes must be re-compiled for each data type. Some do not consider this OOP. Coupling vs Cohesion Coupling and cohesion are two important concepts in the Object Oriented design and hence we will briefly discuss it here. Coupling is the degree to which one class knows about another class. If the knowledge is only through exposed interfaces (data hiding), it is called loosely coupled. If the knowledge is more like accessing data members directly, it is called tightly coupled. We should try to make our code as loosely coupled as possible. Even though you make some change in a class adhering strictly to the class's API, tight coupling can make other classes that use this class not working properly after the change. The term cohesion is used to indicate the degree to which a class has a single, well-focused purpose. The more focused a class is, the higher its cohesiveness, which is a good thing. The key benefit of high cohesion is that such classes are typically much easier to maintain than classes with low cohesion. Another benefit of high cohesion is that classes with a well-focused purpose tend to be more reusable than other classes. In summary, loose coupling and high cohesion are desirable, whereas tight coupling and less cohesion can lead you to problems in the long run. Advantages of object oriented software development Some of the advantages of object oriented software development are: Less maintenance cost mostly because it is modular. Better code reusability due to features such as inheritance and hence faster development. Improved code reliability and flexibility Easy to understand due to real world modelling. Better abstraction at object level. Reduced complexity during the transitions from one development phase to another. What is Object-Oriented Analysis and Design and How to Use it OOAD is a technical method of analyzing and designing an application based on that system’s object models (the logical components of the system that interact with one another). Origins of Object-Oriented Analysis and Design During the software development life cycle, development is typically broken up into stages, which are loose, abstract concepts used to separate the activities taking place within each phase of development. Often, these stages might include requirements, planning, design, coding/development, testing, deployment, maintenance, and so forth. In the case of stringent development methodologies, such as the waterfall method, these stages are sequential and intended to be completely separate from one another. Thus, when creating an application using the waterfall method, it’s unlikely that discoveries made during the testing or deployment phases can impact the decisions already made during the planning or design phases. These limitations, along with the strict step-by-step staging process of waterfall-esque models, led to the rise of iterative models like object-oriented analysis and design. While OOAD practices have been around for a number of decades, the core ideas and techniques were largely cemented in the collective mind of the development community in the 1990s. An assortment of practitioners and authorities in the industry, working together and on solo endeavors, began to publish a number of books, articles, and techniques that all relied heavily on OOAD concepts. Some of these publications and methodologies are still well-known and in use today, including the Unified Modeling Language and the Rational Unified Process. What is Object-Oriented Analysis? To define object-oriented analysis, we must first define what we mean by an object. The definition of an object, according to most dictionaries, is “a tangible, material thing.” Drilling down a bit more to the realm of computer science, an object can be most anything in a programmatic sense, from a variable or data model to a function, class, or method. Moving even deeper into the realm of object-oriented programming, an object is an instance of a thing that typically represents a real world object and has all the same types of characteristics (properties), behaviors (methods), and states (data). When discussing OOAD concepts, an object most closely resembles the object-oriented programming version of an object, in that it is a representation of a real world object with behaviors, characteristics, and states. With that out of the way, we can define object-oriented analysis (OOA). In short, OOA is an iterative stage of analysis, which takes place during the software development life cycle, that aims to model the functional requirements of the software while remaining completely independent of any potential implementation requirements. To accomplish this task via OOAD practices, an objectoriented analysis will focus everything through the lens of objects. This forces OOA to combine all behaviors, characteristics, and states together into one analysis process, rather than splitting them up into separate stages, as many other methodologies would do. To accomplish this goal, a typical OOA phase consists of five stages: Find and define the objects. Organize the objects. Describe how the objects interact with one another. Define the external behavior of the objects. Define the internal behavior of the objects. For example, a typical implementation of OOA is to create an object model for an application. The object model might describe the names, relationships, behaviors, and characteristics of each object in the system. With this information established for each object, the design process that follows is much simpler. What is Object-Oriented Design? The process of object-oriented design is really just an extension of the object-oriented analysis process that preceded it, except with a critical caveat: the consideration and implementation of constraints. For example, with an analyzed object in hand, such as an object model, we must now consider how that object would actually be designed and implemented, which will often require the application of constraints, such as software or hardware platforms, time and budgetary limitations, performance requirements, developer aptitude, and so forth. Put another way, the OOD process takes the theoretical concepts and ideas planned out during the OOA stage, and tries to find a way to design and tangibly implement them, usually via code using whatever language and platforms the development team has settled upon. If OOA is the what, then OOD is the how. Advantages of Object-Oriented Analysis and Design Encourages Encapsulation: Since everything within OOAD revolves around the concept of objects (specifically, the object-oriented variety), one of the biggest advantages of OOAD is that it encourages planning and development of systems that are truly independent of one another. Just like a class written using object-oriented techniques, all the systems and objects produced during an OOAD development life cycle can be mixed and matched as necessary, since they will ideally be built as completely self-contained entities. Easy to Understand: Since OOAD principles are fundamentally based on real world objects, it’s quite easy for everyone on the team to quickly understand what an object name means or how a particular behavior, well, behaves. This makes the overall development life cycle a much smoother process, particularly if your team needs to frequently interact with customers or other non-technical users about the objects and components in the system. In such cases, most people still understand how system components and modelled objects work when they’re based on real world objects and ideas. Disadvantages of Object-Oriented Analysis and Design Ill-Suited to Procedural Applications: Given the object-oriented nature of OOAD, it is quite difficult (although not impossible) to practice OOAD techniques within a procedural programming language, or often to apply the techniques to non-object business logic. Whereas procedural applications are often logically bound by concepts of scope and modularity, object-oriented applications, of course, emphasize objects that simulate the real world, making OOAD methods ill-suited for procedural languages and applications. Too Complex for Simple Applications: While arguably not a disadvantage that is applicable to all projects, it’s certainly the case that OOAD practices are generally not ideal for simpler projects. Many developers have their own personal hard and fast rules to help when deciding whether a project should be procedural or object-oriented, but in most cases, the more basic the needs of the application, the more likely a less-structured, procedural approach is the best fit. As always, we must always use our own best judgment. Phases in Object-Oriented Software Development The major phases of software development using object–oriented methodology are object-oriented analysis, object-oriented design, and object-oriented implementation. Object–Oriented Analysis In this stage, the problem is formulated, user requirements are identified, and then a model is built based upon real–world objects. The analysis produces models on how the desired system should function and how it must be developed. The models do not include any implementation details so that it can be understood and examined by any non–technical application expert. Object–Oriented Design Object-oriented design includes two main stages, namely, system design and object design. System Design In this stage, the complete architecture of the desired system is designed. The system is conceived as a set of interacting subsystems that in turn is composed of a hierarchy of interacting objects, grouped into classes. System design is done according to both the system analysis model and the proposed system architecture. Here, the emphasis is on the objects comprising the system rather than the processes in the system. Object Design In this phase, a design model is developed based on both the models developed in the system analysis phase and the architecture designed in the system design phase. All the classes required are identified. The designer decides whether − new classes are to be created from scratch, any existing classes can be used in their original form, or new classes should be inherited from the existing classes. The associations between the identified classes are established and the hierarchies of classes are identified. Besides, the developer designs the internal details of the classes and their associations, i.e., the data structure for each attribute and the algorithms for the operations. Object–Oriented Implementation and Testing In this stage, the design model developed in the object design is translated into code in an appropriate programming language or software tool. The databases are created and the specific hardware requirements are ascertained. Once the code is in shape, it is tested using specialized techniques to identify and remove the errors in the code. Why do we model? Before constructing anything, a designer first build a model. The main reasons for constructing models include: • To test a physical entity before actually building it. • To set the stage for communication between customers and developers. • For visualization i.e. for finding alternative representations. • For reduction of complexity in order to understand it.