From: subramanian100in on
I have covered C++ to some extent(from Bajarne Stroustrup TC++PL and
Stanley Lippman's C++ Primer). I want to learn how to identify
classes, class relationships, identification of objects, from given
problems. Kindly suggest me easy-to-understand books for beginner like
me. Essentially I want to learn OOA and OOD. Please do NOT suggest
books which will be tough for understanding.

Kindly help.

Thanks
V.Subramanian

From: Phlip on
subramanian100in(a)yahoo.com, India wrote:

> I have covered C++ to some extent(from Bajarne Stroustrup TC++PL and
> Stanley Lippman's C++ Primer). I want to learn how to identify
> classes, class relationships, identification of objects, from given
> problems. Kindly suggest me easy-to-understand books for beginner like
> me. Essentially I want to learn OOA and OOD. Please do NOT suggest
> books which will be tough for understanding.

Easy. Given requirements, write very simple code, and write test cases for
all the code's behavior. When your code has duplication, refactor its
design, and pass all the tests after each little edit.

If you have two blocks of code with the same behavior, use Extract Method to
refactor them into a common function. If these two blocks of code now share
common variables, use Extract Class to sprout a class. If you keep going
like that, you generally create a lean and efficient design that's very
easy to upgrade. When you add features similar to the ones you added
before, you typically _won't_ need to refactor. That's called "Open Closed
Principle".

El Goog will tell you more about these things!

These techniques rapidly generate good designs while avoiding a lot of
debugging.

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
From: Lee Riemenschneider on
On Thu, 4 Oct 2007 14:38:38 UTC, "subramanian100in(a)yahoo.com, India"
<subramanian100in(a)yahoo.com> wrote:

> I have covered C++ to some extent(from Bajarne Stroustrup TC++PL and
> Stanley Lippman's C++ Primer). I want to learn how to identify
> classes, class relationships, identification of objects, from given
> problems. Kindly suggest me easy-to-understand books for beginner like
> me. Essentially I want to learn OOA and OOD. Please do NOT suggest
> books which will be tough for understanding.
>
The best book I have ever seen on these subjects is "Executable UML:
How to Build Class Models" by Leon Starr. Another good book for rules
for identifying classes and relationships is "Object-Oriented Systems
Analysis: Modeling the World in Data" by Sally Shlaer and Steve
Mellor. It covers identifying objects in more depth than the later
"Object Lifecycles" Shlaer-Mellor book or the Mellor-Balcer
"Executable UML" book. The latter two books are valuable from the
point of view of this query for their coverage of domain
identification, which is vital for good system partitioning.

These books only cover OOA, which is concerned with modeling the
problem space, not OOD, which is concerned with modeling the
implementation on a system.


--
Lee W. Riemenschneider
GO BOILERS!
Running eComStation (eCS)(the latest incarnation of OS/2)
Buy eCS everyone! Buy it now! http://www.ecomstation.com
From: H. S. Lahman on
Responding to Subramanian100in...

> I have covered C++ to some extent(from Bajarne Stroustrup TC++PL and
> Stanley Lippman's C++ Primer). I want to learn how to identify
> classes, class relationships, identification of objects, from given
> problems. Kindly suggest me easy-to-understand books for beginner like
> me. Essentially I want to learn OOA and OOD. Please do NOT suggest
> books which will be tough for understanding.

The books you have read describe how to encode a good design in an OOPL
by manipulating OOPL syntax. What you need to understand prior to that
is how to come up with a good OO design to encode. IOW, those are OOP
books and you need an OOA/D book. Check out the "Books" category of my
blog for some suggestions on finding one.

Be forewarned, though, that the OO paradigm is not very intuitive
compared to procedural or functional programming. That's because OOA/D
focuses on abstracting customer problem spaces that are typically very
different than computing spaces. The procedural and functional
programming approaches are tailored to the hardware computational models
that underlie most 3GLs. So you are facing a learning curve regardless
of what book you read.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH