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 8 years ago.
Improve this question
I know of OOP (Object oriented programming) and SOLID.
OOP basics
Encapsulation
Abstraction
Inheritance
Polymorphism
and
SOLID
Single Responsibility Principle
Open / Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Dependency Inversion Principle)
However, I'm not sure what the exact differences are, and if SOLID is a subset of OOP. Can anyone help explain the differences?
the answer is simple:
languages or concepts which don't support Encapsulation, Abstraction, Inheritance and Poly are not object oriented. If you do something object oriented you can always apply these OO basics, because they are available. One doesn't call such things principles.
SOLID in return is optional. When developing an OO design you should strive to be SOLID, by applying the underlying basics. Solid only determines how "good" your design is, not if it is object oriented or not. They are principles.
PS: I don't understand the downvotes to your question, since it's legitimate, can be answered clearly and is confusing to many OO newcomers. Upvote from me.
Object-oriented programming is a programming form which is based on the idea of "objects". Rounded up pieces of code that describe properties (width, time, position...) and behavior (change width, display time, calculate position...) of required entities that work together to solve a specific problem. SOLID is a set of principles that help you design a solution for a specific problem in the object-oriented domain. Think of it as a set of rules that will help you visualize the most correct way to reach a solution for a problem.
Related
This question already has answers here:
Encapsulation vs Abstraction?
(13 answers)
Closed 6 years ago.
I am learning about OOP and I was wondering about abstraction and encapsulation.
Would it be correct to say that abstraction is to chose what information to show and encapsulation is the way it is achieved? If I said this in an interview would it be a correct way to explain it?
Abstraction and encapsulation are complementary concepts: abstraction focuses on the observable behavior of an object... encapsulation focuses upon the implementation that gives rise to this behavior... encapsulation is most often achieved through information hiding, which is the process of hiding all of the secrets of object that do not contribute to its essential characteristics."
Thats about as simple an answer as I can find you. source: Simple way to understand Encapsulation and Abstraction
Based on this and what I know of OOP, I would say that in an interview that would be a very basic but acceptable answer. Lots of good info on that thread. Enjoy!
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 6 years ago.
Improve this question
How Composition is a lesser principle level, than Inheritance? One always has to consider Composition over Inheritance, but there is no mention of Composition in the four major OOP principles. What is the reason behind this? Are they not at the same level?
Composition is a lower-level and a much older concept than inheritance; it comes from the analysis-synthesis approach which basically states that things are either composed of other things or trivial (atomic). It was first introduced back in ancient Greece as a general approach to understanding things.
Composition is not specific to OOP, e.g. in plain C, which is far from being OO, structs are authored using composition, likewise in functional programming functions are composed of other functions, though the nature of composition is totally different in these two examples.
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
Why do we use OOPs concepts?
What are the advantages/disadvantages of OOP?
Where do we use OOP?
How do we tell if a program can be written in OOP paradigm? How is it organized?
Note : I'm not related to technical field... So please consider this in your answers.
In short: to reduce the cognitive load required to write, maintain and understand the software.
Software systems are inherently complex, so developers need some tools to break things down to the modules and individual components that could be analyzed and understood without enormous efforts — and OOP is just that kind of tool.
Thats quite a big question. And I try to give you a feeling why we do develop principals like oop ,soa,....
Most of the principal target to make software less complex. Imagine a file with 1.000.000 functions. it would become difficult to find the you want to change. Especially if there are not veryx wqell name like "Update" so you could have a thousand "update" methods.
Often things are less complex if you don't see the complete information pool so you can focus and things you may need. Thats also why there ideas like the information hiding principle .
Another thing is that when you have standards you have to think about. For example in Real life you know that you can sit on a chair (thats a standard) you don't ahve to think about it. Thats why standards make like easier. Some aspects of OOP establish standards (e.g. use of classes) therefore there is little less complexity.
Having class which are grouping the functions may be the first step towards oop. Now when you search a function you would most propably know what you want to udpat "a custoemr" so you know this function may be in the customer class and you have to only look over these methods.
And most of the time thats what principals are made for. making software more read and understandable
OOP is much much more and not the only paradigm .But there is so much more and OOP has so much principals and interprations. It would be too much to explaind and discuss it here. I would also recommend you to have a look at the CleanCoders Movement which provide this in a more general way.
CleanCoders Webcasts
Does ORganization matter
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 9 years ago.
Improve this question
I've been reading Wirth's books on Oberon--or at least trying to--and I'm hitting a mental road block when it comes to figuring out what is going on regarding object oriented programming in Oberon.
I know his method is supposed to simplify object oriented programming by avoiding "standard" OOP syntax, which he labels a perpetration, as if it was somehow criminal, and maybe I'm just too rooted in class, method, etc... kind of thinking, but can someone translate Oberon's method into standard OOP language, or at least conceptually explain it.
You may get some insight by comparing Ada's tagged type, examined in Ada 95 Rationale: II.1 Programming by Extension, with Oberon-2's type tag, discussed in Object-Oriented Programming in Oberon-2: Run-Time Data Structures, cited here. Both use a record structure with hidden type information to implement inheritance and polymorphism. See also A Comparison of the Object-Oriented Features of Ada 95 and Java, cited here.
Addendum: So are they simply associating procedures with records?
An Oberon record type encapsulates both procedures and data, in a manner similar to the object type in Object Pascal. An Ada tagged record encapsulates the data, while the enclosing package encapsulates the subprograms and record.
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 9 years ago.
Improve this question
What are the best practices for separating data in different classes? Not just objective c, but programming in general.
For example, if someone was making a game like angry birds, how one manage classes?
Would you have a separate class for just the projectiles (in angry birds case, the birds) and have different classes for the targets, music and images, etc?
There is no simple answer to this. You first need to really understand, deep in your soul, how object-oriented programming works and what it represents. Then you need to make your own decisions based on that understanding and your understanding of the problem at hand.
I've seen many "cookbook" applications of OO and MVC and the like that are terrible, even though the writers dotted all the i's and crossed all the t's and their college professors would have given them an A+ on the project.
But in general I'd probably have a common superclass (with several subclasses) for entities that represent visible, movable objects, but probably not use that for music, eg.
not even data but your functional approach must be modular. create as many smaller components in terms of classes and define their behavior as methods and set the interaction between them through the Game Manager/Logic control system that you design for your game...
Best of luck..!!