[nycfoxsig] Notes from Lew for Thurs
- From: Lew <lew1716@xxxxxxxxxxxxx>
- To: 'Chaim Caron' <ccaron@xxxxxxxxxxxxx>, 'Jay Berardinelli' <docman@xxxxxxxxxxxxx>, 'Peter Rooney' <magnetix@xxxxxxxxxxx>
- Date: Mon, 01 Dec 2008 22:48:43 -0500
Please read through the following so we have a common basis for Thurs night,
rather than hearing it for the
first time when I present it. I'd like to brainstorm the basic design of a
theoretical invoicing application
in light of these ideas.
Adapted from Wikipedia:
Intro:
Object-oriented design is part of OO methodology and it forces programmers to
think in terms of objects,
rather than procedures, when they plan their code. An object contains
encapsulated data and procedures grouped
together to represent an entity. The 'object interface', how the object can be
interacted, is also defined. An
object-oriented program is described by the interaction of these objects.
Object-oriented design is the
discipline of defining the objects and their interactions to solve a problem
that was identified and
documented during object-oriented analysis.
From a business perspective, Object Oriented Design refers to the objects that
make up that business. For
example, in a certain company, a business object can consist of people, data
files and database tables,
artifacts, equipment, vehicles, etc.
Sources for object-oriented design: <---- Very important!!!!
The input for object-oriented design is provided by object-oriented analysis.
Analysis and design may occur in
parallel, and in practice the results one activity can feed the other in a
short feedback cycle through an
iterative process. Both analysis and design can be performed little by little,
and the artifacts can be
continuously grown instead of completely developed in one shot.
Some typical sources for object-oriented design are:
Conceptual model:
Conceptual model is the result of object-oriented analysis, it captures
concepts in the problem domain. The
conceptual model is explicitly chosen to be independent of implementation
details, such as concurrency or data
storage.
Use case:
Use case is description of sequences of events that, taken together, lead to a
system doing something useful.
Each use case provides one or more scenarios that convey how the system should
interact with the users called
actors to achieve a specific business goal or function. Use case actors may be
end users or other systems. In
many circumstances use cases are further elaborated into use case diagrams. Use
case diagrams are use to
identify the actor (users or other systems) and the processes they perform.
User interface documentations
(if applicable): Document that shows and describes the look and feel of the end
product's user interface. It
is not mandatory to have this, but it helps to visualize the end-product and
therefore helps the designer.
Relational data model (if applicable): A data model is an abstract model that
describes how data is
represented and used. If an object database is not used, the relational data
model should usually be created
before the design, since the strategy chosen for object-relational mapping is
an output of the OO design
process. However, it is possible to develop the relational data model and the
object-oriented design artifacts
in parallel, and the growth of an artifact can stimulate the refinement of
other artifacts.
Object-oriented concepts supported by an OO language
The five basic concepts of object-oriented design are the implementation level
features that are built into
the programming language. These features are often referred to by these common
names:
1. Object/Class:
A tight coupling or association of data structures with the methods or
functions that act on the data. This is
called a class, or object (an object is created based on a class). Each object
serves a separate function. It
is defined by its properties, what it is and what it can do. An object can be
part of a class, which is a set
of objects that are similar.
2. Information hiding:
The ability to protect some components of the object from external entities.
This is realized by language
keywords to enable a variable to be declared as private or protected to the
owning class. <-- Buggy in VFP
3. Inheritance:
The ability for a class to extend or override functionality of another class.
The so-called subclass has a
whole section that is the superclass and then it has its own set of functions
and data.
4. Interface: <-- Weak in VFP
The ability to defer the implementation of a method. The ability to define the
functions or methods signatures
without implementing them.
Polymorphism: The ability to replace an object with its subobjects. The ability
of an object-variable to
contain, not only that object, but also all of its subobjects.
Designing concepts
Defining objects, creating class diagram from conceptual diagram: Usually map
entity to class.
Identifying attributes.
1. Use design patterns
A design pattern is not a finished design, it is a description of a solution to
a common problem. The main
advantage of using a design pattern is that it can be reused in multiple
applications. It can also be thought
of as a template for how to solve a problem that can be used in many different
situations and/or applications.
Object-oriented design patterns typically show relationships and interactions
between classes or objects,
without specifying the final application classes or objects that are involved.
2. Define application framework
Application framework is a term usually used to refer to a set of libraries or
classes that are used to
implement the standard structure of an application for a specific operating
system. By bundling a large amount
of reusable code into a framework, much time is saved for the developer, since
he/she is saved the task of
rewriting large amounts of standard code for each new application that is
developed.
3. Identify persistent objects/data (if applicable): Identify objects that have
to last longer than a single
runtime of the application. If a relational database is used, design the object
relation mapping. <-- In VFP
Objects can exist momentarily (like a function call) or last as long as the app
is running. A single
createobject() may be the only time/duration for which an object is used.
Identify and define remote objects (if applicable).
Some design principles and strategies
Dependency injection: The basic idea is that if an object depends upon having
an instance of some other object
then the needed object is "injected" into the dependent object; for example,
being passed a database
connection as an argument to the constructor instead of creating one
internally. <- We don't see this in VFP
code, but very useful.
Acyclic dependencies principle: <- I don't know what this even means in VFP or
in any other language.
Favor polymorphic composition of objects over inheritance.
References:
The GOF book:
Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley.
1995. ISBN 0-201-63361-2.
To unsubscribe from the NYACC Database SIG list, send an email to
nycfoxsig-request@xxxxxxxxxxxxx with 'unsubscribe' (no quotes) in the subject
field.
Other related posts:
- » [nycfoxsig] Notes from Lew for Thurs - Lew
