[nycfoxsig] Visual Foxpro Users Group - meets 12/4
- From: "Peter Rooney" <magnetix@xxxxxxxxxxx>
- To: <nycfoxsig@xxxxxxxxxxxxx>, <nycfoxsig@xxxxxxxxxxxxxxx>
- Date: Wed, 3 Dec 2008 11:25:44 -0500
(This update is for those of you not on the googlegroups newsgroup)
VFPUG NYC is meeting this Thursday, Dec. 4, at NYU's Silver Bldg (NE corner
of Washington Sq.), in room 714. The meeting convenes at 7:15 - a little
later than usually. Ask the guards for directions. Bring picture ID.
Lew Schwartz is speaking about Object Oriented Design (OOD), which is part
of OO methodology.
LEW HAS SOME EXCITING TECHNIQUE TO SHARE WITH US!
SEE HIS WRITEUP...
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.
Other related posts:
- » [nycfoxsig] Visual Foxpro Users Group - meets 12/4 - Peter Rooney
