What is the difference between Object-oriented (OOA and OOD and OOP)
Introduction :
Everyone knows what an object is: a tangible thing that we can sense, feel, and manipulate. The earliest objects we interact with are typically baby toys. Wooden blocks, plastic shapes, and oversized puzzle pieces are common first objects. Babies learn quickly that certain objects do certain things: bells ring, buttons are pressed, and levers are pulled.
The definition of an object in software development is not terribly different. Software objects may not be tangible things that you can pick up, sense, or feel, but they are models of something that can do certain things and have certain things done to them. Formally, an object is a collection of data and associated behaviors.
Considering what an object is, what does it mean to be object-oriented? In the dictionary, oriented means directed toward. Object-oriented programming means writing code directed toward modeling objects. This is one of many techniques used for describing the actions of complex systems. It is defined by describing a collection of interacting objects via their data and behavior.
If you’ve read any hype, you’ve probably come across the terms object-oriented analysis, object-oriented design, object-oriented analysis and design, and object-oriented programming. These are all related concepts under the general object-oriented umbrella.
In fact, analysis, design, and programming are all stages of software development. Calling them object-oriented simply specifies what kind of software development is being pursued.
Object-oriented analysis (OOA):
Is the process of looking at a problem, system, or task (that somebody wants to turn into a working software application) and identifying the objects and interactions between those objects. The analysis stage is all about what needs to be done.
Object-oriented design (OOD)
Is the process of converting such requirements into an implementation specification. The designer must name the objects, define the behaviors, and formally specify which objects can activate specific behaviors on other objects. The design stage is all about transforming what should be done into how it should be done.
The output of the design stage is an implementation specification. If we were to complete the design stage in a single step, we would have turned the requirements defined during object-oriented analysis into a set of classes and interfaces that could be implemented in (ideally) any object-oriented programming language.
Object-oriented programming (OOP)
Is the process of converting a design into a working program that does what the product owner originally requested.
Data describes the object's state:
Let’s start with data. Data represent the individual characteristics of a certain object; its current state. A class can define specific sets of characteristics that are part of all objects that are members of that class. Any specific object can have different data values for the given characteristics. For example, the three oranges on our table (if we haven’t eaten any) could each weigh a different amount. The orange class could have a weight attribute to represent that datum. All instances of the orange class have a weight attribute, but each orange has a different value for this attribute. Attributes don’t have to be unique, though; any two oranges may weigh the same amount.
Attributes are frequently referred to as members or properties. Some authors suggest that the terms have different meanings, usually that attributes are settable, while properties are read-only. A Python property can be defined as read-only, but the value will be based on attribute values that are — ultimately — writable, making the concept of read-only rather pointless; throughout this book, we’ll see the two terms used interchangeably. In addition, as we’ll discuss in Chapter 5, When to Use Object-Oriented Programming, the property keyword has a special meaning in Python for a particular kind of attribute.
What is the Composition?
Is the act of collecting several objects together to create a new one.
Composition is usually a good choice when one object is part of another object. We’ve already seen the first hint of composition when talking about cars. A fossil-fueled car is composed of an engine, transmission, starter, headlights, and windshield, among numerous other parts. The engine, in turn, is composed of pistons, a crankshaft, and valves. In this example, the composition is a good way to provide levels of abstraction. The Car object can provide the interface required by a driver, while also giving access to its component parts, which offers a deeper level of abstraction suitable for a mechanic. Those component parts can, of course, be further decomposed into details if the mechanic needs more information to diagnose a problem or tune the engine.
This diagram shows that exactly two players can interact with one chess set. This also indicates that any one player can be playing with only one Chess Set at a time.
Let’s describe our current Chess Set composition and add some attributes to the objects to hold the composite relationships:
