I'm new to programming and I've been wondering what is the difference between ORM - Object–relational mapping and OOP - Object-oriented programming
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.
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:)
As per my knowledge, Objective-C is an Object oriented programming languge and Categories is a feature provided by Objective-C.
So I would like to know that Category feature is coming under which OOPs concept
Abstraction
Polymorphism
Encapsulation
Inheritance, etc.
Thanks in advance.
Mrunal
#Abizern's answer is good. I would add that categories are a form of dynamic dispatch, in particular that they can be used to extend existing classes without subclassing.
That said, Object Oriented Programming is more a design philosophy than a set of language features. One might ask "what OOP feature does postfix increment correspond to?" The answer is "none; it's a language feature." Categories are not primarily used to implement OOP design (though sometimes they are, as noted above). Their original use was to break up large implementation files. Their later use was to provide informal protocols due to a flaw in the language (lack of #optional). And today, they're primarily used to split code along platform-specific lines (NSString+UIStringDrawing vs NSString+AppKitAdditions).
Extensions are similar to categories, and similarly are primarily a language feature rather than an OOP design feature. They facilitate encapsulation to some extent, but mostly are a side-effect of an arbitrary compiler requirement to define methods before they are used (I say "arbitrary" because this is not related to design or developer needs; it just simplifies the compiler). Extensions should not be confused with some deep OOP requirement.
So using categories to attach additional functionality at runtime is dynamic dispatch. Beyond that, it's just a language feature that's used for several non-OOP things.
According to the Cocoa Design Patterns book by Buck and Yacktman. Category is a pattern in itself, and one that is supported by the Objective-C programming language directly.
Probably closest to Encapsulation, when it comes to academic OOP concepts. But this really shows the difference between academic definitions of OOP, and the practical world of OOP Design Patterns.
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.