What is the full form of OOPS ?. Some say Object-oriented programming structure others say Object-oriented programming system. Which one is correct ?.
This seems to be not a wide-spread acronym, similar question was asked also on softwareengineering section of stackexchange: https://softwareengineering.stackexchange.com/a/92181/82905
I'd "blame" OOPSLA conference for OOPS, where S is indeed "system", however I'd avoid using this at large (read "at all"). It is not well-known and asks for confusion. Is it a system programmed in a OOP way? Or is it IDE for OOP language?
The programming paradigm is OOP "object oriented programming". All other may be drived from it and can mean everything.
OOPs stands for : Object-oriented programming system
Related
Can we use Procedural Programming to solve any problem that can be solved using Object Oriented Programming Concepts? My problem is are there some particular problems which can only be solved using OOP concepts.
Please help me understand this.
Yes. Anything that can be solved using OOP can be solved using procedural programming. In the end the compiler just turns your OOP code into assembly, which is procedural.
It all comes down to what the combination of the CPU/RAM etc in your computer can do. Since your computer is Turing Complete it can solve any problem that be solved by any other language or machine that is also Turing Complete.
Nearly all programming languages are "Turing complete". That means programs written in one paradigm (say the functional one) can always be converted to another one (say the logical one). A compiler is just a tool that translates code from one language/paradigm to another. Thus the moment a language is Turing complete, you can solve anything in that language you can in any other, although the performance and elegance of the code might vary.
Currently on the hardware level, the only implemented paradigm is the procedural one (there have been some experiments with the functional and logical one and even OO has already been implemented on a CPU).
I'm thoroughly intrigued by Scheme, and have started with some toy programming examples, and am reading through Paul Graham's On Lisp.
One thing I haven't been able to find is a book or website intended to teach Scheme to "OO people", i.e. people like myself who've done 99 % of their coding in c++/Java/Python.
I see that closures are sort of object-y, in the sense that they have local state, and offer one or more functions that have access to that state. But I don't want to learn Scheme only to port my existing habits on to it. This is why I'm learning Scheme rather than Common Lisp at the moment; I fear that CLOS might just serve as a crutch to my existing OO habits.
What would be ideal is a book or website that offers case studies of problems solved in both an OO language, and also in Scheme in a Schemey way. I suppose I would most appreciate scientific computing and/or computer graphics problems, but anything would do.
Any pedagogical leads would be much appreciated.
I doubt CLOS would serve as a crutch for old habits, I found it to be pretty different from the OO style in C++/Java/Python, and very interesting. I don't understand all the details, but I would recommend Peter Seibel's Practical Common Lisp. If you are reading On Lisp without much trouble, you should be able to dive into the chapters introducing CLOS in PCL. Also, I'd recommend his Google Tech Talk comparing Java and Common Lisp.
Here's a few more recommendations to make this a more full-fledged answer:
The classic text Structure and Interpretation of Computer Programs covers quite a few examples in chapter 3 of building modular systems using closures (and addresses issues with introducing state and mutability). Chapter 2 includes some generic and data/type-directed programming which could be helpful for motivating study of CLOS. This book really needs no introduction though, it's a towering work, and I've only been reading it slowly since the spring. Highly recommended if you are interested in Scheme.
While SICP is a great book, it's not without its flaws: A really interesting look at these is the essay "The Structure and Interpretation of the Computer Science Curriculum" which elaborates on a few criticism of SICP, and is written by the authors of How to Design Programs (I haven't read HTDP but I hear it's very good). While this essay won't teach you specifically what you are looking for - comparing functional and OO programming - it is really interesting anyway. Their freshman undergraduate course starts with a first semester introduction to functional programming using Scheme (I think, PLT/Racket) and is followed by a semester of OO programming with C++ or Java... at least that's the course they describe in the essay.
These slides from Peter Norvig address some of the design patterns common in OO programming and show why they are missing or unnecessary in dynamic, functional languages like Scheme and Lisp: http://norvig.com/design-patterns/
I cautiously recommend the book by the same authors as the Little Schemer books: A Little Java, A Few Patterns. I can't say for sure if this is a really a good book or not, it was incredibly strange and there are some really bad typesetting decisions (italic, serif, variable-width, superscript doesn't belong in a text on programming), but it might be interesting to take a look at. You can probably find it cheap, anyway. Don't take this recommendation that seriously. I think it would be better to stick to the Scheme texts.
p.s. I have to disagree with one comment stating that functional programming is not as complicated at OO programming, I think that's grossly misstating it. Functional programming in all its breadth is truly mind-boggling. When you go beyond map/filter/reduce and first-class functions, and take a look at other things in the functional realm like lazy evaluation, avoiding side effects and mutation, and the strong, static-typed languages, it gets pretty interesting, and is certainly just as complicated as traditional OO programming. I've only just scratched the surface myself but have discovered a great deal of new ideas. Programming is complicated business, whether OO or functional.
Congrat you, my friend ! Love cs, love functional programming.
If you are python developer it takes 3-4 days to think in scheme
Here is the best simple tutorial I have ever met http://www.shido.info/lisp/idx_scm_e.html
I found this course http://cs.gettysburg.edu/~tneller/cs341/scheme-intro/index.html and it may be useful for you
One beginner's resource that is very helpful and geared very much toward the casual reader is "The Adventures of a Pythonista in Schemeland". It's written (obviously) from the point of view of a Python programmer taking first steps with Scheme. One especially nice thing about it is that it includes an overview of the current implementations and compatibility issues between each scheme implementation, which, unfortunately, can cause some headaches when you're just starting out.
With regards to object systems, these two documents (linked from here) give nice examples of very simple toy implementations using closures that I found helpful in understanding their use in capturing state.
If you are starting off with Scheme, have a look at How to Design Programs. This book presents the "Schemey" approach to problem solving. I don't think there is a book that compares OO and functional solutions to the same programming problems. But there is a nice presentation that shows how dynamic languages like Scheme could provide simple solutions to problems that demand complex design patterns in statically typed OOP languages.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I want to ask you to provide me with some articles (maybe books), which you possibly have found very convincing criticising the OOP methodology.
I have read some in the WWW on this topic and I didn't really find a 'definitive demotivator'.
It's not much about my personal attitude to the OOP, but I really would like to have something constructive, rigorous foundation for any kind of discussion and just abstract thinking.
You can post some original research too, but please be very constructive (as my personal request).
Which version of OOP? Alan Kay's original vision? The bastardized modern form of it that misses the point entirely and thus encumbers us with bizarre access control, member variables, etc? Inheritance-centric? Prototype-based? Compositional OOP?
Each form of OOP has its strengths and its weaknesses; its advocates and its detractors; its domains of utility and its domains of uselessness. There's nothing magical about OOP that makes it the Killer Paradigm and there's nothing infernal about it that makes it the Killer (of Programmers) Paradigm.
I can't really point you to any books or articles that killed my interest in OOP as a Silver Bullet (as opposed to one of many techniques I can use to keep my projects survivable). I can point to the funniest critique of a specific brand of OOP, however: Steve Yegge's classic "Execution in the Kingdom of Nouns".
Rick Hickey's Are We There Yet ? - A Deconstruction of Object Oriented Time was an eye opener for me. It's the most logical OO criticism I have come across.
If you want a criticism of OO programming, here's what I'd recommend:
Learn Smalltalk
Learn Erlang
Learn Scheme
Once you've done that, you will have plenty of criticism of the common interpretation of OO programming.
(Hint: OO was in many ways intended to more closely resemble the Actor model of computation, but the common interpretation of it is effectively a modification of the procedural/structured model)
Problem is - most people don't really know Object-Oriented Programming, so many designs SUCK.
Read the works of Scott Ambler, including his (now pretty old) Building Object Applications That Work. This has been eye-opening for quite a lot of people.
Maybe not quite what you were looking for but have a look at the Jan/Feb issue of IEEE Software magazine: Object-Oriented Analysis: Is It Just Theory?. The basic conclusion is that OOA does not provide a good cost/benefit ratio so is poorly utilized.
Given that OOA is not effectively utililzed or supported in the "real world", I suspect that for larger development projects the overall system architecture, deployed object model and class hiearchy end up being sub-optimal and poorly understood (implemented) by various parts of the development team. A second article in the same journal: Four Trends Leading to Java Runtime Bloat point to some common OOP issues that detract from deploying high-volume Java (OOP) systems. The observations made in this article probably apply to most highly architected OOP applications.
Do not take this as OO bashing, it just reflects that as software practictioners we have quite a bit of work to do toward developing better person-to-person communication mechanisms to convey highly complex and abstracted process models.
When you define a process in natural language. You use sentences where you define the subject who will do an action on one or more objects.
The only fix point is the action, the predicate of the sentence.
I don't think assigning actions to objects is a good idea.
There is only one verb, but can be multiple nouns.
In OOP you can write a file in at least 3 ways:
file.write(data);
or
data.writeToFile(file);
or
OperatingSystem.write(file, data);
Which object should implement the method? You need to think about this too.
While in the procedural way, you probably write
write(file, data);
And the only thing you need to think is the order of the operands which is usally does not matter.
(Well file and data may not be the best example but you probably see the point)
You should really see Mr. B. Jacobs's:
OOP Myths Debunked
(also known as OOP Oversold.)
http://cat-v.org has a great page on Object Oriented Programming.
Most of the page consists of humorous but not terribly informative quotes. However, at the bottom of the page are a number of links to articles challenging OOP. They are:
Bad Engineering Properties of Object-Oriented Languages by Luca Cardelli.
Why OO Sucks by Joe Armstrong
Pitfalls of Object Oriented Programming – By Tony Albrecht of Sony Computer Entertainment Europe, Research & Development Division.
Object-Oriented Considered Harmful by Frans Faase.
Object Oriented Programming Oversold!
I Hate Patterns – By Parand Tony Darugar.
Why arc Isn’t Particularly Object-Oriented – By Paul Graham.
The questions about inheritance in the Java IAQ.
Stop Writing Classes – Great talk about how classes are often used and abused. By Jack Diederich.
If you are interested in alternatives to Object-Oriented Programming:
cat-v.org. From their 'about' page: Cat-v.org hosts a series of sites dedicated to diverse subjects that share an idiosyncratic intellectual perspective, questioning orthodoxy and fomenting elitism and high standards in topics from software design to politics, passing by art and journalism and anything else interesting.
Structure and Interpretation of Computer Programs. Specifically teaches functional programming. Available free online here, for sale here. I cannot recommend this highly enough. It is absolutely revolutionary. It will change the way you think.
Any and all writings/videos/lectures by Rob Pike and Steve Yegge. Of particular interest is Yegge's Whirlwind Languages Tour.
I'd recommend learning a different programming paradigm or reading pro arguments for specific paradigms (http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf). Besides OOP, I think the most widely used is the functional paradigm (search f.e. "Why functional programming matters"), but also have a look at the other ones. When you start looking at programming from a different perspective, the flaws of OOP start to appear automatically.
Simple exercise: define the objects IPerson, CMale and CFemale and implement the methods "sex" and "reproduce".
hows about steve yegge's execution in the kingdom of the noun
for java style OO
The Gideon Bible of object-oriented design patterns, aptly named Design Patterns. One of the best software design books I've ever read.
When I say "full" I mean a language that's not an extension to some already existent language like Java or C++. When OOP started it begun with extensions for procedural languages like C and Pascal. Is there any Aspect-Oriented programming language "by itself"?
Short answer: No
But there are languages that contain constructs that mimic aspects, for example Haskel which contains the possibility to add advices or Smalltalk because of its message approach. You could also look at Eifel with its contract oriented approach - that could be compared to applying aspects to functions.
But a pure AOP language, I would say no.
Edit: And sure enough, someone found an AOP language ;)
Well the answer is as usual "Lisp". It has after and before methods in the ANSI Lisp Definition and you can do a lot of the AOP stuff with macros.
While reading some programming books, I notice that the authors says that, in OOP, you may have some confusion while understanding the main idea of OOP.
And hell yeah!. I had some confusion. Did you have the same and what makes this confusion to programmers(even experienced programmers)?!
And if you had it, how could you beat this ?!
Thanks
The Animal trope works when explaining it to most people.
(Further useful links here and here)
A lot of the confusion when learning OOP comes from trying to pick the right relationship between objects and classes of objects, particularly whether:
Object contains Some other Object (or Object1 has an Object2)
Object is an instance of Class
If I can think of a good example that shows a case where either might be appropriate, I'll add it...
OOP takes a "problem oriented" approach to programming as opposed to the traditional "machine oriented" approach used in languages like C and Pascal. Learning OOP can be quite tough if you've programmed extensively in procedural/functional languages. It is to these programmers that things tend to be more confusing. If you are new to programming, you'll probably find things a lot less confusing since you're starting off with a fresh mind.
Having said that, I've seen many programmers who've worked extensively with languages like Java and claim to be good OOP programmers when they were actually far from it. Sure they use Java language features like interfaces, inheritance etc, and create objects "which are instances of classes", and "send a message to an object". Most people use a lot of OOP jargon because they are exposed to it. But when it comes down to writing a simple application their resulting code exposes their poor understanding.
My advise to you is don't get caught in using jargon alone. Question and learn the underlying concepts diligently. You might have your first semi-nirvana (like I did) when you learn polymorphism and the benefits it brings to code re-usability. Another semi-nirvana when you understand the trade-offs between reuse via inheritance and reuse via composition. In the end, you will know that you've understood OOP well if you able to design well, or rather, a good OO design is easily a good measure of how well you understand OOP.
If you are serious about OOP, you should read the first two chapters of the GOF book on Design Patterns. It might be a little tough on new programmers, but it lays the crux of the thinking behind OOP. This book is an important reference which any serious OOP programmer should have. If you understand the concepts in this book well, consider yourself to be a good OO programmer.
Yes, I experienced a bit of confusion initially. This was back in the day when OO was just starting to become mainstream, so there were a lot of books out there which covered it, but didn't explain it well for people who didn't already know what it was. As a result, I started out thinking that an object and a class were largely interchangeable and defining a new class for each object I wanted to create.
I finally "got it" by playing around on LambdaMOO, a MUD (think World of Warcraft, but with no graphics) with an object-oriented in-game programming language. Ironically, MOOCode makes no distinction between classes and objects - objects inherit directly from other objects. (It did have a convention of objects intended for use as "base classes" to be named "Generic Foo" as a way to distinguish them from specific ("instance") Foos, but that's as close to a class/object distinction as it had.)
Indeed, I think way too much emphasis is put on the 'class' concept.
The biggest leap forward in my understanding was when reading about the "Tell, don't Ask" principle.
I only started 'feeling' Object Orientation when playing around with (and reading about) duck-typed environments like Ruby, JavaScript, Python etc... after like 8 years happily creating truckloads of classes in C++.
Statically typed languages are great for production code, but you pay a lot of overhead when trying to get a feeling for Object Orientation.
Also, next to the commonly used term OOP, often one forgets that first comes OOA and OOD.
I think that especially programmers, that were experienced in the development with function-oriented languages, had trouble understanding the concepts of OOP. At least, it was really confusing to me and i did a whole bunch of things to program functional while using an OOP language(Java).
But i also think that the OOP approach is a great thing to beginners because this approach ist very "natural".
I never really had any confusion but I learned programming along the time-axis it evolved. so I had assembly, c, c++, java, c# and loads of other which is not relevant here. What you have to embrace is that everything shall be expressed by an object and an object contains information describing itself (properties) and that they can perform tasks related to them (methods i.E.: Car.GetAllCars();).
For inheritance and polymorphism and all the rest I recommend practice. practice everything - since practice makes perfect. Try to develop the examples given in all the books.
Once you understand the oo basics take a look at design patterns and design principles (e.g. by reading Head First Design Patterns). It will teach you how you should actually use the tools that oo gives you. While this is no substitute for practical experience it can certainly speed up the learning process.
Thank you for your answers.
I think giving examples works best but not every time, right ?!
I heared the creator of C++ when he said, it takes time and patience and you will understand it better by trying.