Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
What is the difference between a software development pattern?
A methodology such as agile DSDM etc how is OO classed as a methodology and a paradigm?
How can OO be applied to a methodology such as agile if itself is a methodology?
Whats the difference between a paradigm and a methodology or a development pattern?
Thanks for any replys.
"When I use a word," Humpty Dumpty
said, in a rather scornful tone, "it
means just what I choose it to mean -
neither more nor less." "The question
is," said Alice, "whether you can make
words mean so many different things."
"The question is," said Humpty Dumpty,
"which is to be master - that's all."
Through the Looking Glass.
Well, not my answer, Lewis Carroll's.
Looking at only one of the questions you asked: "...how is OO classed as a methodology and a paradigm?"
That, at least, has a fairly simple answer:
Object Oriented Design is an analysis methodology.
Object Oriented Programming is an implementation paradigm.
OOD involves analyzing a problem in terms of objects and their interactions. OOP involves implementing a solution as a set of interacting objects.
"Agile" (I hate that name -- though I'll admit "eXtreme Programming" is worse) is really about project management. Just for example, you can apply Pair Programming about equally to something like assembly language or C as to a language that explicitly supports object oriented programming (though being a relatively new idea, it's probably used most often in conjunction with relatively new languages).
Edit: How I'd separate "methodology" from "paradigm" is fairly simple (at least in theory).
Paradigm is really just a fancy word for "example". If I'm following that example to a meaningful degree, the source code (for example) to the program should contain direct, (fairly) clearly defined results from having followed that example. Just for the obvious one, a class publicly derived from another would be a pretty obvious indication of OOP.
A methodology, by contrast, doesn't necessarily show a direct, definable result in the source code. Just for example, there's unlikely to be much in the source code to indicate whether it was developed using "Agile" methodology. I might be able to take a guess if (for example) all the source code files contained comments indicating two authors, but (at best) it would a rather indirect indication of one specific piece of the methodology.
I said in theory, because things can get a bit "fuzzy" at times. If I try hard enough, I can probably write pretty close to pure procedural code, even in a language like Smalltalk that favors objects almost exclusively. Likewise, if I try hard enough I can write OO code in something like C that doesn't really support it. In a case like this, the indications of following the paradigm will usually be harder to find or define than in a more straightforward case.
Methodology is about people. Paradigm is about software.
A paradigm is a way of thinking about a problem - so objects, a relational database, lambda calculus are all models for getting a problem into your head
A methodology is a way of actualy building something based on the paradigm.
If you like, the paradigm is the architect, what are building? should it be a suspension bridge or an arch. The methodology is the engineering, how many cables, how thick, which subcontractors.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I asked this question yesterday and the user #dfeuer advised me, that as a beginner I should not define my own classes. His comment:
Haskell beginners shouldn't define their own classes at all. Learn to define functions, and types, and instances. These are the vast majority of actual Haskell code. As you do this, you'll get a good feel for what makes some classes really useful and others less so. You'll learn what makes some classes easy to use and others full of booby traps. Then when you find a good reason to actually define your own class, you'll go through a slew of bad class designs before you get good enough at it that only most of your attempts go badly. Designing good classes is really hard and rarely necessary.
I am curious, why is defining my own classes usually (for a beginner) a bad idea? What are these "booby traps" and why is it so hard to design good classes?
I thought classes are used to define interfaces to data as I do in OOP. When I write java code, I try to write as much code as possible with abstract classes and especially interfaces, so that when I need to change the data, most of my code remains unchanged and that my methods are highly reusable. Another comment under that question by #Carl suggests, that this is not how classes should be used
Why did you create that class? It feels very weird to me - very much like something that someone used to OOP would do, rather than someone used to Haskell. It has too many parameters, they're connected in what feels like a very ad-hoc manner...
My fear is, that without this OOP use of classes, any change in data would break huge part of code. Is this fear unfunded? And if it is funded, why I should not use classes to define interface to data?
To be fair, I am self taught java programmer and I did not read others people code, so maybe I am doing java wrong also. I only read some books on how the language works and then built an application. I developed it for a year or so, and my whole style is consequence of this experience alone. My style seems to work well for my needs though, and thus I assume it is how java programming/OOP is indeed done.
I'm a relatively a new (and amateur) Haskell enthusiast.
I'd say: just stop thinking you can reuse OOP knowledge, patterns, and other things in Haskell. Even terminology is not "reusable". Classes are not the same thing in OOP languages vs Haskell (well, they are called typeclasses in Haskell, actually).
This is an answer to a question of mine. It starts more or less like this:
It's true that typeclasses can express what interfaces do in OO languages, but this doesn't always make sense.
i.e. stating the inherent difference between two similar (only apparently similar!) concepts in Haskell vs OOP languages.
Another interesting link is on Design Patterns in Haskell. It is very high level, and I still don't quite understand how some tools can be used in Haskell as an alternative to a specific OOP pattern. (Probably the fact that first-class function remove the need for the strategy pattern is the only thing that is totally clear to me, at the moment.) However, I think it is a good reading and, most of all, it should convince you that learning and coding in Haskell comes with a huge mental shift, and it is best approached by starting from zero. If you refuse that, you're not gonna learn Haskell.
I'm not saying that you shouldn't use your brain to notice similarities between OOP languages and Haskell. You should just assume that even trying to build on those observations will handicap your learning process.
As regards Haskell specifically, sitting down and studying LYAH as you were at school (with a laptop to try out examples) is a good way to learn very well the basics. It is an easy-ish to read book, and guides you by hand.
For what is worth, I think that Structure and Interpretation of Computer Programs is a good book that can accompany learning a functional language, as it gives you a practical background to the shift of philosophy I mentioned earlier. You must do the exercises. Doing them will force you towards that mental shift.
A final suggestion, that I would never apply before studying LYAH thoroughly, is to complete The Monad Challenges. But I have to say that LYAH does already a good job at teaching you what the Challenges ask you to think about. I found myself thinking "I already know this", "why is the challenge going so roundabout?".
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've been programming professionally in C, and only C, for around 10 years in a variety of roles.
As would be normal to expect, I understand the idioms of the language fairly well and beyond that also some of the design nuances - which APIs to make public, who calls what, who does what, what is supposed to reentrant and so on. I grew up reading 'Writing Solid Code', it's early C edition, not the one based on C++.
However, I've never ever programmed in an OO language. Now, I want to migrate to writing applications for iPhone (maybe android), so want to learn to use Objective-C and use it with a degree of competence fitting a professional programmer.
How do I wrap my head around the OO stuff? What would be your smallest reading list suggestion to me.
Is there a book that carries some sort of relatively real world example OO design Objective-C?
Besides, the reading what source code would you recommend me to go through.
TIA
Even though the book I am about to recommend you is not specifically for Objective-C (it goes through all concepts of OOP without diving into any specific language) it is probably the best book I've read yet on the subject for a beginner needing an introduction to the subject, it helped me a lot!
The book is:
The Object-Oriented Thought Process
I like this book because it assumes absolutely no knowledge of OOP whatsoever, but it is not dull in wasting time with basic programming concepts. It eases you from the procedural paradigm and then to the OO paradigm. If the author starts to use technical terms he is sure to explain them clearly first. The language is easy to follow and the book is most importantly not boring to read, it does not make use of heavy academic language.
The book is also good to give you some examples along the way to make explanations more clear to understand.
Note that the book I'm suggesting here was published (2nd edition) in 1991.
Object Oriented Programming: An Evolutionary Approach by Brad Cox, the creator of Objective-C, is the book he wrote to introduce his language to the world, and that was a world unfamiliar with the very idea of object-oriented programming. So the book goes very gently and introduces all the basic ideas.
Brad Cox had some ideas about how Objective-C was going to deliver really powerful re-use of components, but things haven't really gone the way he predicted. Still he was a smart guy and I'd recommend his book if you can get hold of it.
For completeness I'll second tuğrul's pointer to https://stackoverflow.com/questions/7571/cocoa-and-objective-c-resources, which has all the modern books listed.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Being a core developer for couple of years, coding applications seeing the class diagrams, sequence diagrams, I decided to improve my self, taking the next step of designing.
As I'm an OO developer, I'm interested in improving my design skills.
For Example, I had a hard time designing a currency converter.
My questions to the SO:
Is it by experience the design skills
can be acquired?
Will learning books/blog/material
over internet etc help?
Is it that one needs the domain
knowledge of the application being
developed?
Knowing Design patterns, principles?
Studying 'Code Complete' book ?
Need to have Problem-solving skills?
In short, given a problem, I just want to solve it in Object-oriented way??
You have to do bad OO design before you can do good OO design.
A fantastic project would be take your currency converter and slowly move the code to use OO concepts. OO is a creative process: there are no wrong answers, but worse and better do exist. Basically, when your code retains functionality and gets shorter/easier-to-read, it's better. When it gains flexibility without adding more code, that's better too. But it's a creative process. Use a version control system like GIT to be able to "undo" easily, try stuff out, and MAKE MISTAKES. OO design is a process.
Is it by experience the design skills
can be acquired?
Yes.
Will learning
books/blog/material over internet etc
help?
Yes.
Is it that one needs the domain
knowledge of the application being
developed?
Yes, but I think that knowing the domain too well can screw up good design. When working with Airline programmers, I noticed that the known, unquestioned abstractions ("ticket," "reservation") inhibited good OO design. Your OO model is not the real world model. It's a model for your program.
Knowing Design patterns,
principles?
Yes, more is better, always.
Studying 'Code Complete'
book ?
Lots of people say it's a great book. But, have you read Italo Calvino? Or Jorge Luis Borges? All kinds of books may help.
Need to have Problem-solving
skills?
No. You get problem-solving skills by applying OO (or any other paradigm).
It is pretty obvious that if you want to learn something, you have to practice. If you want to learn how to be a better programmer, practice programming will help. And if you want to learn how to be a better OO programmer, practicing OOP will obviously help you most. Problem solving skills and knowledge of the domain are things every good programmer needs to have, not only for OOP. And there are a lot of good books out there, they will help you probably, if you are not the "to-less-focused-to-get-something-out-of-a-book" type of person.
Here is a list of programming books. From this list, "Design Patterns" and "Refactoring" seem to be very focused on OOP (I did not read "Head first design patterns", perhaps it is, too). And the book I learned most from (OOP, functional and other concepts), I think, is "Structure and interpretation of computer programs".
I think you're going about this somewhat wrong, because some problems simply have no need of an object-orientated solution. The solution should match the problem, not the other way around.
However, there's no silver bullet to being a better object-orientated designer. The best way, in my opinion, would be to write a complex program, then maintain it solidly for a few years.
The biggest challenge in object-oriented design is not learning the implementation techniques, which come naturally with time and experience. The biggest challenge is understanding the problem domain sufficiently well that you can clearly abstract it with an object model. This is one of the points you hit upon in your question and I think it's certainly one of the most critical. If the problem is not well understood, then you run the risk of implementing a solution for the wrong problem. Further, it's easy to get caught up in the beauty of abstraction and architecture for its own sake, losing sight of the original task.
Is it by experience the design skills can be acquired?
Experience and innate ability - some people just cannot do it.
Will learning books/blog/material over internet etc help?
Of course. But they won't turn you into an OO god.
Is it that one needs the domain knowledge of the application being developed?
Either you need to have it, or you need access to someone who does.
Knowing Design patterns, principles?
Knowing what design patterns are would be a good start - they are just common ways of doing things - nothing magic.
Studying 'Code Complete' book ?
I flicked through it in bookshop once.
Need to have Problem-solving skills?
Obviously yes, I would have thought.
I suggest you to learn Smalltalk. YES..I know it's a bit outdated but I think this is the only environment to experiment, appreciate and 'have fun' with Object Orientation.
In Smalltalk everything from the IDE is an object. You can think about objects without wasting time with details such as header/source files, compilation and so on.
Download a copy of Squeak Smalltalk (http://www.squeak.org/) and start practicing
Try to learn and truly grasp the meaning of "abstraction". I mean abstraction as a general concept, at least as it applies to computer science and software engineering.
From abstraction follows object-orientation. Since, abstraction is about separating the concepts in a system from the implementation, for instance any logical representation of a system or application is an abstraction. Any modeling of an application/system is an abstraction. So, among many ways of modeling an application/system/problem, one is called the object-oriented way. So, abstraction first. Once you get the point of abstraction, then you will see that among many ways of modeling things, object-oriented modeling is superior, in most cases. That is how you get the point of OO.
Then, from abstraction follows fundamental principles of object-orientation: abstract data types, information hiding etc, and mechanisms of achieving them like encapsulation, inheritance etc.
To number your points - I think 2 - 6 are great and I think anyone writing code should read code complete, even if its not OO. But unfortunately it seems that point 1 is the most important!!!
I think that's a problem in our profession. We learn on the job as opposed to studying great code. So essentially everybody is re-inventing the wheel in terms of learning.
Additionally you can use the unit testing, as tool to improve the class design.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
What is a good challenge to improve your skills in object oriented programming?
The idea behind this poll is to provide an idea of which exercises are useful for learning OOP.
The challenge should be as language agnostic as possible, requiring either little or no use of specific libraries, or only the most common of libraries. Try to include only one challenge per answer, so that a vote will correspond to the merits of that challenge alone. Would also be nice if a level of skill required was indicated, and also the rationale behind why it is a useful exercise.
Solutions to the challenges could then be posted as answers to a "How to..." question and linked to from here.
For example:
Challenge - implement a last-in-first-out stack
Skill level - beginner
Rationale - gives experience of how to reference objects
Building Skills in Object-Oriented Design is a free book that might be of use.
The description is as follows:
"The intent of this book is to help the beginning designer by giving them a sequence of interesting and moderately complex exercises in OO design. This book can also help managers develop a level of comfort with the process of OO software development. The applications we will build are a step above trivial, and will require some careful thought and design. Further, because the applications are largely recreational in nature, they are interesting and engaging. This book allows the reader to explore the processes and artifacts of OO design before project deadlines make good design seem impossible."
Write a challenging program from scratch. Try to get some people (around five, that should be doable) to use it. Respond to their change requests.
Adapt your program's design. Start small, then watch it grow. Manage this growth. This is hard. You will also have to fix bugs and maintain the thing over time, which for me was a very valuable lesson.
Challenge: Write a wrapper for your web site/service API of choice in your language of choice, that doesn't already exist (ex. a ZenDesk API wrapper written in C#). Release the wrapper as open source for others to use.
Skill Level: Beginner to Intermediate
Rationale: To learn how to extrapolate a 3rd party web service API into a meaningful set of objects/classes, making the reuse of that API easier in your chosen language.
After you have learned the basics, study the "Gang of four" design patterns book.
http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1221488916&sr=8-1
This is a classic, and a must read for any coder who wants to understand how to use OO to design elegant solutions to common coding problems.
Take a procedural-style written piece of code and try to transform it into OOP based solution. During the process, consult a book on refactoring and design patterns. A friend of mine was able to make a huge step forward in understanding object oriented concepts exactly this way. As with anything, this might not work for everyone.
I have found CRC cards to be quite effective in learning, teaching and building good OO design.
Certainly a good challenge, although less accessible than a "start from scratch" assignment, is to refactor some existing code that either doesn't use inheritance or doesn't use very much of it to make greater use of inheritance. The process of refactoring will expose a lot of the benefits and gotchas of oop, as it certainly has for me on my most recent project. It also pushed me to understand the concepts better than past projects have where I've created my own object oriented designs.
A given task has very little to do with being "OOP", it's more in how you grade it.
I would look at the Refactoring book, chapter 3, and make sure none of the bad code smells exist in the solution. Or, more importantly, go over ones that do apply.
Most importantly, watch for the existence of setters and getters (indicating that you are operating on values from a class and not asking the class to operate on it's own values)--or using "extends" without applying the Liskov Substitution Principle, stuff like that.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
An answer to a Stack Overflow question stated that a particular framework violated a plain and simple OOP rule: Single Responsibility Principle (SRP).
Is the Single Responsibility Principle really a rule of OOP?
My understanding of the definition of Object Orientated Programming is "a paradigm where objects and their behaviour are used to create software". This includes the following techniques: Encapsulation, Polymorphism & Inheritance.
Now don't get me wrong - I believe SRP to be the key to most good OO designs, but I feel there are cases where this principle can and should be broken (just like database normalization rules). I aggressively push the benefits of SRP, and the great majority of my code follows this principle.
But, is it a rule, and thus implies that it shouldn't be broken?
Very few rules, if any, in software development are without exception. Some people think there are no place for goto but they're wrong.
As far as OOP goes, there isn't a single definition of object-orientedness so depending on who you ask you'll get a different set of hard and soft principles, patterns, and practices.
The classic idea of OOP is that messages are sent to otherwise opaque objects and the objects interpret the message with knowledge of their own innards and then perform a function of some sort.
SRP is a software engineering principle that can apply to the role of a class, or a function, or a module. It contributes to the cohesion of something so that it behaves well put together without unrelated bits hanging off of it or having multiple roles that intertwine and complicate things.
Even with just one responsibilty, that can still range from a single function to a group of loosely related functions that are part of a common theme. As long as you're avoiding jury-rigging an element to take the responsibilty of something it wasn't primarily designed for or doing some other ad-hoc thing that dilute the simplicity of an object, then violate whatever principle you want.
But I find that it's easier to get SRP correct then to do something more elaborate that is just as robust.
None of these rules are laws. They are more guidelines and best practices. There are times when it doesn't make sense to follow "the rules" and you need to do what is best for your situation.
Don't be afraid to do what you think is right. You might actually come up with newer and better rules.
To quote Captain Barbossa:
"..And secondly, you must be a pirate for the pirate's code to apply and you're not.
And thirdly, the code is more what you'd call "guidelines" than actual rules...."
To quote Jack Sparrow & Gibbs.
"I thought you were supposed to keep to the code."
Mr. Gibbs: "We figured they were more actual guidelines. "
So clearly Pirates understand this pretty well.
The "rules" could be understood via the patterns movement as "Forces"
So there is a force trying to make the class have a single responsibility. (cohesion)
But there is also a force trying to keep the coupling to other classes down.
As with all design ( not just code) the answer is that it depends.
Ahh, I guess this pertains to an answer I gave. :)
As with most rules and laws, there are underlying motives by which these rules are relevant -- if the underlying motive is not present or applicable to your case, then you are free to bend/break the rules according to your own needs.
That being said, SRP is not a rule of OOP per se, but are considered best practices to create OOP applications that are both easily extensible and unit-testable.
Both are characteristics that I consider as of utmost importance in enterprise application development, where maintenance of existing applications occupies more time than new development does.
As many of the other posters have said, all rules are made to be broken.
That being said, I do think that SRP is one of the more important rules for writing good code. It's not specific to Object Oriented programming, but the "encapsulation" part of OOP is very hard to do right if the class does not have a single responsibility.
After all, how do you correctly and simply encapsulate a class with multiple responsibilities? Usually the answer is multiple interfaces and in many languages that can help quite a bit, but it's still confusing to the users of your class that it may apply in completely different ways in different situations.
SRP is just another expression of ISP :-) .
And the "P" means "principle" , not "rule" :D