The title says it all, I am bit confused as I was asked a question that Information handling in term of OOP is abstraction or encapsulation?
I opted for abstraction but still I am confused because in encapsulation we also hide the fields and in abstraction we hide the details.
Any help in this regard
It may help if you think of encapsulation as one of the tools used to create abstraction. See the wikipedia entry for encapsulation here http://en.wikipedia.org/wiki/Encapsulation_(object-oriented_programming)
Abstraction generally hides information, while Encapsulation separates the changeable data from the unchanged one. In this way, Encapsulation helps to achieve the Open Closed Principle.
Here is a nice answer that I think it clears the confusion
Encapsulation has two faces; data
abstraction and information hiding.
Data abstraction is a type seen from
the outside. Information hiding is a
type seen from the inside.
Abstraction focuses on the outside view of an object (i.e. the interface)
Encapsulation (information hiding ) prevents clients from seeing its
inside view, where the behavior of the
abstraction is implemented
Encapsulation = Hiding the Complexities / information
Abstraction = A (somewhat) defined way to handle complexities, using encapsulation
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 5 years ago.
Improve this question
I've been doing some research on OOP concepts and am having a bit of an issue in trying to understand what exactly Abstraction is. I've gone over numerous Stack Overflow posts on the topic but haven't really been able to pinpoint a satisfying answer.
I've seen a lot of discussions on the differences between Abstraction and Encapsulation, and naturally started started thinking about Abstraction in terms of hiding how a particular class works and providing abstraction through the class API. Here are some posts that steered me in this direction:
Best voted answer refers to functions being Abstract. The very next answer starts talking about abstract classes...
Best voted answer seems to refer to exposing through the class API while the next two goes off in an Inheritance setting. Third answer even suggests Composition and Aggregation is considered an Abstraction
However, as I read through more posts, I noticed answers portraying Abstraction in an Inheritance context, specifically using interfaces and abstract classes to provide an Abstraction of a certain entity (class). I assumed Abstraction given in this manner would allow developers to extend new objects appropriately according to the "guidelines" outlined by this Abstraction. Here are some posts that lead me in this direction:
First couple of answers talk about Abstraction in an abstract class/interface setting, while some down the line start talking about exposing classes through APIs
Top two voted answers refer to abstract classes/interfaces
I'm not sure if I'm just completely missing the point here, but it's getting pretty confusing because every answer seems to add a slight variation to the mix. I definitely see why both contexts are crucial in Object Oriented Programming, but I really wanted a clear-cut definition of what Abstraction is.
Which brings me to my point: does Abstraction work in multiple contexts? Does Abstraction portray both of these concepts?
Hiding away "unnecessary details" as done through interfaces and
abstract classes
Providing an abstraction on a class to be created through interfaces and abstract classes. We can provide an interface of IPet which would act as an abstraction of a Dog class. Additionally, we could provide an Animal base class as an abstract class to provide a higher level abstraction. This could let us use Polymorphism and allow different classes that fall under our Animal abstraction to interact with one another.
Abstracting the implementation of a class by exposing it through the class API
given a Dog class, we just need to know that it has a feed() function as part of its API, and call that function to feed it without knowing how the feeding is actually done. This provides abstraction on the Dog class and lets us easily interact with the class
One of the links I've included above contains the following quote by Matthew Watson that says:
"The problem is that there are no precise definitions for these concepts, and the words themselves have multiple meanings even within the context of object orientation."
Is it just that Abstraction is so abstract, even the definition is abstract :P? Thanks for any guidance in advance!
Edit: I'm rather new to SO and am not really aware of what the "primarily opinion based" flag entails. I don't see how this question is any less valid than the slew of questions regarding Abstraction on SO. I think it would be considered less opinion-based as I'm actually pinpointing two different contexts in which I think Abstraction makes sense in. I've seen many questions that just ask what Abstraction is, which I'd think is an even broader question than what I have here.
To me, abstraction is one of the most beautiful concepts of oo, which is actually what makes the program language very close to human thinking: we, humans always want to classify. Think of a car: your car. And let's approach that car in the context of a banker asking about your assets in the context of a loan: you will say you have assets (highest level of abstraction): an expensive car, a family car, a house, a boat, etc. They all have a specific value. Then suppose the context of the conversation switches to the banker having a personal interest in that car, given he's a car freak him selves. Now the cars will be described in more detail, and you can see different abstraction levels being defined: sport car with brand names, and lots more characteristics.
During the design time, your interest is about the levels of abstraction: What you want to do with it, i.e. its context. So, we will have the levels of abstraction: Asset, Car (and Boat and House), SportCar, FamilyCar. And so on. The context should never have more details than it needs, and this is what you're concerned about during design phase.
During the implementation phase, you will implement these levels of abstraction by encapsulating the properties that belong at these levels. E.g. Asset has a value, where Car has colour and SportCar might have some specific characteristics that a FamilyCar doesn't have.
So, key difference is: design time vs implementation time.
This blog post described the difference in much detail:
http://javarevisited.blogspot.be/2017/04/difference-between-abstraction-and-encapsulation-in-java-oop.html
Here's another post at stackoverflow: What's the difference between abstraction and encapsulation?
Hope this helps.
As for me, the abstraction is when you solve a problem without going into the details at all. If you need to output list of cars, then I do not think "take a list of cars, walk through them, get their data, print them", I rather think "I need a set of objects, preferably cars, that can display data about themselves in the format that I need.". It's more about way of thinking.
I understand that information hiding and encapsulation are not necessarily the same thing but by definition they seem very synonymous. This has led me to wonder whether one can be present without the other.
In simple way I'll try to explain this things :
Encapsulation is the concept of grouping of related things into one unit.
Information hiding is the concept of restricting an access to the members that we grouped together in above concept.
So if you see, both concepts are similar. Here we can not say there is the dependancy of these concepts on one another.
Encapsulation is the possibility to groups related items. These are both member variables and methods.
While information hiding is the possibility to hide the internal state.
However in practice information hiding is often seen as a part of encapsulation.
I'm sorry if my question doesn't meet the standards of SO, but I really had some hard time going through the last few words within this definition of ABSTRACTION from Grady Booch
“An abstraction denotes the essential
characteristics of an object that distinguish it from all other kinds
of objects and thus provide crisply defined conceptual boundaries,
relative to the perspective of the viewer"
Please explain what does he mean by "relative to the perspective of the viewer". Any example would be really helpful.
They simply mean that from the point of view of the person trying to understand the abstraction, it should be clear what it is, what in includes and what it doesn't.
However, how is implemented might not be that clearly different from other abstractions.
For example:
A URI is a different abstraction from a Name. It's clear to a developer and a user what either are. However, implementation-wise they both might be little more than strings.
I think that what they are trying to say is that the semantics and the behaviors define abstractions correctly, not how they are going to be implemented.
Definitions in OOP world are different and not always very clear, for example, I can bring you a definition of abstraction from Tony Hoare:
"Abstraction arises from a recognition of similarities
between certain objects, situations, or processes in the real world,
and the decision to concentrate upon those similarities and to
ignore for the time being the differences."
Maybe this is clearer to you. However, I do not care too much about the words of these definitions.
What is important to understand about abstraction is that it has the function to expose to the user (or viewer) a set of behaviors (an interface) that completely describe and identify an entity (or object). Once you know these behaviors (methods) you can and should ignore the actual implementation of these methods. What the user should care is to provide input parameters and to receive the right results.
I think this is a more practical definition of abstraction.
I'm wondering whether an object asking a question to another object that indirectly holds it is "bad" design. For example...
Requirements:
Character (an object) moves on a grid. When it tries to move to another spot, it needs to know whether that spot is already occupied by something that blocks it, or if that part of the grid is completely inaccessible. (Note that the character itself needs to know).
In the application, a state holds a tilemanager and a charactermanager. The tilemanager knows what tiles are accessible and which aren't. The charactermanager knows the characters' tile locations.
Would it be reasonable for the character to call a function from the state, say AuthorizeMovement, which determines whether movement is possible via its TileManager and CharacterManager, and returns true if so, false if not?
Is this violating any important principles, leading to trouble down the road?
Obviously this is generalized and stripped down to what is necessary to understand the problem.
I'd suggest that it is likely a bad design, yes. The "red flag," so to speak, is the circular reference. You said:
... an object asking a question to another object that indirectly holds it
So, the "holding" object has a reference to the "held" object, and also in order to "ask a question" the "held" object will need a reference to the "holding" object.
That's makes a circular object dependency graph and is often a code smell.
It would seem some other class should have the responsibility of knowing about both the character and the TileManager and/or CharacterManager.
I don't see a problem. Good OO Design comes with many principles. But at its core you have the big 4: Encapsulation, Inheritance, Polymorphism, and Abstraction. In addition, you want high cohesion and low coupling. Meaning your objects/classes can fit anywhere and aren't tied to a particular implementation or class.
With that said, it sounds like you have used the above to encapsulated movement and characters abstract them into separate classes. So your Character class isn't modifying the board directly, which would be bad if it were.
As you gain a deeper understanding of your problem, you can always refactor you code to improve your design to take advantage of other principles.
It's not against any OOP principle. The details of the call are totally abstracted and you depend on the State object anyway. How on earth else would you possibly implement this function?
Abstraction and principles are useful tools. But you shouldn't depend on them to qualify your code as good. Not every abstraction or every principle is good for every scenario or every possible implementation. They're guidelines, not rules. If you can't quickly see an alternative implementation, use this one and then come back to it.
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
What principles do you generally follow when doing class design?
Principles Of Object Oriented Class Design (the "SOLID" principles)
SRP: The Single Responsibility
Principle A class should have one,
and only one, reason to change.
OCP: The Open Closed Principle You
should be able to extend a classes
behavior, without modifying it.
LSP: The Liskov Substitution
Principle Derived classes must be
substitutable for their base
classes.
ISP: The Interface Segregation
Principle Make fine grained
interfaces that are client specific.
DIP: The Dependency
Inversion Principle Depend on
abstractions, not on concretions.
Source: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
Video (Uncle Bob): Clean Coding By Robert C. Martin ( Uncle Bob )
Don't forget the Law of Demeter.
The S.O.L.I.D. principles.
Or at least I try not to steer away too much from them.
The most fundamental design pattern should be KISS (keep it simple stupid)
Which means that sometimes not using classes for some elements at all it the right solution.
That and CRC(Class, Responsibility, Collaborators) cards (write the card down in your header files, not on actual cards that way they because easy to understand documentation too)
As mentioned above, some of the fundamental Object Oriented Design principles are OCP, LSP, DIP and ISP.
An excellent overview of these by Robert C. Martin (of Object Mentor) is available here: OOD Principles and Patterns
The "Resource Acquisition Is Initialization" paradigm is handy, particularly when writing in C++ and dealing with operating system resources (file handles, ports, etc.).
A key benefit of this approach is that an object, once created, is "complete" - there is no need for two-phase initialization and no possibility of partially-initialized objects.
loosely coupled, highly cohesive.
Composition over inheritance.
Domain Driven Design is generally a good principle to follow.
Basically I get away with programming to interfaces. I try to encapsulate that which changes through cases to avoid code duplication and to isolate code into managable (for my brain) chunks. Later, if I need, I can then refactor the code quite easily.
SOLID principles and Liskov's pattern, along with Single responsibility pattern.
A thing which I would like to add to all this is layering, Define layers in your application, the overall responsibility of a layer, they way two layers will interact. Only classes which have the same responsibility as that of the layer should be allowed in that layer. Doing this resolves a lot of chaos, ensures exceptions are handled appropriately, and it makes sure that new developers know where to place their code.
Another way to design is by designing your class to be configurable creating a mechanism where the configuration can be plugged in your class, rather than overriding methods in sub classes, identify what changes, see if that can be made configurable and ensures that this functionality is derived from configurations
I usually try to fit the class into one of the oo design patterns.