I have recently finished reading Clean Architecture book by Unckle Bob.
There he wrote
Three paradigms. Three constraints. Structured Programming imposes
discipline on direct transfer of control. Object Oriented Programming
imposes discipline on indirect transfer of control. Functional
programming imposes discipline upon assignment. Each of these
paradigms took something away. None of them added any new capability.
Each increased discipline and decreased capability.
What does indirect transfer of control mean?
How it is restricted in OOP?
What does indirect transfer of control mean?
Pointers to functions.
How it is restricted in OOP?
Polymorphism.
A more complete explanation can be found on the bottom of page 42.
The bottom line is that polymorphism is an application of pointers to functions. Programmers have been using pointers to functions to achieve polymorphic behavior since... the late 1940s.
The problem with explicitly using pointers to functions to create polymorphic behavior is that pointers to functions are dangerous. Such use is driven by a set of manual conventions. You have to remember to follow the convention...
OO languages eliminate these conventions and, therefore, these dangers. Using an OO language makes polymorphism trivial. That fact provides an enormous power... On this basis, we can conclude that OO imposes discipline on indirect transfer of control.
The discipline imposed in OO is that pointers to functions are accessed exclusively through polymorphism and never used explicitly.
Related
I've recently stumbled upon interesting question (or maybe only author's mistake) and I've started to question myself. After some research I have to say I am not 100% sure of my answer, so I would like to ask if my thinking is correct. The question is:
Describe object oriented programming paradigms
I was first thinking that this is polymorphism, inheritance, encapsulation, abstraction. But why there is multiple form? As I understood my answer is description of paradigm (single) not paradigms (plural). Did I miss something, or this is correct answer?
Basing my argument on definition of paradigm which is generally a pattern of doing something. The paradigms would be:
Abstraction
Encapsulation
Polymorphism
Inheritance.
You might want to check out what Alan Kay has to say about this: http://c2.com/cgi/wiki?AlanKaysDefinitionOfObjectOriented
The necessary excerpts from the link:
This definition is derived from early versions of Smalltalk (Smalltalk-72?), and rules 5 and 6 clearly show Smalltalk's Lisp heritage. Kay remarked as such, noting that rules 4-6 would mutate as Smalltalk developed.
EverythingIsAnObject.
Objects communicate by sending and receiving messages (in terms of objects).
Objects have their own memory (in terms of objects).
Every object is an instance of a class (which must be an object).
The class holds the shared behavior for its instances (in the form of objects in a program list)
To eval a program list, control is passed to the first object and the remainder is treated as its message.
"Alan Kay, considered by some to be the father of object-oriented programming, identified the following characteristics as fundamental to OOP:"
EverythingIsAnObject.
Communication is performed by objects communicating with each other, requesting that objects perform actions. Objects communicate by sending and receiving messages. A message is a request for action, bundled with whatever objects may be necessary to complete the task.
Objects have their own memory, which consists of other objects.
Every object is an instance of a class. A class simply represents a grouping of similar objects, such as integers or lists.
The class is the repository for behavior associated with an object. That is, all objects that are instances of the same class can perform the same actions.
So far, similar to 1-5 above. Rule 6 is different. The reference to lists is removed, instead we have:
Classes are organized into a singly-rooted tree structure, called the inheritance hierarchy. Memory and behavior associated with instances of a class are available to any class associated with a descendent in this tree structure.
It depends on the viewing angle, better to say on the granularity, or what do you want to compare or emphasize.
Object oriented programming is one programming paradigm among others. But then there are different categories of object oriented programming. It makes sense to call the plurality of them object oriented programming paradigms.
See https://en.wikipedia.org/wiki/Object-oriented_programming for a beautiful list of programming paradigms.
OOP has its roots in the late 1960s and early 1970s, and it was formally introduced in the late 1980s. The main proponents of OOP were Alan Kay, Bertrand Meyer, and Grady Booch.
The idea behind OOP is to represent real-world objects and their behavior in a computer program. This allows developers to write software that is more intuitive and easier to understand, as well as reuse code by creating objects that can be used in multiple applications.
Object-Oriented Programming (OOP) is a programming paradigm based on the concept of objects, which can contain data and behavior. In OOP, objects interact with each other by sending messages, and objects can be grouped into classes, which define their shared behavior and data.
OOP has evolved over time, and its use has become widespread in the software industry. Today, several programming languages support OOP, including PHP, Java, Python, C++, Ruby, and more.
You can read further in this post: What is OOP - Object Oriented Programming
I've read the other posts discussing abstraction and encapsulation, but I'm not confident I understand them; or maybe I understand them but feel unsatisfied with the clarity of their content. Here are my understandings of abstraction and encapsulation. In what regards are they accurate/inaccurate/complete/incomplete?
"Abstractions are data types created by programmers to extend a language when primitive data types are insufficient. Like primitive data types, abstractions have specifications which list the inputs they require and the outputs they return, but the specifications do not overwhelm programmers with the methods, functions, and variables used to operate on the inputs. A class is an example of an abstraction. An API is another example of an abstraction."
"Encapsulation is the state of having abstract data types — i.e. classes — isolated from each other so their methods, functions, and variables do not conflict with each other, and so programmers can easily reuse an existing class in other programs without being concerned that doing so would interfere with the rest of the program (presuming the programmer correctly provides the required inputs and correctly handles the data that get returns)."
I prefer Robert C. Martin's definition in APPP:
Abstraction is the elimination of the irrelevant and the amplification of the essential.
I'd say your understanding is correct ... so much, so, that I hesitate to comment more specifically.
However, if I were to comment, I might say that "Data types can be used to implement abstractions ...", rather than "Abstractions are data types ...", since abstractions can exist outside of software (it hurt me to say that :-).
But that's just nitpicking. I think you understand. I hope I do, after 36 years of coding ... mostly in languages that support reasonable levels of abstraction (PL/1, Pascal, C, C++, Java).
There are a lot of nice intelligent people in industry, though, who have no concept of abstraction in software, and consider it pretentiously high brow.
Personally, I think that good clear misnomer-free abstraction is a key technical ingredient of solid software engineering.
I've never come across that definition of encapsulation before. That definition sounds more like what namespaces are for. I've always read about encapsulation being purely about the ability to restrict access to certain components of your code, such as access modifiers in OOP languages. However, there seems to be a two definitions of encapsulation on wikipedia, which is news to me:
Encapsulation is the packing of data and functions into a single
component. The features of encapsulation are supported using classes
in most object-oriented programming languages, although other
alternatives also exist. It allows selective hiding of properties and
methods in an object by building an impenetrable wall to protect the
code from accidental corruption.
In programming languages, encapsulation is used to refer to one of two
related but distinct notions, and sometimes to the combination
thereof:
A language mechanism for restricting access to some of the object's
components.
A language construct that facilitates the bundling
of data with the methods (or other functions) operating on that
data.
Some programming language researchers and academics use
the first meaning alone or in combination with the second as a
distinguishing feature of object-oriented programming, while other
programming languages which provide lexical closures view
encapsulation as a feature of the language orthogonal to object
orientation.
The second definition is motivated by the fact that in many OOP
languages hiding of components is not automatic or can be overridden;
thus, information hiding is defined as a separate notion by those who
prefer the second definition.
source
So, I guess I've always defined encapsulation in terms of point #1, but it looks like some people define it as the ability to bundle methods and data together, and term #1 "information hiding".
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.
What makes everyone went from sequential languages to object languages ?
According to Wikipedia the features of object oriented programming are data abstraction, encapsulation, messaging, modularity, polymorphism, and inheritance. For me data abstraction, encapsulation, messaging, modularity also exist in sequential languages. Only the polymorphism, and inheritance are specific to object oriented programming. Is this correct ?
Many non-OOP languages can certainly build those features. Just looking from a C vs. C++ area, you can provide encapsulation in C by using opaque pointers, with a suite of functions that take/return these opaque objects, and an internal set of functions that are all file-static. You can even do polymorphism and inheritance with function pointers and encapsulated objects.
Then again, we could also all still be programming in assembly or machine language. The reason to bring any feature into a language is to make it easier to use that feature.
Again, looking at C vs. C++, dealing with opaque pointers and the like is annoying, repetitive, and semi-difficult. With C++, you can achieve the same effect with much less code. It's obvious to everyone what is going on. It's a lot more difficult to break (though not impossible). Plus, you make it easy to break encapsulation if you need, since you can define language constructs like friend that provide exceptions where necessary.
And then there are those things that are really hard to implement without direct language support. Operator overloading is impossible of course, but function overloading is really, really hard to do without language support.
Most important of all, if it's in the language, then everyone does it the same way. There are multiple ways of implementing inheritance and polymorphism in C. All of them are incompatible with one another. And while C++ users could do any of those methods, they opt to use the actual language feature 99.9% of the time. This means it's much easier to read someone else's code and know what's going on. You don't have to guess what is opaque and what isn't. You don't have to guess at what is derived from what. You know it, since everyone does it the same way.
In any case, most of the OOP-lite language (C++, Java, C#) can be used more or less like a procedural one if you want. You just ignore the objects. So in many ways, they get the best of both worlds.
The advantage can be summarized this way:
OOP can represent the real world more directly and precisely than previous paradigms, so the program becomes simpler and easier to understand.
And about this:
For me data abstraction, encapsulation, messaging, modularity also exist in sequential languages. Only the polymorphism, and inheritance are specific to object oriented programming.
Most human-readable language can provide data abstraction, encapsulation, messaging and modularity (otherwise they would be machine-languages), but OOP supports better these concepts. For example, to set text of a widget in C, you would do something like this:
HANDLE myEditBox = CreateEditBox(hParent, ...);
SetText(myEditBox, "Hello!");
Notice you have a handle to an object, not an actual object. Now in C++ (OOP) you can make this:
EditBox myEditBox(...);
myEditBox.SetText("Hello!");
The difference is subtle, but important. The C style SetText(handle, "Hello!") does not make any distinction between the handle and other parameters. You don't even know that there's a message to the object. Now the C++ style object.SetText("Hello!") it's like telling explicitly: Hey, object, set your text to "Hello!". Here, the notion of message and receiver (the object) are explicit.
C++ can also destroy objects automatically if they are not declared as pointers, which eliminates calls such as DestroyObject(myEditBox).
Also without OOP you have very poor encapsulation, because most things are implemented with structures which contains only public members. So you can't hide data from users, which mean somenone might try to change things in an unexpected way, that may cause bugs. This is quite common in large programs.
If you have watched Going Deep shows of the Channel9 lately, one very frequently mentioned topic is mathematical duality in programming. TomasP has a good blog post about duality in object oriented programming.
This has been since Microsoft Research found that the observer design pattern is actually a mathematical dual of the iterator pattern. Since then they have used the duality concept in various ways.
My question is:
What mathematical dualities are there in programming?
Object oriented programming is a good start. The major GoF design patterns are: Decorator, State, Iterator, Facade, Strategy, Proxy, Factory Method, Adapter, Observer, Template Method, Composite, Singleton, Abstract Factory and Command. Here is a good object-graph-poster.
I'd say the primary duality in programming is the code-data duality, most clearly exposed in Lisp, but also clear in most contemporary languages which provide introspection functionality.
Not sure if it is entirely what you were looking for, as it's more FP than OO, but there is of course the Curry-Howard Correspondance (a.k.a. Curry-Howard Isomorphism) that "equates" programs with proofs and types with formulae.
You could argue that the duality of observer/iterator is (sort of, work with me here :-) ) a manifestation of the more general OO paradigms of inheritence and the alternate paradigm of delegation and aggregation. In the former, more specialized objects use base functionality (point up) to inherit general capabilities and in the latter, more generalized objects use delegation to access more specialized functionality (point down/out) - there is much academic discussion about the fact that oo designs can be expressed in either form, and since the variance between forms is (reasonably) rigourous and defined, I'd say it could be classified as a dual
See Treaty of Orlando 2 for more info
I think of objects and closures/anonymous functions as duals.
An object is a bunch of data, with a set of routines that are "attached" to it (i.e. its methods).
A closure, in the functional-programming sense of the word, is a (callable) reference to a function, with a set of data attached (in the form of its bound free variables).