Talk:Object Oriented Programming
From Wikibooks, the open-content textbooks collection
I'm the primary author so far, although some others have contributed too. I hope you get the idea of where I'm headed by looking at the TOC and reading what's there. If you have thoughts, post 'em here. Feel free to fill in some blank topics. Note that I will edit for tone etc so it reads like one author. Augustus.saunders 13:30, 12 Sep 2004 (UTC)
Wow, looks really really good so far. Like the fact that you didn't forget the classless (prototype-based) oop, which normally happens. I personally don't feel that C++ or Java are at the same level at smalltalk, many things are not objects in both Java and C (e.g.: Classes are not objects and methodes neither). But so far a very good job. Gmlk 15:30, 12 Sep 2004 (UTC)
Well, I'm just adding a couple of paragraphs here and there every once in a while. Already spent too much time tonight, for just a few measly words. Augustus.saunders 09:04, 25 Jan 2005 (UTC)
I'm attempting to learn object-oriented programming from scratch. The beginning of this book has been quite informative. I look forward to its completion. Thanks for writing it. Evan Chaney 03:17, 17 Jun 2005 (UTC)
I think it would, at least for a while, be more beneficial to link to Wikipedia pages rather than Wikibook pages on certain items, like CLOS or C++ STL. --Snaxe920 05:51, 15 March 2006 (UTC)
Re: tone and inheritence. I think an editor that selected more academic vocabulary would be better suited for a work that desires 'textbook quality'. Granted, I didn't read the whole article, I just skimmed it as I evaluated its suitibility as an introduction to object-oritented programming for non-programmers. I stopped reading and dismissed the content as worthless when I came across the "is-a vs has-a moley baloney" topic under "Inheritence"; if one does not recognize the importance of these two fundamental relations then it is impossible to build quality software using object-oriented techniques or otherwise.
For example, while colloquially understandable, I feel the term 'moley baloney' is completely inappropriate. I feel The entire "Inheritence" section is poorly structured and contains little information of value. I completely agree that inheritence is an often misunderstood concept for many programmers new to object-oritented techniques. The muddling of "interface" and "implementation" in popular class-based object-oriented language inevitably leads to misunderstandings. This section would do well to cite sources that examine inheritence from an object- or functional-based perspective as it is impossible to understand inheritence before the conflicts between the notions of 'type', 'class', and 'interface' are resolved. Which brings me back to where I started as it is my belief that such understanding can only achieved if one understands the is-a and has-a relations.
- Obviously, you didn't look very closely. This text is specifically not aimed at non-programmers. It is not an academic treatise. However, many, many texts trot out the old is-a vs has-a discussion when itroducing inheritance. This confuses type, class, interface, and implementation. Because this confusion is so common, I feel it is necessary explain it's failings. Going into a long winded discussion of type theory and systems before before tackling this confusion is premature, in my opinion. --Augustus.saunders 00:55, 7 September 2006 (UTC)
Contents |
[edit] What is OOP? What is OOP? What is OOP?
This text is a horror. It is a horrible read. Demotivating. There is so much incoherent babbling about nonrelevant stuff... or about somehow juicy stuff we are not supposed to know yet, but get a taste of nevertheless, but should remember not get into too deep yet, but is nice to get a feeling of already, but we'll explain it later really, and now we will not, but it is nice to... AAAARGh! I'll never understand what Object Oriented Programming is! Please, authors, get to the point! What the hell is OOP?
Why the long introduction about "classical OOP" and a "modern OOP" without telling us first what is OOP. And add in REAL Python code, instead of having us read a warning paragraphs about pseudocodes. The thing I have learned after reading six A4 pages is: encapsulation is important, encapsulation, encapsulation, encapsulation, encapsulation, encapsulation... I ask myself: what the hell is encapsulation? oh, dear reader, haven't we explained that? No! you haven't!
Are you writing a book on the different ways of writing a book?
- In most books, this chapter would be the heart of the book. But this isn't "How to Program Language-of-the-week Without Even Trying," and we're not syntax obsessed, assuming you can look in the manual or one of those other books. We want to blaze through here focusing on the concepts and the why's and what-fors so we can get on to the programming! Like we said before, this isn't an academic treatise.
- "There are some books on OOP that will tell you that the cornerstones of object oriented programming are encapsulation, inheritance, and polymorphism, or something along those lines. This is fairly typical of the classic OOP view, and there's nothing wrong with it per se, it's just that we've generalised some ideas and decoupled things here and there since then. But they are still important concepts, so let's dive in!
Who cares that there are different ways of writing books! We come here to know: What is OOP? I don't know. And this way I will never know. Why don't you get to the point? Why do you need to talk about other books? We don't want to know! We want to know about OOP, not about different ways of writing books. Aaargh! (from unknown)
- I would have thought Wikipedia could tell you what OOP was. This book seems to be focused on what the features of OOP are, how they are used, and what is good or bad about each of those features. I don't really see your problem with this text, at least the author is giving an attempt to be entertaining and "personal" to alleviate text boredom. 222.158.163.9 13:57, 3 August 2006 (UTC)
I think that you are looking for a different book. "OOP" and "Object Oriented Programming" means many things to many people. Providing a dictionary definition early in the discussion would confuse things more than help. One of the aims of this text is to counteract much misinformation that has spread over time. There is a lot of wrong-headed advice given in other texts available, especially those focusing on one particular language, that I feel that it is necessary to address this misinformation. This derives from a long legacy of ideas superseding each other. Any text on C++ today that ignores template and generic programming and the STL would be completely remiss. Similarly, any text hoping to describe modern OOP programming must address the influence of functional programming. Ruby, Python, and the Boost libraries pretty much define modern OOP practice (by which I mean being used in the real world, not some fancy-pants academia thing). Nobody would accuse Java or .Net of being on the forefront of programming technique. But people think of them as being "object oriented." Basically, the programming techniques vary significantly depending upon which abstractions a language supports. Thankfully, they can be loosely divided into 2 categories, which I choose to call "classic" and "modern." I think the terms are appropriate. Trying to define OOP independant of these is, IMO, a mistake. OOP is used as such a catch-all term it's necessary to lay out a map.
Finally, many random people contribute little bits and pieces, and obviously everything is a work in progress. You may be used to 3 page articles on "exxxxpert-programmer.com" or some such, but books tend to have introductions that establish the basics and set the stage. Books tend to go more in-depth and go a little slower. A book of this type should be in the 300-500 page range to have any hope of adequately covering the material. Currently, there is a fair word count on design patterns that would more properly belong in an appendix. Aside from that, the total page count here is less than 20. So of course it never delivers. --Augustus.saunders 00:42, 7 September 2006 (UTC)
I agree with unknown user, the language used is kinda chatty and really doesn't get the point across to some of us...(Uh...tide, tide...something. Why don't they have a button for it here?)
[edit] is a Vs has a
The main reason for this concept--a very good one--is that inheritance can be a bad idea, it binds classes too tightly and makes both reuse and debugging more difficult.
I'm not saying there aren't many perfect cases for inheritance, but misusing it is much worse than not using it at all.
When teaching someone new to the subject when to inherit and when to encapsulate, "Has a" or "Is a" makes a good test. You will find very few instances of "is a", and that's exactly how often you should subclass.
The single case for inheritance is where multiple children inherit from a single parent, override methods of that parent, and have those methods called through an object of the type of the parent (IE: you are using polymorphism).
The first Java GUI framework (AWT) was extend-based. It was a horrid model that didn't scale. Notice that in Swing you are never required to extend?
For a another viewpoint, you might google "Extends is evil"[1], there is a java world article that does a great job of examining why you should limit instances where you subclass.
Note that implementing an interface is a COMPLETELY different discussion--It has nothing to do with subclassing and should not be avoided--in fact, should be used as often as possible.
(I'd like to move the meat of this rant into the main module, but I'll wait for comments first since it may be more controversial than I would have suspected)
--Bill 00:18, 7 December 2006 (UTC)
Object oriented programming is said to be one of the most influential developments in modern computer programming, gaining acceptance and praise for it’s’ ability to facilitate complexities in a field of growing software systems. Object oriented programming as a concept is a programming language which uses some object oriented construct or programming which in term is supported by some object oriented principle. Object oriented programming is noted to be a mindset which respects programming as a problem solving method which requires precise application of abstractions which ultimately divides complex problems into manageable pieces or tasks. Idealistically object oriented code can be broken down into a vast number of smaller tasks with each task being simplistically verifiable. Ultimately the goal of object oriented programming is to facilitate the combination of several different programming functions and techniques for the purpose of easier maintenance and more widespread reuse, with the future hope of standardization of functional techniques within the object oriented programming
[edit] Functional Programming
Why on earth would there be a functional programming section in an OO book? Not debating the usability of Functions, just the placement. If I don't see comments in a few days, I'll delete that and fix the "is a vs has a" stuff.
I wanted to write my own book, but in completely different manner. I want to start from Functional Programming first. Can I begin my own book? I am new in wikibook... alexsmail 15:55, 14 April 2007 (UTC)
- If you don't intent into duplicate content creating a new book with a new approach and directed to a different audience is possible, but it will split the number of possible contributors Try to see if no one objects first to the changes (I've checked the history log for contributors and it seems the only registered users contributing content are User:Augustus.saunders and User:BillKress try posting a note on their talk page or directly contact them by email if available), give it a week if no one objects you can reshape the book, try to find another place/context to any content you will be removing if possible. See Wikibooks:Be bold, and thanks for asking first... --Panic 19:53, 14 April 2007 (UTC)
-
- I have post note to their talk page. Why not to create another book on the same issue? I want to include Procedural Programming too as the basis. Every chapter will be look like: breaf description of the concept, real world example, sample example on Java, lengthly discussion with more sophisticated examples using C++ example to clearify two diffirent implementation of the same concept (and highlight diffirence between concept and interface) and lengthly theoretical part. alexsmail 17:49, 15 April 2007 (UTC)
-
-
- If you avoid a direct "collision" with a pre existing book, I don't think anyone will cause problems. You should also take a look into Wikibooks:Forking policy, this is a draft of a policy, in there you may get a feeling on how some of the community feel about this type (if not exactly the same) situation, or take a look on the multiple books on C++. --Panic 18:17, 15 April 2007 (UTC)
-
- reset
Ok if no one is working on it then you may decide to reshape the book or start a new one, you have given every chance to anyone to object to it, it is now up to you. --Panic 16:08, 21 April 2007 (UTC)
[edit] "State" is Evil!
On "State" is Evil! section, the examples were supposed to be in Ruby? They don't look like Ruby to me
