2 Criteria of Object Orientation and Key Construction Decisions

You might also like

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 20

Criteria of Object Orientation

and
Key Construction Decisions
Author and prepared by
Bertrand Meyer

Presented by
Engr. FAROOQ IQBAL
Welcome!!

Lecture 02
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.
ON THE CRITERIA

• The list includes all the facilities which researchers believe to be e


ssential for the production of quality software using the object-orie
nted method. It is ambitious and may appear uncompromising or
even rigid.
• What conclusion does this imply for an environment which satisfie
s some but not all of these conditions?
• Should one just reject such a half-hearted O-O environment as tot
ally insufficient?
• 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 c
onstraints limit your choice to A and B you will have to pick A as the lea
st 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 f
or a software solution, so you may have to balance the criteria given he
re with other considerations.
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.
Key Construction Decisions

• Choice of Programming Language


• Programming Conventions
• Localization Aspects of Technology
• Selection of Construction Practices
Choice of Programming Language

• The programming language in which the system will be implemented sho


uld be of great interest to you since you will be occupied in it from the beg
inning of construction to the end.
• Studies have shown that the programming-language choice affects produ
ctivity and code quality in several ways.
• Programmers working with high-level languages achieve better productivi
ty and quality than those working with lower-level languages.
• Languages such as C++, Java, Smalltalk, and Visual Basic have been cr
edited with improving productivity, reliability, simplicity, and comprehensib
ility by factors of 5 to 15 over low-level languages such as assembly and
C (Brooks 1987, Jones 1998, Boehm 2000).
• The Best and Worst Languages for Particular Kinds of Progr
ams
de Complete 4. Key Construction Decisions Page 7

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 Basic Assembler, Perl
program

Assembler, C, C++,
Fast execution JavaScript, Perl, Python
Visual Basic
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
• Some languages simply don’t support certain kinds of programs,
and those have not been listed as “worst” languages. For exampl
e, Perl is not listed as a “worst language” for mathematical calcula
tions.
Programming Conventions

• In high-quality software, you can see a relationship between the c


onceptual integrity of the architecture and its low-level implement
ation.
• The implementation must be consistent with the architecture that
guides it and consistent internally.
• That’s the point of construction guidelines for variable names, cla
ss names, routine names, formatting conventions, and commentin
g conventions.
Your Location on the Technology Wave

• In a complex program, architectural guidelines give the program struc


tural 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 prog
ramming-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 c
oordinated classes and messy variations in style.
Selection of Major Construction Practices

• Part of preparing for construction is deciding which of the many a


vailable 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 circumstanc
es of the project.
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 se
curity will be addressed, and so on?
• Have you identified your location on the technology wave and adj
usted your approach to match?
• If necessary, have you identified how you will program into the lan
guage rather than being limited by programming in it?
Teamwork

• Have you defined an integration procedure, that is, have you defin
ed the specific steps a programmer must go through before check
ing code into the master sources?
• Will programmers program in pairs, or individually, or some combi
nation of the two?
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 i
n?
• Will programmers review or inspect each others’ code?
Review Questions

• 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—edit
or, refactoring tool, debugger, test framework, syntax checker, an
d so on?
Thank you

You might also like