As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
My friend was asked the following question: what's the difference between object language and object-oriented language?
It's a little unintelligible question. What does term «object language» correspond to? Does that mean «pure» object-oriented language, like the Wikipedia article says:
Languages called "pure" OO languages, because everything in them is treated consistently as an object, from primitives such as characters and punctuation, all the way up to whole classes, prototypes, blocks, modules, etc. They were designed specifically to facilitate, even enforce, OO methods. Examples: Smalltalk, Eiffel, Ruby, JADE, VB.NET.
Unless the person was interviewed by a philosopher talking about an abstract metalanguage, or an old-school engineer talking about the end result a compiler produces, the question sounds like semantic masturbation by someone who doesn't speak the same language as the rest of the industry.
So in other words, the distinction is whatever the interviewer wants it to be. (Or perhaps the question was misheard). I don't think most developers would think that the terms are connected enough to be worthy of comparison and contrast.
The right response would probably be in the style of a psychoanalyst: What do you think it means? Ask clarifying questions to make sure you understand what the interviewer is asking and assuming. Then leave and don't call the employer back, because you don't want to work there.
The term object does not have an official, widely used or otherwise well-known definition.
The term object language does not have an official, widely used or otherwise well-known definition.
The term object-oriented does have an official definition, but that is usually completely ignored, not widely used nor otherwise well-known.
The term object-oriented language does not have a single official, widely used or otherwise well-known definition, it is usually understood to mean
a language in which object-oriented programming is possible or
a language in which only object-oriented programming is possible or
a language in which object-oriented programming is easy or
a language in which object-oriented programming is easy and non-object-oriented programming is hard or
a language in which everything is an object or
any combination of the above or
something completely different (and note that in any of the above you can substitute arbitrary definitions for "object" and "object-oriented")
In short: the interview question roughly translates to "what's the difference between this thing I'm not going to tell you what it is and that other thing I'm also not going to tell you what it is?"
I'd suspect that the interviewer was looking for a distinction between object-based and object oriented.
This is, for example, using structs in C, with no polymorphism or inheritance.
The difference between the two for C and C++ is highlighted here.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been researching and looking for answers here to a problem that I suspect might be solved by a better understanding of design patterns. I think the problem is that I am a self-taught coder and people seem to tend to assume familiarity with a lot of esoteric terminology; I have ended up in Wikipedia spirals trying to determine what some phrases mean.
That said - on to the coding/structural problem.
Actually, just before I start, I should point out that I may well be making unknown presumptions in the way the code is structured in my question. If this is the case, could folks suggest alternatives to what I'm suggesting? I'd really appreciate learning how to better code as opposed to simply being told I'm doing it wrong.
OK...
Let's say we have a Room class, which has 4 Walls, a Ceiling and a Floor. These are instantiated 'inside' the Room. The Room also has a Table which has 4 TableLegs, again instantiated inside the Table, inside the Room. (This, I believe, is Composition, but please correct me if I've got that wrong!).
Finally, the problem:
If someone, somehow, pushes the Table, the TableLeg(s) will need to check the type of Floor they're standing on to trigger the appropriate sound. This, currently would be my solution:
The Table dispatches an event. The Room listens for that 'table pushed' event, quizes the Floor to determine its type, then passes that type to a method on Table, which in turn passes it to the TableLegs.
This, to me, seems fairly inelegant; hence my suspicion that knowledge of design patterns might be useful.
Is there something fundamentally wrong about the structure I've described that I'm not appreciating? If so, what is the alternative?
Finally, I have heard of the Gang of Four book. If that's my first port of call, is it written in an accessible style or will I have to have studied computer science to grasp it?
Sorry for the long, design-pattern-beginner's question.
The Floor could listen for objects Events. The Event interface could expose information about object geometry, material, etc. Then the Floor could check for collisions and play a sound.
I recommend the book Head First Design Patterns
I don't know if I can answer your question, but I can tell you something about the "Design Patterns" book.
It was an instant classic when it was published in 1994/1995. With examples in C++ and Smalltalk (there was no Java or C# back then), it listed solutions to 26 common problems in object-oriented programming. It provided a format for documenting forces and resolutions that was eagerly snapped up by academic conferences for years after. Lots of programmers, including myself, were studying it like holy writ in the hope that a single book could make them superstars.
Then reality set in.
Functional programmers said the patterns were work-arounds for flaws in OOP. What's the fuss? They could do these things without resorting to patterns.
The usual response on first reading the book is to try and fit as many patterns as you can into whatever code you happen to be writing at that moment.
You'll find yourself using the pattern names in design sessions: "I think we need a Chain of Responsibility here!"
Eventually you calm down and realize that patterns aren't the answers to your problems. The best way to use them is to think hard about your problems and solutions and suddenly realize that your answer happens to fall into a pattern.
As for your problem, I don't think you need a pattern. Have the Table send a message to the Floor to ask about its type before you generate the sound. That'll do it. Simplicity is a virtue.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I wrote a simple genetic algorithm to evolve the string "helloworld". I wrote it twice. The first time was written using classes. And the second time was written using just functions where the entire state of the genetic world is passed from one function to the next...to mimic the data flow paradigm. Surprisingly, the code worked well for both the implementations. However, I managed to get it working only after painstakingly removing each and every bug, which was quite a laborious process.
And I asked myself.. there has got to be a better way. Write the code using classes was comparatively difficult than writing the same code using simple functions and I believe writing the same code visually, using something like labview for example would be a lot more easier than writing it only using simple functions.
To that extent, I read about data flow programming and visual programming and quite frankly it seems like it is more natural and intuitive to program in a visual, data oriented manner than in a statement-wise manner, which is what most programming languages enable us to do today. My question is.. if this is the case, why hasn't data flow, visual programming like "labview" become the standard?
I do not believe that data-flow / "Visual Programming" has nearly the performance of well-designed code.
Text-based code can express far more complex and subtle data structures and flows than anything graphical. It gives programmers detailed control over what gets copied, what gets accessed, and precise control over sequences of steps. I have a hard time seeing how data-flow could be that expressive.
Ultimately, data-flow /visual programming can only describe things that are already known. Text-programming (for lack of a better term) actually lets you express more. Programmers can create entirely new data structures and algorithms that simply haven't been represented visually yet.
It is dangerous to use a single problem as the basis for how programming languages should be designed. I'm not sure how the data-flow paradigm would improve GUI framework design, for instance.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I started in High School learning java and python and I guess I just always learned OOP and nothing else my question is What are the other programming paradigms or types of programming languages beside OOP?
"Opposite" isn't really a good way of putting it. What's the "opposite" of Democracy? OOP is a a paradigm -- a way of viewing the problem of programming.
The four main coding paradigms are:
functional (viewing programs as mathematical formulas)
imperative (programs are series of instructions for the computer)
logical (model information and the relationship between that information), and
OOP (Model objects and how it interacts with other data)
http://www.cs.aau.dk/~normark/prog3-03/html/notes/paradigms_themes-paradigm-overview-section.html#paradigms_logic-paradigm-overview_title_1
Logical is the most different by far and you have to jump through a lot of hoops to solve some problems in logical programming. The other three all solve the same problems, but the approaches are different.
Procedural Programming is one of the other forms used.
http://en.wikipedia.org/wiki/Procedural_programming
There is no such thing. OOP is a concept built on top of procedural programming, there is no opposite rather there is a choice of writing in OO or not.
These answers are all wrong ... and that is a VERY good question ... and the answer is .... "AOP" - i.e. an "Algorithmic Oriented Programming" entirely based on the "algorithm" being at the very centre of the concept - in an AOP the "data" or an "object" or "objects"are simply "passed to the algorithm" - i.e. THE ALGORITHM IS ENTIRELY KING (it "knows" what to do with the data) - the data carries around "nothing".
In fact "we" (at Inferix) think OOP is a blind alley!
AOP is a much better model of reality - OOP is fine for "images on screens" and "data processing" but it cannot encapsulate intelligence - because "relationships and dynamics and intelligence" are not at it's core!
So we think that "AI Entities" (coming soon) will use only AOP!
Practically speaking Algol60, Coral66 and Inferix-MTR are examples of AOP languages - Algol60 became Pascal and Ada and the likes - and these just became more and more OOP (e.g. Delphi)!
The start of "typing" of values marked the end of AOP!
However: MTR is still a strictly AOP language (but unfortunately at present it is designed for AI entities to use and not humans).
You could think of an AOP as a language that strictly "prohibits" the typing of data elements and is only concerned with "values" of "signals".
There are several but i would say Functional Programming is the most opposite.
http://en.wikipedia.org/wiki/Functional_programming
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why Objective-C is chosen as language for cocoa or cocoa touch, why not other? What are main usages in Objective-C that are not in other languages.
How I can Convince the interviewer about this.
The main reason is that Cocoa is descended from NeXTStep, which was written in Objective-C back before C++ had the STL (IIRC it didn't even have useful templates back then; I recall g++ having big warnings in its template implementation into the early 90s). Also, I gather Jobs & co. preferred the Smalltalk-like OO of Objective C.
Cocoa is it self implemented in Object-C. By using that language a developer can more easily leverage the features of the hose system. While C/C++ are valid languages ( because of Objective-C background in them ) the interface between C/C++ and Cocoa ( because it's Objective-C ) is harder than if you were to just stick with Objective-C.
See more on this from Apple.
First, I think any language with GC is far more productive than any language without. Especially when programming in the large across many different teams, developers and frameworks, other techniques like reference counting are flawed and lead to code bloat. Many years ago there was a formal study that showed that the theoretical best performance of Generational Garbage Collection was about 4% of cpu usage. The theoretical best using reference counting was just under 10%.
The second thing to look at is how confining the language chosen is and how easy it is to blend with other C / C++ code. Many languages, such as Java, pretty much limit you to a single paradigm. Objective C is set of OO extensions on top of C. It has a great deal of flexibility as a result. In Objective C 2.0 and later, new features such as properties and blocks have also been added.
All the above said there are things I don't like about Objective C. It is more verbose than I like in a programming language and does not provide sufficient capabilities to do much meta-programming. I really am not happy that it still does not have namespaces. I know some of the reasons used to explain this lack but I do not find them at all sufficient. A flat class and method/selector namespace is not excusable in the 21st century.
What I really want is for MacRuby to take off and be implemented very very efficiently. A return of Dylan would also be very greatly appreciated. :)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When I'm learning a new language, I often program some mathematical functions to get used to the control flow syntax. After that, I like to implement some sorting algorithms to get used to the array/list constructs.
But I don't have a standard exercise for exploring the languages OO features. Does anyone have a stock exercise for this?
A good answer would naturally lend to inheritance, polymorphism, etc., for a programmer already comfortable with these concepts. An ideal answer would be one that could be communicated in a few words, without ambiguity, in the way that "implement mergesort" is completely unambiguous. (As an example, answering "design a game" is so vague as to be useless.)
Any ideas?
EDIT: I have to remark that the results here are somewhat ironic. 10 upvotes and (originally) 5 favorites suggest that this is a question others are interested in. Yet the most upvoted answer is one that says there is no good answer. Oh well. I think I'll look at the textbook below, I've found games useful in the past for OO.
I can't imagine there could be a standard set of exercises that would naturally introduce OO features of a programming language to everybody. A lot of the introductory OO tutorials are full of Animals, Cats, and Dogs which does not really cut it for me at least. Find a problem domain in OO you've struggled with a lot, and try to use that as your set of stock exercises for each language you pick up.
The OO constructs that we are used to thinking in terms of may not make sense in a language. Javascript comes to mind which shakes the entire foundation of how we think about objects in general. That said, you shouldn't adapt to a language but rather adapt the language for your purposes. Over time as your knowledge repository grows and improves with experience, you'll naturally want to implement what you think is best in each programming language that you use regardless of what the language offers.
Good question...
In my opinion the best teacher is just find a simple example of OO features and try to write something alone, creating new examples for Yourself and trying develop simple application in which You can connect all features of OO .
Implementing algorithm like merge sort which don't use OO feature, cause they don't need it is useless. Try real useful programs.
I remember when learning OO i write application with general "Animal" interface with methods and class which inherit it, like "amphibian". it was fanny time ;)
Some fun: implement the Shape/Circle/Ellipse hierarchy without falling into the trap (it can be done very nicely in Java, Scala, etc.).
edit implement it before looking at the proposed solutions in the Wikipedia article :)
I've used Hunt The Wumpus. The original implementation in BASIC was not at all OO, but if you start fresh it lends itself pretty nicely to this.
Here's what I use:
http://homepage.mac.com/s_lott/books/oodesign.html
I've done it enough times that it's "standard" in my opinion.
This might be too specific, but it's what I credit for really getting me to understand OOP personally. For my work I had to write code to extract data from a large variety of different sources. It seemed straightforward to me at the time that I should tackle the problem from the perspective of designing various "DataProvider" classes. What only gradually became clear was how much code I could reuse by breaking the different kinds of providers down into hierarchical categories, like this:
DataProvider
TextDataProvider
HtmlDataProvider
CsvDataProvider
XmlDataProvider
BinaryDataProvider
...and so on. I would suggest that any problem like this--where you need to accomplish a certain kind of task (in my case, extracting data) in a bunch of different ways (e.g., from multiple sources)--will be a great opportunity to delve into OOP and hopefully learn to appreciate how useful it is.
I personally find the best way to learn OO, is to write your own testing framework.
I find a layout of a Test Runner, owning one or more Test Suites, which each have their own Test Cases enough of a starting point, but you can easily grow it from there, and it might even be something you care to use in the future.
Alternatively, if you want something completely throw away, there's always Enterprise FizzBuzz. :)