1. LESSON 1 Introduction To Software Development CSC 300 Fall 2019
Howard Rosenthal

2. Course References
Materials for this course have utilized materials in the following documents. Additional materials taken from web sites will be referenced when utilized.
Anderson, Julie and Franceschi, Herve, Java Illuminated 5TH Edition,, Jones and Bartlett, 2019
Bravaco, Ralph and Simonson, Shai, Java Programming From The Ground Up, McGraw Hill, 2010
Deitel, Paul and Deitel, Harvey, Java, How To Program, Early Objects, Eleventh Edition, Pearson Publishing, 2018
Gaddis, Tony, Starting Out With Objects From Control Structures Through Objects, Seventh Edition, Pearson Publishing, 2019
Horstmann, Cay, Core Java For The Impatient, Addison Wesley- Pearson Education, 2015
Naftalin, Maurice and Wadler, Philip, Java Generics and Collections, O’Reilly Media, 2007
Schmuller, Joseph, Teach Yourself UML In 24 Hours Second Edition, SAMS Publishing, 2002
Urma, Raoul-Gabriel, Fusco, Mario and Mycroft, Alan, Java 8 in Action: Lambdas, Streams, and Functional-Style Programming, Manning Publishing, 2014
Wirfs-Brock, Rebecca, Wilkerson, Brian and Wiener, Laura, Designing Object-Oriented Software, Prentice Hall, 1990
Oracle On-Line Documentation and Tutorials,

3. Lesson Goals Discuss the purpose and goals of this course
Discuss key software development practices
Good coding and testing practices
Describe software complexity and two ways of calculating it
Briefly describe software methodologies
Waterfall
Spiral
Agile
Introduce object-oriented programming

4. Purpose And Goals Of This Course
The purpose of this class is to improve your programming skills
As Computer Science majors the professors in your upper division classes will expect you to be able to produce programs that solve the problems in many of their classes
Assigning a program in these classes will be the same as a reading assignment
The professors won’t be teaching you how to read, neither do they expect to teach you how to program
In addition, many interviews for internships and full-time jobs include testing your programming skills and problem solving approaches
Therefore we want to teach you ways to improve your efficiency, your ability to design and then code and test the solutions to complex problems.
We will make sure that you understand the underlying principle of Object Oriented Programming
We will show you how to read the very extensive Oracle Documentation

5. Good And Popular Software Design Practices

6. Some Key Practices In Software Development That Are Widely Agreed Upon (1)
Good design and definition of interfaces
Interfaces allow us to encapsulate and then hide implementation details
Well-defined interfaces between software objects is important to ensure that the code is usable
Automated testing is something almost universally agreed upon as a laudable goal.
Tools capture test scenarios for playback so that they can be run multiple times.
Continuous integration, as opposed to developing in silo branches and then having extensive merging efforts, is also largely viewed as a benefit.
Helps find any problems or disconnects between developers early in the process
Use of object-oriented design patterns
Software Patterns describe how to solve typical problems that appear in many application scenarios in similar ways. – An abstract class has patterns that may be applied to multiple child classes
These patterns can be seen as abstracted knowledge, that guides you in better solving your concrete problems
For instance, all polygons have their perimeters calculated in a similar way.
A more complex example – all cars start in a similar way.

7. Some Key Practices In Software Development That Are Widely Agreed Upon (2)
Code reviews are widely considered to be indispensable ways of promoting code quality.
Usually done by peers as well as management to ensure that software is correct and meeting requirements
Avoids fudging by programmers
Pair programming takes code reviews to the next level and has development performed in a constant state of review.
Two persons teams continuously review and consult on each other’s code.
One click, automated builds are considered an important goal for most organizations
Eliminates the practice of having someone labor for half a day to get the software into a deployable state.
Low complexity makes the code much easier to test and maintain
High complexity in code geometrically increases the number of tests
Good documentation is essential unless you want to own the same piece of code for its entire lifetime
Need to be able to turn over code to a new developer or maintainer

8. Good Software Development
Writing good software is much more than sitting down and starting to code
You need a methodology
You need a structure
You need to thoroughly test
Every loop and branch must be thoroughly tested
You need to strive towards simplicity
This makes testing easier
You need to refactor on a regular basis
Refactoring is improving the software without adding new functionality
Improvements can include performance improvement, bug fixes, etc.)
You need well-documented software (see reference SoftwareDocumentation.pdf)
You must document all logic, parameters, and test results
You would like to develop reusable software whenever possible
This requires data-driven software that can serve multiple similar purposes

9. Good Basic Software Engineering Practices
Build the framework of classes first using UML class diagrams.
Keep code simple
This means that you don’t want to nest too deeply.
Compile each class as you write it.
Write data driven software
If all the data is hardcoded the software isn’t very useful.
Test thoroughly, first by unit, and then for the program as a whole.
Start building test matrices.
Document, especially the external interfaces
Review and refactor the software to improve the code.
Understanding basic object-oriented principles including inheritance, polymorphism and interfaces.
Learning how to read and use language documentation (in particular applied to Oracle documentation).

10. Refactoring – A Deeper Dive
Refactoring simply means "improving the design of existing code without changing its observable behavior".
Originally conceived in the Smalltalk community, it has now become a mainstream development technique.
While refactoring tools make it possible to apply refactorings very easily, its important that the developer understand what the refactoring does and why it will help
Each refactoring is a simple process which makes one logical change to the structure of the code.
When changing a lot of the code at one time it is possible that bugs were introduced.
But when and where these bug were created is no longer reproducible.
If, however, a change is implemented in small steps with tests running after each step, the bug likely surfaces in the test run immediately after introducing it into the system.
Then the step could be examined or, after undoing the step, it could be split in even smaller steps which can be applied afterwards.
This is the benefit of comprehensive unit tests in a system, something advocated by Extreme Programming techniques.
These tests, give the developers and management confidence that the refactoring has not broken the system, the code behaves the same way as it behaved before.
Refactoring is usually done within an agile or prototyping environment.

11. Questions to ask, actions to take
Phases In Refactoring
Action
Questions to ask, actions to take
Detect a problem
Is there a problem? What is the problem?
Characterize the problem
Why is it necessary to change something? What are the benefits? Are there any risks?
Design a solution
What should be the "goal state" of the code? Which code transformation(s) will move the code towards the desired state?
Modify the code
Steps that will carry out the code transformation(s) that leave the code functioning the same way as it did before.

12. Examples Of Refactoring (1)
Rename
A method, variable, class or other java item has a name that is misleading or confusing.
This requires all references, and potentially file locations to be updated.
The process of renaming a method may include renaming the method in subclasses as well as clients.
On the other hand, renaming a package will also involve moving files and directories, and updating the source control system.
Move Class
A Class is in the wrong package, it should therefore be moved to another package where it fits better.
All import statements or fully qualified names referring to the given class need to be updated. The file will also have to be moved and updated in the source control system.
Extract Method
A long method needs to be broken up to enhance readability and maintainability and reduce complexity.
A section of code with a single logical task (e.g. find a record by id) is replaced with an invocation to a new method.
This new method is given suitable parameters, return type and exceptions.
By giving the method a clear and descriptive name (findRecordById), the original method becomes simpler to understand as it will read like pseudocode.
Extracting the method also allows the method to be reused in other places, not possible when it was tangled amongst the larger method.

13. Examples Of Refactoring (2)
Extract Superclass
An existing class provides functionality that needs to be modified in some way.
An abstract class is introduced as the parent of the current class, and then common behaviour is "pulled up" into this new parent.
Clients of the existing class are changed to reference the new parent class, allowing alternative implementations (polymorphism).
Any methods which are common to the concrete classes are "pulled up" with definitions, while those that will vary in subclasses are left abstract.
As well as aiding in efficient code re-use, it also allows new subclasses to be created and used without changing the client classes.
Replace Conditional with Polymorphism
Methods in a class currently check some value (if or switch statement) in order to decide the right action to perform. One trivial example is a class that draws a shape, which is defined by a width and type (circle or square).
The code quickly becomes confusing as the same if or switch statements are repeated throughout the class, i.e. in methods that calculate the area or perimeter of the shape.
By using polymorphism, the shape specific behaviour can be offloaded to subclasses, simplifying the code.
This has the added benefit of allowing other subclasses, e.g. rectangle or star, to be introduced without extensive code changes.

14. Good Practices For Software Coding and Testing

15. Good Coding Practices For Java Programmers (1)
1. Using Naming Conventions
Before writing any code you should specify a set of naming conventions for your Java (or other) project, such as how to name classes and interfaces, how to name methods, how to name variables, how to name constants, etc. These conventions must be obeyed by all programmers in your team.
According to Robert Martin (the author of Clean Code), an identifier (a class, a method, and a variable) should have the following characteristics:
Self-explanatory: a name must reveal its intention so everyone can understand and change the code easily. For example the names daysToExpire or inputText do reveal their intention clearly.
If a name requires a comment to describe itself, then the name is not self-explanatory.
Meaningful distinctions
If names must be different, then they should also mean something different. For example, the names a1 and a2 have a meaningless distinction; while the names source and destination may be meaningful distinction.
Pronounceable - Names should be pronounceable as naturally as spoken language because we are humans - very good at words.

16. Good Coding Practices For Java Programmers (2)
Here are some general naming rules:
Class and interface names should be nouns, starting with an uppercase letter.
For example: Student, Car, Rectangle, Painter, etc.
Variable names should be nouns, starting with a lowercase letter.
For example: number, counter, birthday, gender, etc.
Method names should be verbs, starting with a lowercase letter.
For example: run, start, stop, execute, etc.
Constant names should have all UPPERCASE letters and words are separated by underscores. For example: MAX_SIZE, MIN_WIDTH, MIN_HEIGHT, etc.
Using camelCase notation for names.
For example: studentManager, carController, numberOfStudents, runAnalysis,
A good reference for naming conventions is an Oracle’s publication: Java Code Conventions. Build your own naming conventions using this document.
Remember, naming is very important in programming as we name everything from classes to interfaces to methods to variables to constants, etc.
So do not write code just to satisfy the compiler, write code so that it is readable and can be understood by humans - for yourself, for your teammates, and for other guys who end up maintaining your project.

17. Good Coding Practices For Java Programmers (3)
2. Ordering Class Members by Scopes
The best practice to organize member variables of a class by their scopes from most restrictive to least restrictive.
That means we should sort the members by the visibility of the access modifiers: private, default (package), protected, and public. And each group separated by a blank line.
For example, the following members declaration looks quite messy:
public class StudentManager {
protected List<Student> listStudents;
public int numberOfStudents;
private String errorMessage;
float rowHeight;
float columnWidth;
protected String[] columnNames;
private int numberOfRows;
private int numberOfColumns;
public String title; }
This is better:

18. Good Coding Practices For Java Programmers (4)
3. Class Members should be private
We should minimize the accessibility of class members (fields)
That means we should use the lowest possible access modifier (hence the private modifier) to protect the fields. This practice is recommended in order to enforce information hiding or encapsulation in software design.
Use mutator methods to change these variables.
The added benefit is that you check for the validity of a value only once
4. Avoid Empty Catch Blocks
It’s a very bad habit to leave catch blocks empty, as when the exception is caught by the empty catch block, the program fails in silence, which makes debugging harder.
5. Using StringBuilder or StringBuffer instead of String concatenation
Remember that String is immutable, so each time we do a concatenation we create a whole new object
This is not the case with StringBuilder objects

19. Good Coding Practices For Java Programmers (5)
6. Use enum or Constant Class instead of Constant Interface
It’s a very bad idea to create an interface which is solely for declaring some constants without any methods. Here’s such an interface:
public interface Color {
public static final int RED = 0xff0000;
public static final int BLACK = 0x000000;
public static final int WHITE = 0xffffff; }
This is because the purpose of interfaces is for inheritance and polymorphism, not for static variables. So the best practice recommends us to use an enum instead. For example:
public enum Color
BLACK, WHITE, RED
7. Avoid Redundant Initialization (0-false-null)
It’s very unnecessary to initialize member variables to the following values: 0 (for primitive numerics), false (for Boolean), null character (for char) and null (for objects).
Just as is the case with arrays these values are the default initialization values of member variables in Java.

20. Good Coding Practices For Java Programmers (6)
8. Use Interface References to Collections
When declaring collection objects, references to the objects should be as generic as possible.
This is to maximize the flexibility and protect the code from possible changes in the underlying collection implementations class.
That means we should declare collection objects using their interfaces List, Set, Map, Queue and Deque.
We will demonstrate this when we discuss Generics and then the Collection Framework
9. Avoid using for loops with indexes
Don’t use a for loop with an index (or counter) variable if you can replace it with the enhanced for loop, an iterator, or forEach (since Java 8).
It’s because the index variable is error-prone, as we may alter it incidentally in the loop’s body, or we may starts the index from 1 instead of 0.

21. Good Practices For Unit Testing (1)
Test only one code unit at a time
When we try to test a unit of code, this unit can have multiple use cases. We should always test each use case in a separate test case.
For example, if we are writing the test case for a function which is supposed to take two parameters and should return a value after doing some processing, then different use cases might be:
First parameter can be null. It should throw Invalid parameter exception.
Second parameter can be null. It should throw Invalid parameter exception.
Both can be null. It should throw Invalid parameter exception.
Finally, test the valid output of function. It should return valid pre-determined output.
This helps when you do some code changes or do refactoring then to test that functionality has not broken, running the test cases should be enough. Also, if you change any behavior then you need to change single or least number of test cases.
Don’t make unnecessary assertions
Remember, unit tests are a design specification of how a certain behavior should work, not a list of observations of everything the code happens to do.
Do not try to Assert everything, but just focus on what you are testing. Otherwise you will end up having multiple test cases failures for a single reason, which does not help in achieving anything.
Make each test independent of all the others
Do not make a chain of unit test cases. It will prevent you to identify the root cause of test case failures and you will have to debug the code. Also, it creates dependency, means if you have to change one test case then you need to make changes in multiple test cases unnecessarily.

22. Good Practices For Unit Testing (2)
Emulate all external services and state
Otherwise, behavior in those external services overlaps multiple tests, and state data means that different unit tests can influence each other’s outcome.
You’ve definitely taken a wrong turn if you have to run your tests in a specific order, or if they only work when your database or network connection is active.
This is important because you would not love to debug the test cases which are actually failing due to bugs in some external system.
Note: You will have a chance to test for these interfacing problems during integration testing

23. Software Complexity

24. Halstead’s Software Complexity Methodology
In 1977, Mr. Maurice Howard Halstead introduced metrics to measure software complexity.
Halstead’s metrics depends upon the actual implementation of program and its measures, which are computed directly from the operators and operands from source code, in static manner.
It allows to evaluate testing time, vocabulary, size, difficulty, errors, and efforts for C/C++/Java source code.
According to Halstead, “A computer program is an implementation of an algorithm considered to be a collection of tokens which can be classified as either operators or operands”.
Halstead metrics think a program as sequence of operators and their associated operands.
He defines various indicators to check complexity of module.

25. Halstead Metrics and Metric Report
Complexity Indicators
Metrics Report
Length*log2Vocabulary

26. Cyclomatic Software Complexity (1)
Every program encompasses statements to execute in order to perform some task and other decision-making statements that decide, what statements need to be executed.
These decision-making constructs change the flow of the program.
If we compare two programs of same size, the one with more decision-making statements will be more complex as the control of program jumps frequently.
McCabe, in 1976, proposed Cyclomatic Complexity Measure to quantify complexity of a given software.
It is a quantitative measure of the number of linearly independent paths through program's source code
It is graph driven model that is based on decision-making constructs of program such as if-else, do-while, repeat-until, switch-case and goto statements.
In normal terms, the cyclomatic complexity measure tells how complex your code is.
Process to make flow control graph:
Break program in smaller blocks, delimited by decision-making constructs.
Create nodes representing each of these blocks.
Connect nodes as follows:
If control can branch from block i to block j
Draw an arc
Optional: From each exit node to entry node

27. Cyclomatic Software Complexity (2)
Good software design keeps the complexity of any method low, limiting the levels of nesting by creating and invoking new methods.
Note: The government has strong limits on the level of complexity of any individual piece of software.
These standards have filtered into commercial standards
When you have lowered complexity you may have more methods
Therefore good and complete documentation of each method, as well as each class, it extremely important
See SW Complexity SEI Carnegie Mellon.pdf in references

28. Calculating Cyclomatic Software Complexity
Mathematically, the cyclomatic complexity of a structured program is defined with reference to the control flow graph of the program, a directed graph containing the basic blocks of the program, with an edge between two basic blocks if control may pass from the first to the second. The complexity M is then defined as
M = E − N + 2P,
where
E = the number of edges of the graph.
N = the number of nodes of the graph.
P = represents number of nodes that have exit points in the control flow graph. (or often considered as the number of connected components)

29. Example Of Complexity Calculation
A control flow graph of a simple program.
The program begins executing at the red node, then enters a loop (group of three nodes immediately below the red node).
On exiting the loop, there is a conditional statement (group below the loop), and finally the program exits at the blue node.
This graph has 9 edges, 8 nodes, and 1 exit point, so the cyclomatic complexity of the program is
*1 = 3
For a single program (or subroutine or method), P is always equal to 1. So a simpler formula for a single subroutine is
M = E − N + 2
From:

30. Alternate Formula
An alternative formulation is to use a graph in which each exit point is connected back to the entry point.
In this case, the graph is strongly connected, and the cyclomatic complexity of the program is equal to the cyclomatic number of its graph (also known as the first Betti number), which is defined as
M = E − N + P.
This may be seen as calculating the number of linearly independent cycles that exist in the graph, i.e. those cycles that do not contain other cycles within themselves.
Note that because each exit point loops back to the entry point, there is at least one such cycle for each exit point.
M = = 3
From:

31. Another Cyclomatic Complexity Example
In the above example:
e = 10
n=8
Cyclomatic Complexity = =3 (using alternate formulation with the e10 connecting arc) Or
M = *1 (Using basic formula)

32. Software Development Methodologies – A Brief Introduction

33. Classic Traditional Program Management Uses The Waterfall Model

34. The Waterfall In Reality
In reality there are almost always unknowns and changes
This leads to the potential to circle back at any step to a prior step in the life cycle

35. The V-Shaped Model Is A Variation On The Waterfall
Advantages
Disadvantages
Early development of test plans during the corresponding analysis and design processes during the life cycle improves the possibility of acceptance test success.
Software is developed during the implementation phase, so no early prototypes of the software are produced
Each phase has specific deliverables
Little flexibility and adjusting scope is difficult
Simple and easy to use
Very rigid like the waterfall model
Works well for small projects where requirements are easily understood
This model does not provide a clear path for problems found during testing phases

36. The Spiral Model Combines The Traditional and Predictive Lifecycle Model With Prototyping – It Is Iterative

37. The Spiral Model Uses Prototyping As A Key Tool During Requirements Discovery (1)
The requirements for the new system are defined in as much detail as possible.
This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design.
This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
A second prototype is evolved by a fourfold procedure:
Evaluating the first prototype in terms of its strengths, weaknesses, and risks
Defining the requirements of the second prototype
Planning and designing the second prototype
Constructing and testing the second prototype.

38. The Spiral Model Follows A Path That Leads To Requirements Discovery (2)
At the customer's option, the entire project can be aborted if the risk is deemed too great.
Risk factors might involve development cost overruns, operating-cost miscalculation, or any other factor that could, in the customer's judgment, result in a less-than-satisfactory final product.
The existing prototype is evaluated in the same manner as was the previous prototype, and, if necessary, another prototype is developed from it according to the fourfold procedure outlined above.
The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.
The final system is constructed, based on the refined prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

39. The Agile Manifesto
Agile methodologies embrace the concept of incremental development and delivery of workable software
The Agile Manifesto encompasses four basic values
PMBOK V6 Agile Fig. 2-1

40. The Twelve Principles Of The Agile Manifesto
PMBOK V6 Agile Fig. 2-2

41. Many Different Lean Methods Are Considered Agile
Often people mean different methods when talking about Agile
Any method that embraces the the Agile Manifesto and Principle may be considered an Agile method
PMBOK V6 Agile Fig. 2-4

42. What Is A Scrum?
Scrum is a single-team process framework used to manage product development
The framework consists of roles, events, artifacts and rules that uses an “iterative” Agile delivery approach to deliver working products within timeboxes of one month or less
Scrum is the most widely used methodology for Agile development. Key advantages include:
Relatively easy to train and implement
Reflects the truly incremental delivery approach used for in-house improvements
Keeps the customer satisfied and sold
Keeps a team together for a longer time, improving efficiency
Through the retrospectives provides a mechanism for continuous process improvement.
Not appropriate for new large scale projects
Scrum defines "a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”
It challenges assumptions of the "traditional, sequential approach” to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members
A key principle of Scrum is the dual recognition that customers will change their minds about what they want or need (often called requirements volatility)
There will be unpredictable challenges for which a predictive or planned approach is not suited
Scrum adopts an evidence-based empirical approach that the problem cannot be fully understood or defined up front
It instead focuses on how to maximize the team's ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving technologies and changes in market conditions

43. The Scrum Framework

44. The Scrum Process Is Built Around Daily Standups and Rapid Delivery Of New Capabilities

45. Continuous Improvement In The Agile Environment
The Agile mindset should include the quest to learn (even when you fail) and leveraging what you learn to continuously improve on what you do
The Agile mindset is an attitude that equates failure and problems with opportunities for learning and invaluable feedback
It’s a belief that we can all grow stronger over time if you put in effort to increase your knowledge and support the team, and the organizational culture gives you the space to do it

46. The Daily Stand-up (1)
Daily stand-up, as the name suggests, is a daily status meeting among all the members of an Agile team. It not only provides a forum for regular updates but also brings the problems of team members into focus so that it can be quickly addressed
Daily stand-up is a must-do practice, no matter how an Agile team is established regardless of its office location
A daily stand-up is a daily status meeting among all team members and it is held roughly for 15 minutes
Daily stand-up is for status update, not for any discussion. For discussion, team members should schedule another meeting at a different time
Participants usually stand instead of sitting so that the meeting gets over quickly
Every member has to answer three important questions in the daily standup
What I did yesterday?
What I'll do today?
Any impediment I am facing.../ I am blocked due to...

47. The Daily Stand-up (2)
The benefits of having a daily stand-up in Agile are as follows −
The team can evaluate the progress on a daily basis and see if they can deliver as per the cycle/iteration plan
Each team member informs all about his/ her commitments for the day
It provides visibility to the team on any delay or obstacles
Stand-up attendees
The Scrum Master, the Product Owner, and the delivery team should attend the stand-up on a daily basis
Stakeholders and Customers are encouraged to attend the meeting and they can act as an observer, but they are not supposed to participate in stand-ups
It is the Scrum Master's responsibility to take note of each team member's queries and the problems they are facing
Stand-ups for geographically dispersed teams can be done in multiple ways, in case the team members are in different times zones
Select a convenient time for all – this is harder to do on international projects, but the core Agile teams are typically small and collocated
Have a wide variety of communication tools ready like conference call, video conferencing, instant messengers, or any other third-party knowledge sharing tools

48. The Agile Retrospective
An Agile retrospective is a meeting that's held for the team reflects on what happened in the cycle or in the recent past and identifies actions for improvement going forward
It can be thought of as a "lessons learned" meeting
The team reflects on how everything went and then decides what changes they want to make in the next cycle
The retrospective is team-driven, and team members should decide together how the meetings will be run and how decisions will be made about improvements
Retrospectives should never be about blame, but how to avoid the same pitfalls in the future
During a retrospective the team members answer the following questions:
What worked well for us?
What did not work well for us?
What actions can we take to improve our process going forward?
Because Agile stresses the importance of continuous improvement, having a regular Agile retrospective is one of the most important of Agile development practices
The Ninth Agile principle outlined in the Agile manifesto states, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly." A framework, such as the one below, can be used to provide structure and keep discussion during the retrospective focused.
An Agile retrospective may be held at the end of an cycle/increment/iteration or other times including:
Any release or shipping by the team
If more than a few weeks have passed since the prior
If the team is stuck and having problems
Any other milestone

49. Object-Oriented Programming

50. What Is Object-Oriented Programming
The purpose of OOP is to organize a program's structure so that one can build programs using abstract models called "objects" that encapsulate data and behavior into one unit
Object-oriented programming is based upon theories from the field of cognitive science about how information is represented in the human mind.
Cognitive science is a multidisciplinary field where psychiatrists, neurologists, computer scientists, and others try to understand the nature of human thought.
Computer scientists are particularly interested in this field because understanding human thought is helpful in the field of artificial intelligence as well as human-computer interaction.
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects", which may contain data, in the form of fields, often known as attributes; and code, in the form of procedures, often known as methods.
A feature of objects is that an object's procedures can access and often modify the data fields of the object with which they are associated (objects have a notion of "this" or "self").
In OOP, computer programs are designed by making them out of objects that interact with one another.

51. Classes And Objects Classes Objects
The definitions for the data format and available procedures for a given type or class of object; may also contain data and procedures (known as class methods) themselves, i.e. classes contain the data members and member functions
Objects
Instances of classes
Objects sometimes correspond to things found in the real world.
For example, a graphics program may have objects such as "circle", "square", "menu".
An online shopping system might have objects such as "shopping cart", "customer", and "product”
Sometimes objects represent more abstract entities, like an object that represents an open file, or an object that provides the service of translating measurements from U.S. customary to metric.
The use of classes and objects allow us to model all forms of real world documentation

52. Why Use Object-Oriented Programming
Object-0riented programming has great advantages over other programming styles:
Code Reuse and Recycling:
Objects created for object-oriented Programs can easily be reused in other programs.
Encapsulation:
Once an object is created, knowledge of its implementation is not necessary for its use. In older programs, coders needed understand the details of a piece of code before using it (in this or another program).
Objects have the ability to hide certain parts of themselves from programmers. This prevents programmers from tampering with values they shouldn't. Additionally, the object controls how one interacts with it, preventing other kinds of errors.
For example, a programmer (or another program) cannot set the width of a window to -400.
Design Benefits:
Large programs are very difficult to write.
Object-oriented programs force designers to go through an extensive planning phase, which makes for better designs with less flaws.
In addition, once a program reaches a certain size, object-oriented programs are actually easier to program than non-object-oriented ones.
Software Maintenance:
Programs are not disposable and legacy code must be dealt with on a daily basis, either to be improved upon (for a new version of an exist piece of software) or made to work with newer computers and software.
An object-oriented program is much easier to modify and maintain than a non-object-oriented program.
So although a lot of work is spent before the program is written, less work is needed to maintain it over time.