I'm looking for some visuals for a presentation to illustrate the principles of oop in a simple-to-grasp way.
I want to avoid saying stuff like "an object is a software bundle of related state and behavior".
Has anyone seen a non-jargon-y illustrated guide to OOP?
O'Reilly's book Head First Object-Oriented Analysis and Design may fullfil your needs
The illustrations in Grady Booch's book Object Oriented Analysis & Design with Applications are pretty good , and quite funny!
Well, I just thought of cars as an example of OO design. There's a fixed interface: accelerator, brake, clutch, steering wheel, gears, lights, indicators and so on. There's also different implementations of the underlying 'object': petrol, hybrid, electric. Inheritance - manual transmission inherits from automatic transmission but adds a gear lever and clutch.
Related
So there is this "modular" paradigm which (depending on the perspective) goes even above OOP itself. You can write an un-modular OOP piece of software, so to speak. I have read the wikipedia article of course and the "Objects as modules" chapter of the stairways book (its about Scala, by Martin Odersky), I also read the modules section of the wikipedia's LM article, but I still can't get a clear understanding of what exactly is it that a modular design provides.
I think I understand the reason behind it in an abstract form: it provides a kind of separation of concern that is orthogonal to the partitioning mechanisms of the underlying language and even the programming paradigm (say OOP). But I don't quite get how exactly this is achieved. What is it about modules that is not captured by the classes, interfaces or libraries? I feel like I'm missing some big-picture, architectural point here.
Disclaimer: perhaps here is not the right place or perhaps the question itself is vague or even philosophical in nature.
I've recently forayed into the world of functional programming (FP) and am wondering how to "think functionally" for even moderately sized applications? Especially w.r.t. the analysis and design of FPs.
With OOP we're trained to think in terms of objects, their attributes and relations. We model our analyses/designs using class and sequence diagrams. However, the same models seem to be a bad fit when designing for FPs. What are the equivalent modeling paradigms for functional programming? It seems DFDs maybe a good fit but I maybe wrong.
For example: I was thinking of designing a simulation of Monopoly, the board game using Haskell, just to learn the language. When doing OOAD you come up with classes like board contains items that have attributes/methods attached to it. You have player and various other objects and their associated relations that can be captured in a class diagram. And their interactions in a sequence diagram. However, these modeling paradigms doesn't seem to transfer well for functional programs. So just "how" do you model functionally?
Note: I'm looking for concrete references/examples that can explain how to analyze and design functional programs given that I'm coming from a heavily object-oriented way of thinking/modeling.
According to Simon Peyton Jones:
The language in which you write profoundly affects the design of
programs written in that language. For example, in the OO world, many
people use UML to sketch a design. In Haskell or ML, one writes type
signatures instead. Much of the initial design phase of a functional
program consists of writing type definitions. Unlike UML, though, all
this design is incorporated in the final product, and is
machine-checked throughout.
Source: Masterminds of Programming
So instead of drawing all the fancy UML diagrams, you actually write type definitions coupled with undefined in the design phase.
All of my programming these days consists of single-person projects. If I were collaborating on a project with other programmers, I think that writing type definitions and using undefined would be a good approach.
But I gather what you're really looking for is some advice about how you can learn to think functionally. So here are some thoughts.
When programming in Haskell, there are two ways I think about the program I'm writing.
If the program is mathematical, I think of the program as a set of equations.
Otherwise, I tend to think of the program as one or more chains of of data transformations. (So perhaps DFDs would be useful.)
So in your Monopoly example, my first thought would be to figure out how I'm going to represent the state of the board (e.g., which properties have houses, who owns them). Then I might have a function that transforms the board when someone buys a property, and other functions for other things players might do. (There's also monads for representing state, State and StateT. I might use them, if and when I feel they will make the code clearer, but I usually keep things basic to start.)
One of the mistakes I made most often as a beginner was to create a lot of unnecessary classes and data types.
Short answer: composition of smaller programs.
You first study the problem before you, then you develop a set of small operations (often in the form of combinators) that you reckon make sense in that problem's context, and finally you build the solution around those operations. I'm under the impression that all packages found on Hackage follow this approach.
In this way the final solution is (more often than not) simple, clear and elegant. As you can appreciate the aforementioned set of small operations you choose for your solution is critical; with practice, you'll develop the sensibility to pick it wisely.
My book suggestion is Pearls of Functional Algorithm Design, by Richard Bird, Google Books (preview). In this book you'll learn about the calculational approach to functional programming, which I think is most valuable.
Two books you might be interested in:
Structure and Interpretation of Computer Programs - a classic intro to CS textbook in Scheme. I think it's a must for programmers interested in FP.
How to Design Programs - similar to SICP, slightly more modern and focuses on design. The language of choice here is Racket.
If you want a hands-on project in Haskell, I'd recommend Write Yourself a Scheme in 48 Hours, a wonderful tutorial for implementing an interpreter for Scheme. AST manipulation is where FP (and especially Haskell) shines, so I think writing an interpreter is a good experience for new FP programmers.
My perspective regarding the FP vs OO analysis and design debate is the following:
OOAD and DDD (Domain-Driven Design) are very useful tools for software systems decomposition;
FP has types, OO has classes and interfaces: they are dual in different worlds;
FP has type instances, OO has class instances (aka, objects in OO);
Use composition in FP, where in OO you would use inheritance;
Both FP and OO languages come with polymorphic constructs;
Both FP and OO use collections (sets, lists and maps) to make connections between instances (of types in FP, and of classes in OO);
Associations in FP are typically implemented as collections of instance IDs, whereas absensein OO they are implemented as collections of references to the memory locations of objects. This comes from the immutability property of data structures in FP.
Most books in FP, like those referred in the other answers before mine, do not show you how to design (aka, decompose) complex real-world problems. They generally demonstrate FP's features with very short examples (e.g., compare them with the examples in Craig Larman's Applying UML and Patterns excelent book, and judge yourself).
For something more close to what could be called Functional-Oriented Analysis and Design (FOAD), I recommend these:
Elixir in Action
Domain Modeling Made Functional: Tackle Software Complexity with Domain-Driven Design and F#
Functional and Reactive Domain Modeling
Functional Programming in Scala
DDD, OOAD, and FOAD, can be implemented in any programming language, however some programming languages offer constructs that make these approaches easier or harder to implement, but they are perfectly practical. This is evident by the many sources you can find discussing DDD in the context of FP.
Dr. Alan Kay said this regarding the essence of OOP (here):
OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things. It
can be done in Smalltalk and in LISP. There are possibly other systems
in which this is possible, but I'm not aware of them.
Following this statement, Joe Armstrong, one of Erlang's creator, an FP language with important uses in the industry (e.g., WhatsApp), argues that Erlang is perhaps the most OO language around (see this interview also featuring Ralph Johnson).
Also, some say that Erlang is the best language that captured the essence of OO programming: the passing of messages between objects.
Hope this was helpful.
I can only speak from the perspective of Erlang OTP. We think in terms of processes, which have a state and functions. So in the state the process will have all the "variables" and handler functions react to data the process receives in its message queue. They act on the received data, possibly alter their own state, possibly return some data and/or have some side effects. The state can be stored in a map or a record or any other valid data type. Usually we define a record called state() or loopData().
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I want to ask you to provide me with some articles (maybe books), which you possibly have found very convincing criticising the OOP methodology.
I have read some in the WWW on this topic and I didn't really find a 'definitive demotivator'.
It's not much about my personal attitude to the OOP, but I really would like to have something constructive, rigorous foundation for any kind of discussion and just abstract thinking.
You can post some original research too, but please be very constructive (as my personal request).
Which version of OOP? Alan Kay's original vision? The bastardized modern form of it that misses the point entirely and thus encumbers us with bizarre access control, member variables, etc? Inheritance-centric? Prototype-based? Compositional OOP?
Each form of OOP has its strengths and its weaknesses; its advocates and its detractors; its domains of utility and its domains of uselessness. There's nothing magical about OOP that makes it the Killer Paradigm and there's nothing infernal about it that makes it the Killer (of Programmers) Paradigm.
I can't really point you to any books or articles that killed my interest in OOP as a Silver Bullet (as opposed to one of many techniques I can use to keep my projects survivable). I can point to the funniest critique of a specific brand of OOP, however: Steve Yegge's classic "Execution in the Kingdom of Nouns".
Rick Hickey's Are We There Yet ? - A Deconstruction of Object Oriented Time was an eye opener for me. It's the most logical OO criticism I have come across.
If you want a criticism of OO programming, here's what I'd recommend:
Learn Smalltalk
Learn Erlang
Learn Scheme
Once you've done that, you will have plenty of criticism of the common interpretation of OO programming.
(Hint: OO was in many ways intended to more closely resemble the Actor model of computation, but the common interpretation of it is effectively a modification of the procedural/structured model)
Problem is - most people don't really know Object-Oriented Programming, so many designs SUCK.
Read the works of Scott Ambler, including his (now pretty old) Building Object Applications That Work. This has been eye-opening for quite a lot of people.
Maybe not quite what you were looking for but have a look at the Jan/Feb issue of IEEE Software magazine: Object-Oriented Analysis: Is It Just Theory?. The basic conclusion is that OOA does not provide a good cost/benefit ratio so is poorly utilized.
Given that OOA is not effectively utililzed or supported in the "real world", I suspect that for larger development projects the overall system architecture, deployed object model and class hiearchy end up being sub-optimal and poorly understood (implemented) by various parts of the development team. A second article in the same journal: Four Trends Leading to Java Runtime Bloat point to some common OOP issues that detract from deploying high-volume Java (OOP) systems. The observations made in this article probably apply to most highly architected OOP applications.
Do not take this as OO bashing, it just reflects that as software practictioners we have quite a bit of work to do toward developing better person-to-person communication mechanisms to convey highly complex and abstracted process models.
When you define a process in natural language. You use sentences where you define the subject who will do an action on one or more objects.
The only fix point is the action, the predicate of the sentence.
I don't think assigning actions to objects is a good idea.
There is only one verb, but can be multiple nouns.
In OOP you can write a file in at least 3 ways:
file.write(data);
or
data.writeToFile(file);
or
OperatingSystem.write(file, data);
Which object should implement the method? You need to think about this too.
While in the procedural way, you probably write
write(file, data);
And the only thing you need to think is the order of the operands which is usally does not matter.
(Well file and data may not be the best example but you probably see the point)
You should really see Mr. B. Jacobs's:
OOP Myths Debunked
(also known as OOP Oversold.)
http://cat-v.org has a great page on Object Oriented Programming.
Most of the page consists of humorous but not terribly informative quotes. However, at the bottom of the page are a number of links to articles challenging OOP. They are:
Bad Engineering Properties of Object-Oriented Languages by Luca Cardelli.
Why OO Sucks by Joe Armstrong
Pitfalls of Object Oriented Programming – By Tony Albrecht of Sony Computer Entertainment Europe, Research & Development Division.
Object-Oriented Considered Harmful by Frans Faase.
Object Oriented Programming Oversold!
I Hate Patterns – By Parand Tony Darugar.
Why arc Isn’t Particularly Object-Oriented – By Paul Graham.
The questions about inheritance in the Java IAQ.
Stop Writing Classes – Great talk about how classes are often used and abused. By Jack Diederich.
If you are interested in alternatives to Object-Oriented Programming:
cat-v.org. From their 'about' page: Cat-v.org hosts a series of sites dedicated to diverse subjects that share an idiosyncratic intellectual perspective, questioning orthodoxy and fomenting elitism and high standards in topics from software design to politics, passing by art and journalism and anything else interesting.
Structure and Interpretation of Computer Programs. Specifically teaches functional programming. Available free online here, for sale here. I cannot recommend this highly enough. It is absolutely revolutionary. It will change the way you think.
Any and all writings/videos/lectures by Rob Pike and Steve Yegge. Of particular interest is Yegge's Whirlwind Languages Tour.
I'd recommend learning a different programming paradigm or reading pro arguments for specific paradigms (http://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf). Besides OOP, I think the most widely used is the functional paradigm (search f.e. "Why functional programming matters"), but also have a look at the other ones. When you start looking at programming from a different perspective, the flaws of OOP start to appear automatically.
Simple exercise: define the objects IPerson, CMale and CFemale and implement the methods "sex" and "reproduce".
hows about steve yegge's execution in the kingdom of the noun
for java style OO
The Gideon Bible of object-oriented design patterns, aptly named Design Patterns. One of the best software design books I've ever read.
The team is familiar with ASP.NET and has been working in VB.NET for several years, but they just haven't made the transition in thinking in terms of objects. In fact, they may be a little intimidated by OOP from brief glimpses they've seen of C++ and unmanaged environments. Work has kept them busy enough that they haven't had time to properly absorb the benefits that .NET and OOP provides.
I'm looking for some lightweight resources (i.e.: blog posts, articles) that I can share with both developers and/or managers which would help to introduce the object oriented paradigm in a nicely presented fashon. The language could be in either C# or VB.NET, though VB.NET would be preferred.
Thanks!
Another approach that has worked spectacularly for me is to host an open-ended series of brown bag lunches. This is when you invite your coworkers (not demand) to a conference room where you discuss some aspect of OO.
Everyone brings their own lunch. And you can buy a pizza now and then to incent them to come, but you wouldn't do this every week.
Always have it the same place and the same time every week. You'll always talk briefly, no more than 30 minutes, leaving plenty of time for questions and discussion on how we use this in our company. Start on time and finish religiously on time.
Publish the schedule, emphasizing that they'll get the most out of it if they attend all sessions, but if they miss one, they can still catch on.
Here are some example topics:
OO for beginners.
Abstraction is the main thing; how to
get there.
Encapsulation 101
Why inheritance?
Top 5 things we should use
inheritance for here
Interfaces are way better than
inheritance.
What are Design Patterns?
... then drill down into the patterns
that you'd use in real life.
I'm telling you, if you make these things interesting, you'll be amazed at how quickly your people will come up to speed.
Then, the best followup in the world is to implement Pair Programming and Friendly Code Walkthroughs. If you don't do one or both of these, the lessons will likely not stick.
Head First Object-Oriented Programming from O'Reilly & Associates by McLaughlin, et al.
Here's a link for more: Head First OOAD
Great book. Great series. Easy to read and easy to grasp the concepts of OO, which is what you're after with your team.
(source: coverbrowser.com)
For OOP with VB...
Beginning Object-Oriented Programming with VB.Net
Object-Oriented Programming with Visual Basic .Net
Depending on how experienced one is you may want to also read about Object-Oriented Analysis and Design. These will help you to wrap your head around how to do it.
Head First Object-Oriented Analysis and Design
Object-Oriented Analysis and Design with Applications
MS article on OO in VB.Net:
http://msdn.microsoft.com/en-us/library/aa289512(VS.71).aspx
A little old but gives the basics....
It has been my experience that depending on how entrenched the team is on the event driven model will greatly influence how effective the team moves/embraces OO. It's easier than I would like to admit to just use objects in .Net and not really understand OO. Coming from VB6 it was too easy to keep on trucking the classic way. The OOA & OOD books may be a great starting point if your team seems to be just "users" of the objects in .Net versus actually creating classes in their own code.
I've worked with VB developers of varying skills before (mostly from a VB6 background). Design Patterns might already require too much abstract thinking on their part.
If they're pretty savvy with business requirements, can I suggest a 'Naked Objects' type approach? This approach let's everyone visualise objects, encapsulation, inheritance, relationships and composition, and can ease the initial pain of OOAD. And you can use concrete examples from your business, instead of contrived examples from a book.
It's a long road - best of luck!
P.S. If you're interested, I provide a tool that supports the Naked Object pattern.
Design Pattens
The book is actually pretty "lightweight" from the perspective of a single pattern.
I've worked with designing databases for a loooong time, and these days I'm working in C# too. OO makes sense to me, but I don't feel that I have a good grounding in the deep theory of OO design.
In database land, there's a lot of theory around how to design the structure of a database, the main notion being normalisation. Normalisation directly steers the structure of a database and to some extent dictates how to arrange entities in a database.
Are there any similar concepts behind how to design the structure of an Object-Oriented program?
What I'm reaching for is one or more underlying theoretical principles which naturally guide the developer into the "correct" design for the solution to a given problem.
Where can I look to find out more?
Is there a go-to work I should read?
Update:
Thanks to everyone for their answers.
What I'm reading seems to say that there is no "Grand Theory of OO Design", but there are a bunch of important principles - which are largely exemplified by design patterns.
Thanks again for your answers :)
Be careful some of the design patterns literature.
There are are several broad species of class definitions. Classes for persistent objects (which are like rows in relational tables) and collections (which are like the tables themselves) are one thing.
Some of the "Gang of Four" design patterns are more applicable to active, application objects, and less applicable to persistent objects. While you wrestle through something like Abstract Factory, you'll be missing some key points of OO design as it applies to persistent objects.
The Object Mentor What is Object-Oriented Design? page has mich of you really need to know to transition from relational design to OO design.
Normalization, BTW, isn't a blanket design principle that always applies to relational databases. Normalization applies when you have update transactions, to prevent update anomalies. It's a hack because relational databases are passive things; you either have to add processing (like methods in a class) or you have to pass a bunch of rules (normalization). In the data warehouse world, where updates are rare (or non-existent) that standard normalization rules aren't as relevant.
Consequently, there's no "normalize like this" for object data models.
In OO Design, perhaps the most important rule for designing persistent objects is the Single Responsibility Principle.
If you design your classes to have good fidelity to real-world objects, and you allocate responsibilities to those classes in a very focused way, you'll be happy with your object model. You'll be able to map it to a relational database with relatively few complexities.
Turns out, that when you look at things from a responsibility point of view, you find that 2NF and 3NF rules fit with sound responsibility assignment. Unique keys still matter. And derived data becomes the responsibility of a method function, not a persistent attribute.
The book "Design Patterns" is your next step.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612
But, you don't have to use an OO approach to everything. Don't be religious about it. If a more procedural approach feels more straitforward, then go with that. People new to OO tend to overdue it for a while.
I think Agile Software Development, Principles, Patterns, and Practices is quite good.
It provides a lot of in-depth disccusion of OO principles listed here:
The principles of Object Oriented Design and Dependency Management
SRP — The Single Responsibility Principle
OCP — The Open Closed Principle
LSP — The Liskov Substitution Principle
DIP — The Dependency Inversion Principle
ISP — The Interface Segregation Principle
REP — The Reuse Release Equivalency Principle
CCP — The Common Closure Principle
CRP — The Common Reuse Principle
ADP — The Acyclic Dependencies Principle
SDP — The Stable Dependencies Principle
SAP — The Stable Abstractions Principle
If you're used to building normalized databases, then Object Oriented design should come naturally to you. Your class structures will end up looking a lot like your data structure, with the obvious exception that association tables turn into lists and lookup tables turn into enums within your classes.
All together, I'd say you're a lot better off coming into OO design with a background in Relational Databases than you would be going the other direction.
If you want to really get to grips with O-O, go play with Smalltalk. ST is a pure OO language, and quite in-your-face about it. Once you get over the paradigm hump you've learned OO as you can't really do Smalltalk without it. This is how I first learned OO.
Check the results of this. Learn from each question.
I really liked Head First Design Patterns, which is very approachable, and the excellent Object oriented Design Heuristics by Arthur J. Riel
This site lists 101 title... design patterns, refactoring and other... Have a look at it.. It will be a good starting point...
Go for Object Thinking by David West. An interesting read..
You're from the dark side though.. as per the book;) Database thinking has been the curse of OO programmers all over. They're opposite ends of a spectrum. For instance
Database thinking values the data attribues over everything else.. normalization and creating types based on how they fit into the DB Schema OR the ER diagram.. OO thinking creates types based on behavior and collaboration and does not recognize the data attributes as all important.
Databases come from the scientific people who value formalization and method over everything else. OO comes from the people who use heuristics and rules of thumb and value individuality and social interaction over a hard and fast process.
The point being a COBOL programmer can write COBOL programs even after moving onto a OO Language. Check out any book like Thinking in Java for the first section which invariably details out the tenets of OO (Apprentice).. Follow it up with Object Thinking (journeyman) and in due time.. a master.
Model your objects by keeping real world objects in mind.
We are currently developing automation software for machines. One of those machines has two load ports for feeding it raw material, while all others have only one. In all modules so far, we had the information of the ports (current settings, lot number currently assigned to it etc) as members in the class representing the machine.
We decided to create a new class that holds the information of the ports, and add two LoadPort members to this MachineXY class. If we had thought about it before, we would have done the same for all those single port machines...
You should look at UML, which is an entire process given to OOD.
I'd recommend getting a book (or a couple), because the theory is quite large, most people pick and choose the techniques most appropriate for the project at hand.
Start reading about design patters, from say Martin Fowler. :)
They are the most practical use of OOP.
I am guess you mean OO in the database world.
Object-oriented databases which store objects never did really catch one so you are currently looking mapping objects to relational database. ORM or Object-relational mapping is the term used to describe the software that does this mapping. Ideally this gives you the best of both worlds where developers can internact with the objects and in the database everything is stored in relational tables where standard tuning can take place.
in DBA slang: object-oriented design is nothing else but properly normalized data behind safe operation interfaces, safe meaning, look at the operations, not the data directly