What is the difference between structured programming and object oriented programming?
Structured COBOL programming is top-down approach whereas Object Oriented COBOL programming is bottom-up approach
Another Example of Objected oriented is Java
Hope it helps:)
Related
Does OOP mean that the paradigm is around ADTs, since ADTs are the base of objects? If so, if ADTs are used procedurally, what does this make the procedural code?
I am not sure I totally understand your question, but even so, ADTs predate OOP direct support in languages (or language compilers). This usually means that you can(could) emulate OOP support, when it does(did) not exist(ed), by manipulating ADTs and following certain conventions your respect (yourself, not forced by the compiler). If you do that, you are writing code in object-oriented style, although only using available procedural mechanisms.
In DCI discussions, there is a usually mention of pure object oriented languages:
Object-oriented programming languages—particularly the "pure"
ones—expressed everything in terms of objects or methods on objects.
(Of course, most programming languages used classes to do this.
The point is that nothing was supposed to exist outside of an object framework.)
Source: http://www.artima.com/articles/dci_vision.html
I'm trying to understand the difference between a pure OO language and a non-pure one in terms of DCI. To help put the differences into context, it would be good to have an example of a pure OO language so that I can contrast it with my experience with class based language such as java.
Question: What languages are pure OO languages (from the perspective of DCI)?
A non-pure OO language in this context is a language were not everything is objects. Java for example have "primitive" types, which behave differently than objects. For example, Java's primitive types are passed by value, while Java passes references when it passes it's objects.
In contrast, Python treats everything as objects, and although it has built-in types, it has no primitive types, everything is objects.
I think you misunderstand the reference to classes. I don't think they say that a pure OO language does not have classes.
I keep reading that object-oriented programming can basically be done in any programming language, and that in order to do so, explicit language support is not required. I.e. one can write object-oriented programs in, say, plain C.
What good examples of OO design using a procedural language are there, apart from GTK+?
Which open source projects are good examples of procedural design, on the other hand? (preferably C)
In C, OO programming usually takes the form of calling particular initialization and cleanup functions on struct pointers, and for polymorphism, passing around structs of function pointers. One example I can think of offhand is KVM.
well i am having lots of question regarding to the desired topic,well its better to be short here.
1> C# is object oriented or object based
2> java is object oriented or object based
as per my knowledge c# is object oriented and java is object based,if it is true then what makes java to be oriented not object oriented.
Object based programming paradigm makes use of all the features of object oriented programming except for inheritance. For example JavaScript is object based whereas Java is object oriented.
Although it is common to use these two terms mutually exclusively, practically speaking, an object oriented language is also object based but not vice versa.
Both C# and Java are object-oriented languages.
Generally, a language is regarded as "object-based" when it lacks support for certain central features of a truly object-oriented language, namely inheritance and polymorphism. A good example of an object-based language is VB 6 (the pre-.NET version). It was based on objects, but it did not support either inheritance or polymorphism, making it impossible to regard as a truly object-oriented language.
What is the difference between Object-Oriented Modeling and Object-Oriented Programming? I overheard a conversation on my subway train this morning and it seems that these things are different. Aren't they?
Object-Oriented Modeling refers to the process where you are designing how the code will look like. You will use a modeling language like UML to do Object-Oriented Modeling. Object-Oriented Programming refers to a programming paradigm where you use objects. These objects have been designed during the desing phase using Object-Oriented Modeling techniques, and they are implemented during the construction (programming phase) using a language that supports Object-Oriented programming and based on the model.
Modeling is creating an abstraction of a problem, where as programming is the implementation of such an abstraction.
Modeling can be done in many ways: textual, formulas, diagrams... UML is one standard of modeling object oriented concepts.
Programming can be done in different ways too, depending on the tool, language etc. There are ways to generate the program right out of the modeling tool, typically out of UML models. This goes even a step further, where UML models are "executed" directly.
Other common confusions about object-oriented programming exist too - starting from "it's the thing where your drag and click", over hybrid 3rd generation concepts I refer to as "processing Objects" to practical patterns and ending with pure OOP.
I'd say the modeling precludes the programing, where the modeling is the physical design, before the programming is implemented.
http://en.wikipedia.org/wiki/Object-Oriented_Modeling
http://en.wikipedia.org/wiki/Object_oriented_programming
I just found this:
Object-oriented modeling is a formal
way of representing something in the
real world. It draws from traditional
set theory and classification theory.
object-oriented modeling is not
limited to computer-related elements.
One may use object-oriented modeling
to represent many different types of
things, from organizational
structures, to organic materials, to
physical buildings.
Object-Oriented Modeling is used to define, usually without any actual code, the classes, methods, and variables. There are many tools out there to help with such modelling. Netbeans is one such package. Netbeans can help you model your code and will even attempt to help you get started after you make your class diagrams.
I found this extraction is from the DTMF website about Key concepts of object oriented modeling.
Abstraction: DENotes the essential
characteristics of an object that
distinguish it from all other kinds of
objects and thus provide crisply
defined conceptual boundaries.
Example: A Cheesburger - is good to
eat and fun to cook.
Modularity: Decomposition of
abstractions into discrete units.
Example: The various "layers" of a
cheesburger - the bun, the lettuce,
the ketchup, the mayonnaise, the
burger, the cheese, onions, pickels,
etc.
Encapsulation: Process of
compartmentalizing the elements of an
abstraction that constitute its
structure and behavior; encapsulation
serves to separate the interface of an
abstraction and its implementation.
Example: • To cook the cheeseburger:
- Is the stove available? Are the burners working? Are the ingredients
available? • To eat the
cheeseburger: - Is it made correctly?
Is my plate clean or disgusting?
Hierarchy: A ranking or ordering of
abstractions. Example: A
cheeseburger is really a subclass of a
hamburger with cheese added which is a
sub class of sandwich which is a
subclass of the Hierarchal superclass
food.
Key Elements: Classes – A collection
of definitions of state, behavior,
and/or identity • Properties •
Methods
Objects: Instances of a class
Associations: Relationships •
Dependency • Identity •
Aggregation • Composition • And
others
Well, given that code is a means of communicating, object-oriented programming in an object-oriented programming language is a form of modelling.
One can however model at a more abstract level using modelling languages that are less expressive, but perhaps more useful for other purposes. For the purposes of developing software, modelling not relatively closely tied to programmes is mainly an exercise for a certain class of person who thinks it is terribly important, and is paid as if it were, but it is not.