Booch's book feels too philosophical rather than practical?
in [OOP]
|
Prev: Use Case Scenario Inheritance
Next: Do we need a guild?
From: arnuld on 20 Jan 2007 04:29 hai all, 1st of all i am newbie to what you call OOA-D. so i searched the archives of this newsgroup & i got this path: OOA-D -> UML -> OOP i also noticed one very interesting thing here about OOP step: OOP should be done preferably in a language that you will not use professionally, as told by "Lahman". i think he is right. reagarding OOA-D i see 4-5 recommendations but only 2 are available in my country: Booch & Rumbaugh i read some part of chapter 3 of "OOA & D with applications " by Grady Booch (around 10-12 pages). it feels *too* philsophical rather than practical, as if he is the king of "academic education" & doing Ph. D research on OOA-D or something like that. i dont even understand 10% of what Booch was talking about. it literaly swept above my head :-( . as per my experience, having a computer degree at hand ( i have a graduate degree) & writing code professionally are 2 very-very *different* things & Booch belong to the former side, at least this is is what i have felt. Does Rumbaugh writes in the same manner? UML authors like: Fowler, Page-Jones,Larman are easily available in my country (INDIA) i am learning C++ & not able to understand the OOP animal there. i only have done some non-professional Lisp Programming, like writing some trivial programmes & dont know any other language. what i want to say is, functional/procedural style comes naturally to me, this is exactly how i write trivial programmes & when i faced C++, i was completely blown-up into pieces. i dont even understand what exactly OOP is. i want to learn OOP and i dont want to read philosophical concepts. so i was thinking of buying Craig Larman's "Applying UML and Patterns". does anybody has any suggestions? "arnuld" -- http://arnuld.blogspot.com/ Linux registered user #439610 :: http://counter.li.org/
From: Daniel T. on 20 Jan 2007 08:40 "arnuld" <arnuld3(a)gmail.com> wrote: > i want to learn OOP and i dont want to read philosophical concepts. > so i was thinking of buying Craig Larman's "Applying UML and > Patterns". does anybody has any suggestions? I suggest you read Booch as if it was a novel. Don't try to understand or absorb it. Then read "Designing Object-Oriented C++ Applications using the Booch Method" by Martin and "Object-Oriented Design Heuristics" by Riel. These two books really opened my eyes. Then read Booch's book again and see what you think. A couple of other book suggestions, not strictly OO: "The Pragmatic Programmer" by Hunt & Thomas" and "Refactoring: Improving the Design of Existing Code" by Fowler. > what i want to say is, functional/procedural style comes naturally > to me, this is exactly how i write trivial programmes This is right and natural. OO is a method for handling complexity, it is rather forced to try to use it in trivial applications. Read the post below as well: http://groups.google.com/group/comp.software.patterns/browse_thread/threa d/d6e77220da9d415c/2d3fa888f4ec1652?tvc=2&q=group%3A*software.patterns*+a uthor%3Adaniel#2d3fa888f4ec1652 You don't have to intuit OO in order to take advantage of it: In procedural code, we are taught to move duplicated blocks of code into a function. Those for whom procedural is "intuitive" are special in that they can spot duplication before it's in the code and create that function up front. People who intuit OO can spot duplicated decision code before typing it. However, like the beginner procedural person, you don't have to "get it" in order to take advantage of it after the fact. When you see two switch statements that both switch off of the same variable, or two if statements that both check the same condition, just knock yourself on the head for not catching it beforehand and create polymorphic classes to remove the duplicated decision code.
From: Robert Martin on 20 Jan 2007 09:20 On 2007-01-20 03:29:47 -0600, "arnuld" <arnuld3(a)gmail.com> said: > i want to learn OOP and i dont want to read philosophical concepts. so > i was thinking of buying Craig Larman's "Applying UML and Patterns". > does anybody has any suggestions? Larman's book is quite good. You might also want to read the following article: www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Then go and read about each of the principles in turn by finding the coresponding articles at: http://www.objectmentor.com/resources/publishedArticles.html C++ is a complex language. Learning OOP by learning C++ is a bit like learning to sing by starting with opera. A simpler language would be more appropriate. I suggest two: Learn Ruby to experience what a good dynamically typed OO Language is like. Then learn Java to see what a relatively simple statically typed OO language is like. Then go back to C++. -- Robert C. Martin (Uncle Bob)��| email: unclebob(a)objectmentor.com Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com The Agile Transition Experts��| web:���www.objectmentor.com 800-338-6716� � � � � � � � ��|
From: H. S. Lahman on 20 Jan 2007 11:42 Responding to Arnuld... > 1st of all i am newbie to what you call OOA-D. so i searched the > archives of this newsgroup & i got this path: > > OOA-D -> UML -> OOP > > i also noticed one very interesting thing here about OOP step: OOP > should be done preferably in a language that you will not use > professionally, as told by "Lahman". i think he is right. First, a clarification. The above is not really a path. UML is a notation for OOA/D just as C++ or Smalltalk are notations for OOP. Thus the result of doing both OOA/D or OOP is a model of the hardware execution; one just happens to be a graphical notation while the other is a text notation. (The notations are also at different levels of abstraction.) While I advocate learning OOA/D before attempting OOP and I advocate using a "pure" OOPL like Smalltalk for learning OOP, I think those are different things. Model-based development does use UML as <formal> a step stone between OOA/D and OOP, but one does not /need/ to do OOA/D formally in UML when developing software. The important thing about OOA/D is the conceptual approach to problem solving, not the notation. > reagarding OOA-D i see 4-5 recommendations but only 2 are available in > my country: Booch & Rumbaugh > > i read some part of chapter 3 of "OOA & D with applications " by Grady > Booch (around 10-12 pages). it feels *too* philsophical rather than > practical, as if he is the king of "academic education" & doing Ph. D > research on OOA-D or something like that. i dont even understand 10% of > what Booch was talking about. it literaly swept above my head :-( . as > per my experience, having a computer degree at hand ( i have a graduate > degree) & writing code professionally are 2 very-very *different* > things & Booch belong to the former side, at least this is is what i > have felt. > > Does Rumbaugh writes in the same manner? I don't think the issue is academic perspective for either author. Both Booch and Rumbaugh had substantial practical experience and AFAIK neither held a university teaching position. (Booch was building computers and programming when he was in high school.) Booch spent most of his career at Rational Software, which was founded as a consulting company to industry. Before going to Rational, Rumbaugh spent quite awhile at GE. The OO paradigm is not intuitive if one is used to development using traditional procedural approaches like Structured Programming. To properly do OO development one must essentially forget everything one learned about procedural development because it will just introduce confusion. I suspect that what you perceive as an academic perspective is primarily just a new way of thinking about software development. In the Books category of my blog a point I make is that selecting an OOA/D book is a personal thing. Different authors' styles can strongly affect how well the message gets across. So the best way to select one is to browse in the library first using the criteria I provide in the blog. However, if the choice is as limited as you suggest that may not be an option. In that case I can only suggest reading their books carefully with an open mind. View the books as explaining a new way of thinking about solving problems and try to understand the approach itself regardless of how the approach compares to what you already know. > > UML authors like: Fowler, Page-Jones,Larman are easily available in my > country (INDIA) > > i am learning C++ & not able to understand the OOP animal there. i only > have done some non-professional Lisp Programming, like writing some > trivial programmes & dont know any other language. what i want to say > is, functional/procedural style comes naturally to me, this is exactly > how i write trivial programmes & when i faced C++, i was completely > blown-up into pieces. i dont even understand what exactly OOP is. > > i want to learn OOP and i dont want to read philosophical concepts. so > i was thinking of buying Craig Larman's "Applying UML and Patterns". > does anybody has any suggestions? Larman's book is more practical in the sense that it is more about How to apply an OO methodology while Booch's and Rumbaugh's books are more about What an OO methodology is. IOW, Larman's book emphasizes the /process/ of developing software more than the A&D principles. Even if you find Larman's book easier to grasp because of the familiarity of the overall processes like IID, I would suggest going back to Booch and Rumbaugh and re-reading them with you new knowledge. ************* 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
From: arnuld on 20 Jan 2007 12:24
> I suggest you read Booch as if it was a novel. Don't try to understand > or absorb it. Then read "Designing Object-Oriented C++ Applications > using the Booch Method" by Martin and "Object-Oriented Design > Heuristics" by Riel. These two books really opened my eyes. Then read > Booch's book again and see what you think. i dont have Booch, i have an illiegal pdf copy. book is too expensive, nearly 2.5 times expensives than Rumbaugh's :-( if i need to purchase then i will choose Rumbaugh. BTW, the other 2 books you mentioned, of Reil & Robert Martin, are not available in India. > A couple of other book suggestions, not strictly OO: "The Pragmatic > Programmer" by Hunt & Thomas" and "Refactoring: Improving the Design of > Existing Code" by Fowler. these 2, also, are not available in India. BUT these are available: "OBJECT ORIENTED SOFTWARE ENGINEERING" by IVAR JACOBSON "UNIFIED MODELING LANGUAGE USER GUIDE" by BOOCH / RUMBAUGH / JACOBSON "UNIFIED SOFTWARE DEVELOPMENT PROCESS" by JACOBSON / BOOCH / RUMBAUGH "UML DISTILLED" by MARTIN FOWLER / KENDALL SCOTT "FUNDAMENTALS OF OBJECT ORIENTED DESIGN IN UML" by MEILIR PAGE JONES "APPLYING UML & PATTERNS" by CRAIG LARMAN "EXECUTABLE UML - FOUNDATION FOR MODEL DRIVEN ARCHITECURE" by MELLOR / BALCER "OBJECT ORIENTED MODELING & DESIGN WITH UML" by MICHAEL BLAHA / JAMES RUMBAUGH > Read the post below as well: > > http://groups.google.com/group/comp.software.patterns/browse_thread/threa > d/d6e77220da9d415c/2d3fa888f4ec1652?tvc=2&q=group%3A*software.patterns*+a > uthor%3Adaniel#2d3fa888f4ec1652 "out of my head", the problem explained by OP (Frank O'Haram in that thread) really looks like Ph. D. thesis to me, disconnected from the real world. > You don't have to intuit OO in order to take advantage of it: what does that mean? :: You don't have to intuit OO in order to "take advantage of" it: OR You don't have to intuit OO in order to "understand" it: > In procedural code, we are taught to move duplicated blocks of code into > a function. Those for whom procedural is "intuitive" are special in that > they can spot duplication before it's in the code and create that > function up front. > > People who intuit OO can spot duplicated decision code before typing it. > However, like the beginner procedural person, you don't have to "get it" > in order to take advantage of it after the fact. i don't see any difference between these 2 explanations. may be because of my newbie-ness. |