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).
Related
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.
My understanding of "factory-related" design patterns and their OOP-implementations has always been pretty simple.
A "Factory method" is a method inside a class that has an interface (or an abstract class) as a return type and constructs objects implementing this interface based on some internal logic.
A "Factory" is a class that only contains factory methods
An "Abstract factory" is an interface (or an abstract class) that only contains factory methods
But I recently stumbled upon Wikipeda articles on the subject (Factory, Abstract factory) that made me somewhat confused, especially about what a "Factory" is in OOP.
Here are several quotes:
A subroutine that returns a "new" object may be referred to as a "factory", as in factory method or factory function.
Factories are used in various design patterns
The "Abstract factory pattern" is a method to build collections of factories.
A factory is the location of a concrete class in the code at which objects are constructed
which arouse some questions:
(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?
(2) Is "Factory" not a pattern itself?
(3) What does "collection" mean here? Is it just a way of saying "you can have several factories that implement the same interface (which is an abstract factory)"?
(4) What???
Can anyone clarify what this means? Is my initial understanding of factories incorrect?
Look at this wiki which says:
In object-oriented programming (OOP), a factory is an object for
creating other objects – formally a factory is a function or method
that returns objects of a varying prototype or class from some
method call, which is assumed to be "new".[a] More broadly, a
subroutine that returns a "new" object may be referred to as a
"factory", as in factory method or factory function. This is a basic
concept in OOP, and forms the basis for a number of related software
design patterns.
So to answer your questions specifically:
(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?
No, it means that you can create other objects using an object(factory).
(2) Is "Factory" not a pattern itself?
There are different design patterns out of which factory pattern is one. So when you are creating objects using a factory then that patter of creating other objects is "Factory pattern"
I think you generally have it right. But, people don't like general, so it's the specifics where things go pear-shaped.
There a few things to consider:
Wikipedia is sometimes woefully bad on technical subjects because they are trying to get to a single answer where different domains or programming languages may use the terms slightly differently. Not only that, many people are not skilled at technical writing and forget that Wikipedia is for the masses, not a graduate-level computer science theory class. As such, they tend to overly focus on minutiae or use language more complicated than necessary. So, don't worry about Wikipedia. And, although there is an edit history, no real names tend to be attached to these and no one really cares who wrote which words, so no one is that motivated to do that well. Having expressed that quite cynical opinion of the whole endeavor, reading the Talk pages are very interesting, in a Cunningham's Law sort of way.
(2) The name "Factory" is a pattern, but remember that patterns are general ideas, not implementations. Different languages may employ the same idea in different ways, and those different ways may not agree. A particular language or community starts to use the term in the way most meaningful to them, however, despite what anyone else thinks. That idea may show up in bare, procedural logic; classes; objects; or whatever the tool provides.
Design Patterns (the book(s)) are generally describing shortcomings in tools. They also aren't really design patterns in the way the authors think they are. Mark Jason Dominus has a wonderful talk on this, "Design Patterns" Aren't. His basic idea is that the Gang of Four misunderstand Christopher Alexander in that they (accidentally) prescribe solutions rather than promote the idea of a locally-relevant architectural language. So, the Gang of Four patterns become reified in languages almost exactly as the described single possible solution. Readers then force those patterns as a globally-relevant language completely disconnected from what you personally are trying to build, then argue about what it all really means out of any sort of context using extremely ill-suited examples that don't matter to what anyone is trying to build. There's no reason your recommendation engine and someone's first person shooter should have the same architectural language other than your tool forcing it on both of you. FWIW, paying attention to Mark Jason Dominus is a very good professional development move. His Higher-Order Perl is one of the best programming language books I've read and certainly better than anything I've written. He knows a lot of different languages (and languages that are very different) and thinks very deeply about things.
In (3), the term "collection" is unfortunate because we tend to use that to mean a set of things that co-exist at a particular time in the same container (box, book, whatever). I think they are trying to suggest that the abstract factory is a template for future factories that cannot be presently enumerated, which is a fancy way of saying that we can use it to build factories we don't even know about yet.
In (4), the term "location" is unfortunate. An abstract factory is a way of producing concrete factories, which is a way of producing objects.
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".
The creator of the Clojure language claims that "open, and large, set of functions operate upon an open, and small, set of extensible abstractions is the key to algorithmic reuse and library interoperability". Obviously it contradicts the typical OOP approach where you create a lot of abstractions (classes) and a relatively small set of functions operating on them. Please suggest a book, a chapter in a book, an article, or your personal experience that elaborate on the topics:
motivating examples of problems that appear in OOP and how using "many functions upon few abstractions" would address them
how to effectively do MFUFA* design
how to refactor OOP code towards MFUFA
how OOP languages' syntax gets in the way of MFUFA
*MFUFA: "many functions upon few abstractions"
There are two main notions of "abstraction" in programming:
parameterisation ("polymorphism", genericity).
encapsulation (data hiding),
[Edit: These two are duals. The first is client-side abstraction, the second implementer-side abstraction (and in case you care about these things: in terms of formal logic or type theory, they correspond to universal and existential quantification, respectively).]
In OO, the class is the kitchen sink feature for achieving both kinds of abstraction.
Ad (1), for almost every "pattern" you need to define a custom class (or several). In functional programming on the other hand, you often have more lightweight and direct methods to achieve the same goals, in particular, functions and tuples. It is often pointed out that most of the "design patterns" from the GoF are redundant in FP, for example.
Ad (2), encapsulation is needed a little bit less often if you don't have mutable state lingering around everywhere that you need to keep in check. You still build ADTs in FP, but they tend to be simpler and more generic, and hence you need fewer of them.
When you write program in object-oriented style, you make emphasis on expressing domain area in terms of data types. And at first glance this looks like a good idea - if we work with users, why not to have a class User? And if users sell and buy cars, why not to have class Car? This way we can easily maintain data and control flow - it just reflects order of events in the real world. While this is quite convenient for domain objects, for many internal objects (i.e. objects that do not reflect anything from real world, but occur only in program logic) it is not so good. Maybe the best example is a number of collection types in Java. In Java (and many other OOP languages) there are both arrays, Lists. In JDBC there's ResultSet which is also kind of collection, but doesn't implement Collection interface. For input you will often use InputStream that provides interface for sequential access to the data - just like linked list! However it doesn't implement any kind of collection interface as well. Thus, if your code works with database and uses ResultSet it will be harder to refactor it for text files and InputStream.
MFUFA principle teaches us to pay less attention to type definition and more to common abstractions. For this reason Clojure introduces single abstraction for all mentioned types - sequence. Any iterable is automatically coerced to sequence, streams are just lazy lists and result set may be transformed to one of previous types easily.
Another example is using PersistentMap interface for structs and records. With such common interfaces it becomes very easy to create resusable subroutines and do not spend lots of time to refactoring.
To summarize and answer your questions:
One simple example of an issue that appears in OOP frequently: reading data from many different sources (e.g. DB, file, network, etc.) and processing it in the same way.
To make good MFUFA design try to make abstractions as common as possible and avoid ad-hoc implementations. E.g. avoid types a-la UserList - List<User> is good enough in most cases.
Follow suggestions from point 2. In addition, try to add as much interfaces to your data types (classes) as it possible. For example, if you really need to have UserList (e.g. when it should have a lot of additional functionality), add both List and Iterable interfaces to its definition.
OOP (at least in Java and C#) is not very well suited for this principle, because they try to encapsulate the whole object's behavior during initial design, so it becomes hard add more functions to them. In most cases you can extend class in question and put methods you need into new object, but 1) if somebody else implements their own derived class, it will not be compatible with yours; 2) sometimes classes are final or all fields are made private, so derived classes don't have access to them (e.g. to add new functions to class String one should implement additional classStringUtils). Nevertheless, rules I described above make it much easier to use MFUFA in OOP-code. And best example here is Clojure itself, which is gracefully implemented in OO-style but still follows MFUFA principle.
UPD. I remember another description of difference between object oriented and functional styles, that maybe summarizes better all I said above: designing program in OO style is thinking in terms of data types (nouns), while designing in functional style is thinking in terms of operations (verbs). You may forget that some nouns are similar (e.g. forget about inheritance), but you should always remember that many verbs in practice do the same thing (e.g. have same or similar interfaces).
A much earlier version of the quote:
"The simple structure and natural applicability of lists are reflected in functions that are amazingly nonidiosyncratic. In Pascal the plethora of declarable data structures induces a specialization within functions that inhibits and penalizes casual cooperation. It is better to have 100 functions operate on one data structure than to have 10 functions operate on 10 data structures."
...comes from the foreword to the famous SICP book. I believe this book has a lot of applicable material on this topic.
I think you're not getting that there's a difference between libraries and programmes.
OO libraries which work well usually generate a small number of abstractions, which programmes use to build the abstractions for their domain. Larger OO libraries (and programmes) use inheritance to create different versions of methods and introduce new methods.
So, yes, the same principle applies to OO libraries.