OO Analysis

  • Thread starter Thread starter KV
  • Start date Start date
K

KV

Alright, I've read Jesse Liberty's book almost cover to cover. So now I
know something about using C#. I have an idea for a program I want to
write.

I have NO IDEA what objects I need, or how to set things up. Are there
any good object-oriented books or website tutorials on ANALYSIS that you
would recommend? I need something that will teach me to diagram and
organize my thoughts.

The program I want to write transfers certain files and directories from
one PC to another. It seems I need a source computer object and a
destination computer object. Beyond that, to what level should I
extrapolate objects? Should I have a log object, for instance? Surely,
I wouldn't have an object for each program I want to copy (I was
thinking of doing an enumeration for software). I need to know where to
draw the lines.

-KV
 
Object Technology - A Manager's Guide, Second Edition (or later)
-- David A. Taylor, Ph.D.

C# Class Design Handbook
-- WROX

Both should work very well for you.
 
Introduction to Design Patterns, 2nd Ed, Shalloway and Trott

Excellent reference for someone who is learning objects. You can skip past
most of the yahoos who still write objects as "nouns" with methods as the
"verbs" and go right to identifying commonality and encapsulating
variability.

This book will change how you think about object oriented analysis.

--- Nick
 
KV wrote:
[...snip...]
Are there
any good object-oriented books or website tutorials on ANALYSIS that you
would recommend? I need something that will teach me to diagram and
organize my thoughts.
Click to expand...

Others have recommended a lot of interesting book; personally, I like
"Applying UML and Patterns" from Craig Larman, Prentice Hall 1998 best.
The program I want to write transfers certain files and directories from
one PC to another. It seems I need a source computer object and a
destination computer object. Beyond that, to what level should I
extrapolate objects? Should I have a log object, for instance? Surely,
I wouldn't have an object for each program I want to copy
Click to expand...

Why not ? This would involve creating one (!) class like "ProgramToCopy",
which would know about source base UNC, target base UNC and involved files
(filesToCopy). Each File would be represented by an "FileToCopy" object (the
second class), which in turn knows the file name, the source directory
(relative to the source base UNC), the target directory (relative to the
target base UNC) and the file size (and maybe some other things as well).
The "ProgramsToCopy" might be kept in an ArrayList, and when working ths
list, you'd tell each instance of "ProgramToCopy" to copy itself; the
ProgramToCopy instance would tell all its "FileToCopy" instances to copy
themselves...

[...snip...]
I need to know where to draw the lines.
Click to expand...
[...snip...]

If you are modelling a system, you'll have to know all objects you need, all
of their attributes and methods and the use cases you want to implement in
your software. So, it might well be that the line is drawn at the very
bottom. During analysis, you will find out what's necessary...

HTH
Michael
 
Michael Voss said:
Why not ? This would involve creating one (!) class like "ProgramToCopy",
which would know about source base UNC, target base UNC and involved files
(filesToCopy). Each File would be represented by an "FileToCopy" object (the
second class), which in turn knows the file name, the source directory
(relative to the source base UNC), the target directory (relative to the
target base UNC) and the file size (and maybe some other things as well).
The "ProgramsToCopy" might be kept in an ArrayList, and when working ths
list, you'd tell each instance of "ProgramToCopy" to copy itself; the
ProgramToCopy instance would tell all its "FileToCopy" instances to copy
themselves...
Click to expand...

There has to be a reason for creating the object. Just because something
can be done in an object doesn't mean it should, and that doesn't mean it
shouldn't. The design you suggest is fine, for some uses. In general,
however, I would ask: what are you encapsulating and why? Is there
variation in how two files in the system are copied? Do you need objects to
encapsulate the fact that one file is harder to copy than another? Then
encapsulating a file is fine.

On the other hand, if the variations are at the file system level, then
encapsulating a "directory" object and have a "copy-director" to communicate
between them may be a better direction. I can't say... the OP didn't
provide enough information to analyze the points of variation in a newsgroup
posting.

The order and structure of your classes are not just an expression of your
application... the ARE the application. This should not be done in the
first way that makes sense... this should be done in the BEST way that makes
sense.

If you read "Introduction to Design Patterns, 2nd Ed." by Shalloway and
Trott, you will see an extensive section on "Commonality-Variability
Analysis". This is a method of understanding and structure that helps to
"draw the lines" (as the OP put it) between what "could" work and what
"works better." (The idea was originally introduced by Jim Coplien).

A well structured program lasts longer, works better, and is less expensive
to produce.

--- Nick
 
Ian said:
I found Object Oriented Design Heuristics to be a very useful book. It's
probably not one to read as your first book on OO design, because it assumes
you already know the basics, but it provides a lot of useful real world
advice.

http://www.amazon.com/exec/obidos/tg/detail/-/020163385X?v=glance
Click to expand...

Ian,

This book is EXACTLY what I was looking for. I purchased it, and I've
read most of it. It explains why and when to use all those elements of
OO programming. Reading a plain C# book just explains the tactics, but
not the strategy.

Thanks for the referral!

-KV
 
Back
Top