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!
Related
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.
Improve this question
I've started to study concepts like Cohesion and principles like Single Responsibility Principle. I am very confused about the difference between them.
The web has a lot of information, but I find it very difficult to filter out the correct comparison.
What is the relationship between Cohesion and Single Responsibility?
Is it possible for a class to have only one responsibility but low cohesion?
Cohesion can be seen a software quality metric, while SRP is more of a subjective software quality principle. As the Pragmatic Programmers describe it, cohesive code happens when things that belong together and depend on one another stay together.
For instance, if a class's instance variables or properties are all used by its methods and its methods alone, but the methods also do not use any external data or methods from other objects, that class is said to be highly cohesive. However, if that class happens to be reading and writing from a file, that class can be seen as not adhering to the Single Responsibility Principle, as reading and writing can be viewed as two very distinct tasks. Regardless, you can also see the class's main task as "do IO operations with the file system", so SRP is somewhat open to interpretation depending on the context it's applied.
This concepts are described in a concise manner in Wikipedia here and here.
One responsability is still an abstract concept. If the responsability is to build a report, it is one task, but still a task with several steps and data parts. So there is some space for low cohesion to happen in the class. Just making a calculation, if simple, is much more "atomic" and high cohesion.
If you see SRP as having a single reason to change the class, I think that helps too.
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 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.
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 8 years ago.
Improve this question
I always hear that we need to encapsulate whenever we write object-oriented code. If I'm the only developer on a project, do I still need to use encapsulation?
One way to put an answer: Encapsulation, conceptually, exists for writing better, safer, less error-prone code. It doesn't exist, primarily, to facilitate teams working together on code (that might be a side effect, but that's not the purpose).
So the goods that encapsulation seeks to foster scale from one coder to many coders, and they are goods that do not really have to do with the number of coders, although those goods may find stronger expression the larger the project and teams are.
Encapsulation is there for a reason.
Someone has to maintain and manage your code after you are done, right? What if the project gets bigger and you get team members?
So, the answer is "yes", it is always best to use encapsulation whenever possible.
The fact you are asking this question makes me wonder you actually did not get the actual value of encapsulation as a means to reduce and thus deal with complexity.
My theoretical computer science professor used to tell me that in the end, if you think at the whole binary representation of a program, any program is just a number. Very big indeed but, only a number. And that is true, any other construct we use but 0 and 1 (i.e. C++, Java, Python, functional programming, object oriented programming, aspect oriented programming, etc..) is just because of the fact we need more abstract means to get the one number we need.
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
We want to implement a model or guideline for our OO designs,. We like Domain-Driven Design. Our specific question is: do you think DDD is still valid right now beyond the pattern design? If so, do other approaches or variants exist that we should evaluate ?
Fundamentally we develop enterprise web and desktop applications using Visual studio (c#).
Thanks in advance
In my opinion, DDD is as pertinent today as ever. The idea that one should strive for an Ubiquitous Language, such that the domain in code is not divorced from the domain as described by the domain experts, will probably remain a good idea for a long time, and it is easier today to focus on the domain first and consider persistence as a "secondary" problem than it used to be. It is also still true that DDD requires an important design effort, and its value is going to be proportional to how complex the domain is.
I have not written any application using the methodology, but I have been reading a lot on Event Sourcing and CQRS lately, and they both seems like a very interesting approach which should fit well with DDD (and are usually advocated by people who are DDD proponents).
I can't find it right now, but there is a video interviews of Eric Evans floating around somewhere on the web,You may be interested in watching this video of Eric Evans, which is a form of retrospective on the methodology a few years after writing the book, and what he would have done differently now.
I think DDD is quite alive (or quite as dead) as before. My opinion is that the "domain" is a hot topic today because of DSLs (Domain-Specific Languages) and MDE (Model-Driven Engineering).
You may want to learn more about a similar "domain-driven" aproach, called DSM - Domain-Specific modeling. In DSM, you can work through patterns but you also define code generators that translate your domain-specific design into working code.
Check the DSM Forum or Wikipedia for more information about DSM.
The two most notable tools right now in this area are MetaEdit+ from MetaCase and AtomWeaver from Isomeris.