By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
457,932 Members | 1,474 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 457,932 IT Pros & Developers. It's quick & easy.

encapsulation

P: n/a
I am not sure I understand encapsulation.

I thought that one of the objectives in OOPs is to
hide data structures from other objects so that
they did not have to know how to unpack them.

However, in some instances, it seems that passing
a data structure greatly reduces the number of accesses
one might have to make between objects. Ie:
a simple database might present an "offering" (which is
really in the form of a data structure) to a display object so that a person
can make a data selection. Then the selection (which could represent
multitudes of records) could be passed back to the database. The problem is
that the display object would now have to know how to unpack the "offering"
and then how to pack it back up
to send a subset of the offering back.

How does OOPS cope with this fundamental problem?

I realize that I could integrate the display module into
the database module but it seems that I am just heading back to the old days
when one had merely one object
"The Program". Should not I be able to break the problem down so that I
encapsulate the database
independently from the display interface....and yet
allow for reasonable communication between them
of massive amounts of data?

Please help me to understand this issue.

Thank you,

Bil
Nov 20 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Bill,

I'll try to explain this the best I can and help you get a grasp on it.

From what I read from your statements, its not only understanding
encapsulation but the idea of multi-teir development as well. The idea of
separating the UI Layer from the Business Logic layer from your datalayer.
(Or in Enterprise Apps UI->Facade->BLL->Data->System framework)

In which case, if this is what your questioning then I will give you a
pretty simple, yet understandable example.

As far as sending "package objects" in and out of layers and knowing how to
unpack them isn't bad. I don't think so at least. I mean look at it from a
common sense perspective, if you have a 3 teir program, UI->BLL->Data,
shouldn't each one of these know how to handle data being passed in and out
of it? How are you going to display something you know nothing about?
Second of all, why?

Now, if you want flexiblity in the things that your display layer can show
thats where interfaces come in, in which case you can define a structure
that both parties (the application and the business logic or business logic
and data) have to conform to in order to "communicate" with one another. A
standard if you will. A good example of this is the IList interface, which
is used to like mad between windows forms controls (as well as ASP.NET) and
whatever implements IList.

Now, can all this be encapsulated into a single executable known as the
program, sure. I've heard arguments that says all your BL should be in a
DLL and your data should be in a DLL, etc... I personally only do it when I
know I'm going to resuse a library, but for stuff that is 100% proprietary,
I just put it into the executable. And I use interfaces to talk between
these layers often times so I have some conformity and gives me the
possiblities of expansion (though you could ask the questoin, what if your
interface changes, in which case we are in a whole new realm. =))

..NET uses this idea extensivly with Datasets, in which case these are
basically the "packages" you are talking about that is offered by the
datalayer, BL can do stuff with it, and your UI can display it because it
implements several interfaces common between the UI and the DL.

I hope this answered your question some, I'm tired, haven't slept for awhile
and really don't know what I'm saying anymore. So if you have more
questions, or anytone wants to just take my idea and tear it up, cool. =)

-CJ

"William H. Burling" <wh*******@earthlink.net> wrote in message
news:i9******************@newsread1.news.atl.earth link.net...
I am not sure I understand encapsulation.

I thought that one of the objectives in OOPs is to
hide data structures from other objects so that
they did not have to know how to unpack them.

However, in some instances, it seems that passing
a data structure greatly reduces the number of accesses
one might have to make between objects. Ie:
a simple database might present an "offering" (which is
really in the form of a data structure) to a display object so that a person can make a data selection. Then the selection (which could represent
multitudes of records) could be passed back to the database. The problem is that the display object would now have to know how to unpack the "offering" and then how to pack it back up
to send a subset of the offering back.

How does OOPS cope with this fundamental problem?

I realize that I could integrate the display module into
the database module but it seems that I am just heading back to the old days when one had merely one object
"The Program". Should not I be able to break the problem down so that I
encapsulate the database
independently from the display interface....and yet
allow for reasonable communication between them
of massive amounts of data?

Please help me to understand this issue.

Thank you,

Bil

Nov 20 '05 #2

P: n/a
CJ,

Thank you for responding.

I apparently did not appreciate that interfaces do not have to be simple. By
simple I mean a single value
with a data type of byte, char, word, long. I was under the impression that
perhaps slightly more complicated
properties could exist but none more complicated than a single dimensional
array all array elements the same.
ie: all marbles or all bowties.

Perhaps that is what the IList is about(a form of an array?). I don't know
anything about the IList but suspect it is an object that
is passed between objects and everybody knows how to read it (as they know
its properties and methods)
But i do not know if the properties are simple. All the "controls" that I
know of in windows programming
seem to have only "simple" (no complex data structures) properties. Are the
Ilist properties "simple"? or are the arguments
of the methods "simple"?

I was under the impression that encapsulation was centered around "hiding
the data structure" so that other members
did not have to know how to unpack it. It was my understanding that the
reason why one did not want to have a second
object unpack a data structure is that it now made a second object dependent
upon another (they both had to know how
to unpack a complicated data structure). Hence that method now had to be
written twice.......making the code
less robust (as now the programmer has to remember to change the method in
two locations.

for simple real world problems I can readily see how to do that. But for
more complicated problems in which alot of
data is being exchanged.....I suddenly found the One property for one data
concept very combersome and unwieldy.

As I think about it....I am beginning to see some things. At some point one
has to unpack the data. if that is the case, then
if it is too unwieldy for an interface then it will also probably be too
unwieldy inside of some code in the second object.
In both cases, one has to get at the unpacked data. Might as well be at an
interface.

Let me give you a very specific example so that you can see my plight.

i am modeling the storage of dry cleaners invoices for a hotel group.

each invoice has a hotel name, hotel invoice number, guest name,
guestwrittendate, guestwrittenroomnumber,
then about 40 "items". each item has the same data structure (clng type,
clothing type, PriceToGuest,
NumofclothesTobeCleanedfor each clng type and clothing type)

The invoices are currently stored in excel workbooks, each workbook
represents a year for a given hotel. each worksheet
holds invoices for one billing period for that year.

So to specifiy any given invoice, I must let the user select:
Hotel, year, billing period, invoice number
and to gain access to this invoice, i need to allow the user to retrieve the
40 items.

how does one do that without making an interface that is 4 properties plus
40*4 properties that represent the item information.
It seems absurd.

I could make an interface that presents 4 properties (hotel, year, billing
period, invoice number), and then 4 more properties
that display a single item(clng type, clothing type, price, numofclothes).
To gain access to all 40 items, perhaps i need to offer
some sort of indexing mechanism to allow a user of the data to index through
all 40 items through the four exposed "item" properties.

The above, then, gives the user "simple" (no complex data structures; just
end use data) without having an excessive interface.

A compromise would be to ship all 40 items in an array in which each array
element is a datastructure holding the four parts of an item.
To retrieve the item parts, a single object could be used in which an array
element is "pipelined" through it where the output
is discrete end-use pieces. Since the unpacker is in a single object I have
not violated my goal of having only single copies of code.
any object wanting to read this data just uses the unpacker.

However.....what have i gained? a smaller interface but more complex (as now
another object needs to know that it must use
an unpacking object).

Am I making sense here....am i phrasing the problem in the right way? i am
sure my problem is generic. there must be vocabulary
to describe it. what is that vocabulary.

Thank you,
Bil

"CJ Taylor" <no****@blowgoats.com> wrote in message
news:vn************@corp.supernews.com...
Bill,

I'll try to explain this the best I can and help you get a grasp on it.

From what I read from your statements, its not only understanding
encapsulation but the idea of multi-teir development as well. The idea of
separating the UI Layer from the Business Logic layer from your datalayer.
(Or in Enterprise Apps UI->Facade->BLL->Data->System framework)

In which case, if this is what your questioning then I will give you a
pretty simple, yet understandable example.

As far as sending "package objects" in and out of layers and knowing how to unpack them isn't bad. I don't think so at least. I mean look at it from a common sense perspective, if you have a 3 teir program, UI->BLL->Data,
shouldn't each one of these know how to handle data being passed in and out of it? How are you going to display something you know nothing about?
Second of all, why?

Now, if you want flexiblity in the things that your display layer can show
thats where interfaces come in, in which case you can define a structure
that both parties (the application and the business logic or business logic and data) have to conform to in order to "communicate" with one another. A standard if you will. A good example of this is the IList interface, which is used to like mad between windows forms controls (as well as ASP.NET) and whatever implements IList.

Now, can all this be encapsulated into a single executable known as the
program, sure. I've heard arguments that says all your BL should be in a
DLL and your data should be in a DLL, etc... I personally only do it when I know I'm going to resuse a library, but for stuff that is 100% proprietary, I just put it into the executable. And I use interfaces to talk between
these layers often times so I have some conformity and gives me the
possiblities of expansion (though you could ask the questoin, what if your
interface changes, in which case we are in a whole new realm. =))

.NET uses this idea extensivly with Datasets, in which case these are
basically the "packages" you are talking about that is offered by the
datalayer, BL can do stuff with it, and your UI can display it because it
implements several interfaces common between the UI and the DL.

I hope this answered your question some, I'm tired, haven't slept for awhile and really don't know what I'm saying anymore. So if you have more
questions, or anytone wants to just take my idea and tear it up, cool. =)

-CJ

"William H. Burling" <wh*******@earthlink.net> wrote in message
news:i9******************@newsread1.news.atl.earth link.net...
I am not sure I understand encapsulation.

I thought that one of the objectives in OOPs is to
hide data structures from other objects so that
they did not have to know how to unpack them.

However, in some instances, it seems that passing
a data structure greatly reduces the number of accesses
one might have to make between objects. Ie:
a simple database might present an "offering" (which is
really in the form of a data structure) to a display object so that a

person
can make a data selection. Then the selection (which could represent
multitudes of records) could be passed back to the database. The problem

is
that the display object would now have to know how to unpack the

"offering"
and then how to pack it back up
to send a subset of the offering back.

How does OOPS cope with this fundamental problem?

I realize that I could integrate the display module into
the database module but it seems that I am just heading back to the old

days
when one had merely one object
"The Program". Should not I be able to break the problem down so that I
encapsulate the database
independently from the display interface....and yet
allow for reasonable communication between them
of massive amounts of data?

Please help me to understand this issue.

Thank you,

Bil


Nov 20 '05 #3

P: n/a
"William H. Burling" <wh*******@earthlink.net> wrote in
news:i9******************@newsread1.news.atl.earth link.net:
The problem is
that the display object would now have to know how to unpack the
"offering" and then how to pack it back up
to send a subset of the offering back.


You can make the DB object pass a "Record object". The display class then
formats/displays the object as required and returns a Record object back to
the DB object.

You can pass anything between objects - single variables, arrays,
structures, objects, etc. etc.
--
Lucas Tam (RE********@rogers.com)
Please delete "REMOVE" from the e-mail address when replying.
http://members.ebay.com/aboutme/coolspot18/
Nov 20 '05 #4

P: n/a
Hi Bill,

I'm in a silly mood so you get a silly example. ;-)

A man is buying Chinese food for himself, his wife and his daughter. Each
person wants it from a different shop.

He walks into the first and orders. The server disappears and reappears
later with the food in industry standard boxes. Our man does the same in the
other two shops and goes home.

In the first shop, the chef gets fresh raw ingredients, prepares them and
cooks them up in freshly made sauces. In the second shop, pre-prepared
ingredients are put together with sauces bought in from a bulk supplier. In
the third shop, complete meals (actually prepared by the first shop) are taken
out of the freezer and reheated.

That's encapsulation. Same ordering, same/similar menu, same packaging.
Totally different production. That's what encapsulation is hiding - the method
by which an object serves up its content.

The man goes home with his three meals and ponders on how he can walk into
each shop, speak to a Chinese person in English (though they write the order
in Chinese), pay with the same currency and walk out with standard boxes and
cups containing very familiar food.

That's an interface (and polymorphism in action). He enacts the same
procedure for the man at each shop as they all have inherent Chinese-Shopness
(though in one he stood in bright light at a counter where a TV was blaring
out with some sport, while in another he sat in subdued luxury, next to a tank
of bright tropical fish with soft Chinese music playing).

Actually, the third shop was a laundry, but by asking for Mr Wong (not his
wife, who ran the laundry), our man was able to get his food prepared. That's
because although Mr Wong had inherited his father's laundry, he had always
wanted a restaurant (his wife wouldn't let him go that far) and so he
implemented a Chinese-take-away interface.

On getting home, our man opens the packaging and puts some items into the
fridge, some into the oven to warm while others go straight onto the table.
Some of the packaging goes in the rubbish bin, some into a recycling
container. He knows exactly what to do with the food and eventually creates a
lovely display for the family to sit at and eat.

Our man has to know what to do with food and how to prepare it. His
daughter is only 6 so she doesn't really have a clue (nor does she care that
much - what's a Dad for, after all?). He's proud of his expertise - that's
being a bachelor he says to himself.. Sometimes, though, he wishes that he
knew how to cook it as well.

=================================
I've no idea what you made of that. - just a bit of fun. :-))
=================================

Getting to your situation now.

The Total OOP method would have an object for everything, of course.
Hotel, Guest, Room, DryCleaner, DryCleaningItem, DryCleaningItemList, Invoice,
DryCleaningInvoice, InvoiceStore (Excel workbook), Period, BillingPeriod, etc,
etc.

The DryCleaningInvoice would contain its Date, InvoiceNumber plus
references to its InvoiceStore, Hotel, Guest and DryCleaningItemList.

The DryCleaningInvoice would present an interface much as you described in
your post - It can give you the individual properties and it can provide the
DryCleaningItemList. The DCIList would be able to serve individual DCItems.
These would be able to give you their individual properties - and each
property would, in turn, be able to provide different renditions of itself for
different purposes.

Most often, a single rendering function, ToString, is sufficient, but some
objects provide a ToString with formatting. Other objects need more and
provide functions - MeAsThis and MeAsThat. A user of such an object needs to
know which property it wants, which form it wants it an and where to put it
once it's got it. How the object produces each of these forms is none of its
concern, however.

The parallel with our Chinese Food story now breaks down a bit. Our man
had to know what to do with his food - he even had to do some more work on it,
(such as cutting the fat off the pork for his daughter). In an OOP scenario,
the food would have unpacked itself and heated/cooled/defatted/etc as
required. It would still be up to the man to bring it to the table, however.

Your task is the storage of these Invoices. You are in the position of the
Chinese shops in that you know about the underlying storage and maniupulation
of the data, ie Excel workbooks. It'll be your task (as an Invoice) to get the
data from the workbook and parcel it up to go out to the users in your
standard boxes. These boxes are the other objects - DCInvoice, DCItemList,
DCItem. These may be designed totally with the convenience of the end user in
mind leaving you a lot of work preparing the data for that interface. Or you
could design it with your ease in mind and leave more work for the end user.
The more work you do for them, though, the more they will thank you (no they
won't they'll take you for granted!!) as the task of using your facilities
will be easier. What you certainly <won't> do is give any hint of Excellness.

If your users need to do some special processing, then, if it is likely to
be used elsewhere or frequently (ie it's not so special), or is tricky (ie
it's really special), or for other reasons, you would move that logic into
your objects - this way you can guarantee the work. It depends on how you want
to divide the labour.

Well, that's enough of that. I've enjoyed this one - I hope you have too,
and found it of some use. :-)

Your fortune cookie says: 'A man with a simple face may hide deep
thoughts'.

Regards,
Fergus
Nov 20 '05 #5

P: n/a
Cor
Hi Fergus,
I buy mostly the ingredients and make it myself.
Sometimes it is delicious sometimes it is terible, but always the next time
better.
:-)
Cor
Nov 20 '05 #6

P: n/a

"William H. Burling" <wh*******@earthlink.net> wrote in message
news:KI******************@newsread1.news.atl.earth link.net...
CJ,

Thank you for responding.

I apparently did not appreciate that interfaces do not have to be simple. By simple I mean a single value
with a data type of byte, char, word, long. I was under the impression that perhaps slightly more complicated
properties could exist but none more complicated than a single dimensional
array all array elements the same.
ie: all marbles or all bowties.

Keep remembering object oriented programming. Everything is an object,
therefore they can be as simple or as complex as you want. Interfaces
consist of objects, which can be classes, properties, methods, or even other
interfaces. Be as complex as you want to be. =0
Perhaps that is what the IList is about(a form of an array?). I don't know
anything about the IList but suspect it is an object that
is passed between objects and everybody knows how to read it (as they know
its properties and methods)
Exactly. You don't know what type of object it is necessarily (like you
would with Early Binding) because it could be inherited or whatever or
designed a different way. But those common properties exist, in which case
can be used in other "objects". It's just an agreement.
But i do not know if the properties are simple. All the "controls" that I
know of in windows programming
seem to have only "simple" (no complex data structures) properties. Are the Ilist properties "simple"? or are the arguments
of the methods "simple"?

Actually, programming controls are pretty complex and pretty simple.
Complex in the way they give you flexibility to do what you want, but simple
enough so you don't reinvent the wheel every time you use it.

Which is good that you bring up IList in that case. Because so many
controls (especially databound controls) use the IList interface. Obviously
to list data in the control and maniuplate as needed. Now, why the
interface? Because there are so many things, especially in programming that
could be "List" releated and require user input. By creating an interface,
we agree that there should be a common way to list this data and use the
same code over and over.

So did you underappreciate them? Yep... but most people use them when there
is no need, and 2nd, its kinda confusing at first, because when you are
learning them, you rarely see a use for them. Because of course yo are
going to be the best programmer in the world, and you will be writing all
the software so you will know all the methods...

Maybe that was just me for awhile..... =)
I was under the impression that encapsulation was centered around "hiding
the data structure" so that other members
did not have to know how to unpack it.
Still is. Members don't necessarily have to know how to unpack it. But the
agree upon these common things enough that each is satisifed. Or maybe they
aren't, but you see where I'm going.
It was my understanding that the
reason why one did not want to have a second
object unpack a data structure is that it now made a second object dependent upon another (they both had to know how
to unpack a complicated data structure). Hence that method now had to be
written twice.......making the code
less robust (as now the programmer has to remember to change the method in
two locations.
Correct. =)

for simple real world problems I can readily see how to do that. But for
more complicated problems in which alot of
data is being exchanged.....I suddenly found the One property for one data
concept very combersome and unwieldy.

As I think about it....I am beginning to see some things. At some point one has to unpack the data. if that is the case, then
if it is too unwieldy for an interface then it will also probably be too
unwieldy inside of some code in the second object.
In both cases, one has to get at the unpacked data. Might as well be at an
interface.

True, and think about what data actually needs to be given to complete a
task. =)
Let me give you a very specific example so that you can see my plight.

i am modeling the storage of dry cleaners invoices for a hotel group.

That's pretty vague... =) j/k
each invoice has a hotel name, hotel invoice number, guest name,
guestwrittendate, guestwrittenroomnumber,
then about 40 "items". each item has the same data structure (clng type,
clothing type, PriceToGuest,
NumofclothesTobeCleanedfor each clng type and clothing type)

The invoices are currently stored in excel workbooks, each workbook
represents a year for a given hotel. each worksheet
holds invoices for one billing period for that year.

So to specifiy any given invoice, I must let the user select:
Hotel, year, billing period, invoice number
and to gain access to this invoice, i need to allow the user to retrieve the 40 items.

how does one do that without making an interface that is 4 properties plus
40*4 properties that represent the item information.
It seems absurd.

A good idea when modelling software is to keep things in small project
groups. This relates not only to development style, but the way the
software as built. You can build more than 1 interface too. Have several,
which is where I was saying pass data that you need. Don't pass it if you
really don't need it. And not saying that an interface couldn't inherit or
reference another interface. =) See where this is going? Absurd doesn't
look so absurd when you have it all nicely organized.

For example, those 40 items? Are they Name Value pairs? So could they be
put into a Single Name Value Collection so the actual amount of items
doesn't matter? And of that collection, say its a Dictionary base, where
you could have name / Object collection...

You see how this can continue to spawn into more. =) Suddenly what is
simple, is very complex at the same time. =)
I could make an interface that presents 4 properties (hotel, year, billing
period, invoice number), and then 4 more properties
that display a single item(clng type, clothing type, price, numofclothes).
To gain access to all 40 items, perhaps i need to offer
some sort of indexing mechanism to allow a user of the data to index through all 40 items through the four exposed "item" properties.

See Above.
The above, then, gives the user "simple" (no complex data structures; just
end use data) without having an excessive interface.

A compromise would be to ship all 40 items in an array in which each array element is a datastructure holding the four parts of an item.
To retrieve the item parts, a single object could be used in which an array element is "pipelined" through it where the output
is discrete end-use pieces. Since the unpacker is in a single object I have not violated my goal of having only single copies of code.
any object wanting to read this data just uses the unpacker.

Remember to understand what an object is. Inheritance is very important
here.
However.....what have i gained? a smaller interface but more complex (as now another object needs to know that it must use
an unpacking object).
Am I making sense here....am i phrasing the problem in the right way? i am sure my problem is generic. there must be vocabulary
to describe it. what is that vocabulary.

You are, and I understand your struggles. I think you come from a
background that wasn't originally OOP. And nothing wrong with that, I did
too. And its very diffucult to understand, especially when your exposed to
a non OOP lifestyle for so long.

Just remember, keep things small an organized, a single object can have
access to many many many other objects, etc, etc. Which can all be used at
different times, reasons, etc. And expanded upon.

Hopefully I made some sense with this. And if not, Cor or Fergus explained
it with a Chinese man or something.
Peace
-CJ
Thank you,
Bil

"CJ Taylor" <no****@blowgoats.com> wrote in message
news:vn************@corp.supernews.com...
Bill,

I'll try to explain this the best I can and help you get a grasp on it.

From what I read from your statements, its not only understanding
encapsulation but the idea of multi-teir development as well. The idea of separating the UI Layer from the Business Logic layer from your datalayer. (Or in Enterprise Apps UI->Facade->BLL->Data->System framework)

In which case, if this is what your questioning then I will give you a
pretty simple, yet understandable example.

As far as sending "package objects" in and out of layers and knowing how to
unpack them isn't bad. I don't think so at least. I mean look at it from a
common sense perspective, if you have a 3 teir program, UI->BLL->Data,
shouldn't each one of these know how to handle data being passed in and out
of it? How are you going to display something you know nothing about?
Second of all, why?

Now, if you want flexiblity in the things that your display layer can

show thats where interfaces come in, in which case you can define a structure
that both parties (the application and the business logic or business

logic
and data) have to conform to in order to "communicate" with one another.

A
standard if you will. A good example of this is the IList interface,

which
is used to like mad between windows forms controls (as well as ASP.NET)

and
whatever implements IList.

Now, can all this be encapsulated into a single executable known as the
program, sure. I've heard arguments that says all your BL should be in a DLL and your data should be in a DLL, etc... I personally only do it when I
know I'm going to resuse a library, but for stuff that is 100%

proprietary,
I just put it into the executable. And I use interfaces to talk between
these layers often times so I have some conformity and gives me the
possiblities of expansion (though you could ask the questoin, what if

your interface changes, in which case we are in a whole new realm. =))

.NET uses this idea extensivly with Datasets, in which case these are
basically the "packages" you are talking about that is offered by the
datalayer, BL can do stuff with it, and your UI can display it because it implements several interfaces common between the UI and the DL.

I hope this answered your question some, I'm tired, haven't slept for

awhile
and really don't know what I'm saying anymore. So if you have more
questions, or anytone wants to just take my idea and tear it up, cool. =)
-CJ

"William H. Burling" <wh*******@earthlink.net> wrote in message
news:i9******************@newsread1.news.atl.earth link.net...
I am not sure I understand encapsulation.

I thought that one of the objectives in OOPs is to
hide data structures from other objects so that
they did not have to know how to unpack them.

However, in some instances, it seems that passing
a data structure greatly reduces the number of accesses
one might have to make between objects. Ie:
a simple database might present an "offering" (which is
really in the form of a data structure) to a display object so that a

person
can make a data selection. Then the selection (which could represent
multitudes of records) could be passed back to the database. The problem
is
that the display object would now have to know how to unpack the

"offering"
and then how to pack it back up
to send a subset of the offering back.

How does OOPS cope with this fundamental problem?

I realize that I could integrate the display module into
the database module but it seems that I am just heading back to the
old days
when one had merely one object
"The Program". Should not I be able to break the problem down so that

I encapsulate the database
independently from the display interface....and yet
allow for reasonable communication between them
of massive amounts of data?

Please help me to understand this issue.

Thank you,

Bil



Nov 20 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.