Criteria of Object Orientation

and
Key Construction Decisions

Presented by
Engr. Farooq Iqbal

Object-Oriented Software Construction, by Bertrand Meyer,

Second Edition, Published by, Prentice Hall in 1997
Lecture 02

Presented by
Engr. Farooq Iqbal
 Learning Outcomes
 One of the benefits will be to obtain a brief token of
what makes a system object-oriented.

 This expression has nowadays become so generally

used that we need a list of precise properties under
which we can assess any method, language or tool
that claim to be O-O.

3
 On The Criteria
 The list includes all the facilities which researchers believe to
be essential for the production of quality software using the
object-oriented method.

 It is ambitious and may appear uncompromising or even

rigid.

 What conclusion does this imply for an environment which

satisfies some but not all of these conditions?

 Should one just reject such a half-hearted O-O environment

as totally insufficient?

4
 On The Criteria

Several reasons suggest that some compromises may be

necessary:
“Object-oriented” is not a Boolean condition:
 environment A, although not 100% O-O, may be “more” O-O than
environment B; so if external constraints limit your choice to A and B
you will have to pick A as the least bad object-oriented choice.

 Not everyone will need all of the properties all the time.

 Object orientation may be just one of the factors guiding

your search for a software solution, so you may have to
balance the criteria given here with other considerations.

5
 Categories

The set of criteria which follows has been divided into three
parts:
 Method and language: these two almost indistinguishable aspects cover
the believed processes and the notations used to analyze and produce
software. Be sure to note that (especially in object technology) the term
“language” covers not just the programming language in a strict sense,
but also the notations, textual or graphical, used for analysis and design.
 Implementation and environment: the criteria in this category describe
the basic properties of the tools which allow developers to apply object-
oriented ideas.
 Libraries: object technology relies on the reuse of software components.
Criteria in this category cover both the availability of basic libraries and
the mechanisms needed to use libraries and produce new ones.

6
 Key Construction Decisions

 Choice of Programming Language

 Programming Conventions
 Localization Aspects of Technology
 Selection of Construction Practices

7
 Choice of Programming Language

 The programming language in which the system will be implemented

should be of great interest to you since you will be occupied in it from
the beginning of construction to the end.

 Studies have shown that the programming-language choice affects

productivity and code quality in several ways.

 Programmers working with high-level languages achieve better

productivity and quality than those working with lower-level
languages.

 Languages such as C++, Java, Smalltalk, and Visual Basic have been
credited with improving productivity, reliability, simplicity, and
comprehensibility by factors of 5 to 15 over low-level languages such
as assembly and C (Brooks 1987, Jones 1998, Boehm 2000).
8
 Choice of Programming Language
Kind of Program Best Languages Worst Languages

Command-line processing Cobol, Fortran, SQL -

Cross-platform
Java, Perl, Python Assembler, C#, Visual Basic
development
Database manipulation SQL, Visual Basic Assembler, C
Direct memory
Assembler, C, C++ C#, Java, Visual Basic
manipulation
Distributed system C#, Java -

Dynamic memory use C, C++, Java -

Easy-to-maintain C++, Java, Visual

Assembler, Perl
program Basic

Assembler, C, C++,
Fast execution JavaScript, Perl, Python
Visual Basic

9
 Choice of Programming Language

Kind of Program Best Languages Worst Languages

For environments with
Assembler, C C#, Java, Visual Basic
limited memory
Mathematical
Fortran Assembler
calculation
Perl, PHP, Python,
Quick-and-dirty project Assembler
Visual Basic
C#, Java, Perl, Visual
Real-time program C, C++, Assembler
Basic
Cobol, Perl, Visual
Report writing Assembler, Java
Basic
Secure program C#, Java C, C++
String manipulation Perl, Python C
C#, Java, JavaScript,
Web development Assembler, C
PHP, Visual Basic
 Choice of Programming Language

 Some languages simply don’t support

certain kinds of programs, and those have
not been listed as “worst” languages.

 For example, Perl is not listed as a “worst

language” for mathematical calculations.

11
 Programming Conventions

 In high-quality software, you can see a relationship

between the conceptual integrity of the architecture and
its low-level implementation.

 The implementation must be consistent with the

architecture that guides it and consistent internally.

 That’s the point of construction guidelines for variable

names, class names, routine names, formatting
conventions, and commenting conventions.

12
Your Location on the Technology Wave

 In a complex program, architectural guidelines give the

program structural balance and construction guidelines
provide low-level harmony, articulating each class as a
faithful part of a comprehensive design.
 Any large program requires a controlling structure that
unifies its programming-language details.
 Part of the beauty of a large structure is the way in which
its detailed parts bear out the implications of its
architecture.
 Without a unifying discipline, your creation will be a
jumble of poorly coordinated classes and messy variations
in style.

13
Selection of Major Construction Practices

 Part of preparing for construction is deciding which of the

many available good practices you’ll emphasize.

 Some projects use pair programming and test-first

development, while others use solo development and
formal inspections.

 Either technique can work well depending on specific

circumstances of the project.

14
 Coding

 Have you defined coding conventions for names,

comments, and formatting?
 Have you defined specific coding practices that are
implied by the architecture, such as how error conditions
will be handled, how security will be addressed, and so
on?
 Have you identified your location on the technology wave
and adjusted your approach to match?
 If necessary, have you identified how you will program
into the language rather than being limited by
programming in it?

15
 Team Work

 Have you defined an integration procedure,

that is, have you defined the specific steps
a programmer must go through before
checking code into the master sources?

 Will programmers program in pairs, or

individually, or some combination of the
two?

16
 Quality Assurance

 Will programmers write test cases for their code before

writing the code itself?

 Will programmers write unit tests for the their code

regardless of whether they write them first or last?

 Will programmers step through their code in the debugger

before they check it in?

 Will programmers integration-test their code before they

check it in?

 Will programmers review or inspect each others’ code?

17
 Review

 What is advantages of Object Oriented construction?

 Have you selected a modification control tool?

 Have you selected a language and language version or

compiler version?

 Have you identified and acquired other tools you’ll be

using—editor, refactoring tool, debugger, test framework,
syntax checker, and so on?

18
End of Lecture
Thank you