Home > Archive > Visual Basic > December 2005 > What is OOP's purpose, code reuse, bug minimisation, or what?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
What is OOP's purpose, code reuse, bug minimisation, or what?
|
|
|
| Well, what is the fundamental purpose of OOP? Has it been successful
so far? Is Extreme Programming waiting in the wings to supplant it as
the Next Big Thing? What future developments are expected? Could the
procedural approach enjoy a resurrection?
MM
| |
|
|
"MM" <kylix_is@yahoo.co.uk> wrote in message
news:63ktp1hr8nkdvrh7hp9d3glo03qamfboe0@
4ax.com...
> Well, what is the fundamental purpose of OOP? Has it been successful
> so far? Is Extreme Programming waiting in the wings to supplant it as
> the Next Big Thing? What future developments are expected? Could the
> procedural approach enjoy a resurrection?
>
> MM
First off, you are jumbling several technologies that are only loosely
related.
Object-Oriented Programming is a combination of several basic
methods/principles: a structural method, a 'reliability' discipline,
classification techniques, abstract data types, &etc.
Extreme Programming is merely a process method to create solutions. It is
often rooted in OOP technologies (but wouldn't have to be), and thus will in
no way supplant OOP.
'Procedural' has many definitions. It is usually used today to refer to
non-OO structured code. As OO has definitely 'won' the hearts and minds of
modern software development, while procedural methods have their place, I
can't imagine a revivial of structural programming.
The next "Great Thing" is already among us, it is the inevitable blending of
Unified, Agile, Aspect, and <place_your_favorite_here> methods into a single
menu - one can pick those pieces that make sense in their problem domain -
and use it.
-ralph
| |
| mayayana 2005-12-13, 6:56 pm |
| Interesting questions.
When all the hype and fashion are taken out
of the issue, isn't it really just about what level
one is working at? People can work with
assembly or use a higher level API coming
from DLLs. People can work with the API
or use pre-prepared objects. People can
use objects or they can use finished software
and just click buttons to accomplish their goal.
Maybe I'm oversimplifying, but that seems the
gist of it to me. I don't see why so many people
want to compare those options as equivalent
choices, where one is better than the other or
one is "out of date". That's like saying farming is
out of date and the new, improved way to get
food is to just start at the level of cooking. (Or
to adapt that analogy to procedural vs. OOP, it's
like saying that cooking is out of date and the
the new, better way to make a meal is through
"reheating".)
--
mayayanaXX1a@mindXXspring.com
(Remove Xs for return email.)
MM <kylix_is@yahoo.co.uk> wrote in message
news:63ktp1hr8nkdvrh7hp9d3glo03qamfboe0@
4ax.com...
> Well, what is the fundamental purpose of OOP? Has it been successful
> so far? Is Extreme Programming waiting in the wings to supplant it as
> the Next Big Thing? What future developments are expected? Could the
> procedural approach enjoy a resurrection?
>
> MM
| |
|
| On Tue, 13 Dec 2005 08:51:25 -0600, "Ralph"
<nt_consulting64@yahoo.com> wrote:
>
>"MM" <kylix_is@yahoo.co.uk> wrote in message
> news:63ktp1hr8nkdvrh7hp9d3glo03qamfboe0@
4ax.com...
>
>First off, you are jumbling several technologies that are only loosely
>related.
But nevertheless related, for even classes contain procedural code at
the basic level. And XP is said to have failed miserably, being
largely hype, rather like OOP, although I accept that some OOP designs
may actually work to some degree. However, I believe that the
fundamental reason why so many modern IT projects fail is because
modern software design makes them far more complex than they need to
be to accomplish the goal that the client actually wanted to achieve.
>Object-Oriented Programming is a combination of several basic
>methods/principles: a structural method, a 'reliability' discipline,
>classification techniques, abstract data types, &etc.
>
>Extreme Programming is merely a process method to create solutions. It is
>often rooted in OOP technologies (but wouldn't have to be), and thus will in
>no way supplant OOP.
>
>'Procedural' has many definitions. It is usually used today to refer to
>non-OO structured code. As OO has definitely 'won' the hearts and minds of
>modern software development, while procedural methods have their place, I
>can't imagine a revivial of structural programming.
>
>The next "Great Thing" is already among us, it is the inevitable blending of
>Unified, Agile, Aspect, and <place_your_favorite_here> methods into a single
>menu - one can pick those pieces that make sense in their problem domain -
>and use it.
Aren't all these buzz words and associated methodologies just
complicating IT design even more? At the end of the day, here's a
"bit" of data: Send it somewhere, store it, retrieve it, manipulate
it, test it. Isn't that what all computing is about?
MM
| |
| Jan Hyde 2005-12-13, 6:56 pm |
| MM <kylix_is@yahoo.co.uk>'s wild thoughts were released on
Tue, 13 Dec 2005 15:44:06 +0000 bearing the following fruit:
>On Tue, 13 Dec 2005 08:51:25 -0600, "Ralph"
><nt_consulting64@yahoo.com> wrote:
>
>
>But nevertheless related, for even classes contain procedural code at
>the basic level. And XP is said to have failed miserably, being
>largely hype, rather like OOP, although I accept that some OOP designs
>may actually work to some degree. However, I believe that the
>fundamental reason why so many modern IT projects fail is because
>modern software design makes them far more complex than they need to
>be to accomplish the goal that the client actually wanted to achieve.
>
>
>Aren't all these buzz words and associated methodologies just
>complicating IT design even more? At the end of the day, here's a
>"bit" of data: Send it somewhere, store it, retrieve it, manipulate
>it, test it. Isn't that what all computing is about?
>
LOL sounds like you're saying
Brain surgery: Open the skull, fix the issue, close the
skull - why bother learning medicine for all those years,
doesn't it just complicate things?
Jan Hyde (VB MVP)
--
What do you get when you cross a snowman with a vampire? Frostbite.
| |
| Jim Mack 2005-12-13, 6:56 pm |
| Jan Hyde wrote:
=20
> LOL sounds like you're saying
>=20
> Brain surgery: Open the skull, fix the issue, close the
> skull - why bother learning medicine for all those years,
> doesn't it just complicate things?
Well, there's another question in there -- is brain surgery the right =
remedy when you have a headache?
I can't argue against OOP as a technology, but I can argue against it as =
a religion. As good as it may be for certain problems or problem =
domains, it shouldn't be the only tool on your belt.
I'm always wary of best-ever "do-all" new new things (methodologies or =
languages). Invariably they're extended into areas where they're ill =
suited. As important as it is to grasp new things, it's just as =
important not to lose one's perspective. You don't fully understand a =
technology until you know when not to use it.
Not directed at you, just an observation...
--=20
Jim Mack
MicroDexterity Inc
www.microdexterity.com
| |
| Mike Williams 2005-12-13, 6:56 pm |
| "Jim Mack" <jmack@mdxi.nospam.com> wrote in message
news:Oz6Gs$$$FHA.2320@TK2MSFTNGP11.phx.gbl...
> You don't fully understand a technology until you know when not to use it.
Well said. Brilliant! I agree completely.
Mike
| |
|
| On Tue, 13 Dec 2005 15:51:04 +0000, Jan Hyde
<StellaDrinker@REMOVE.ME.uboot.com> wrote:
>MM <kylix_is@yahoo.co.uk>'s wild thoughts were released on
>Tue, 13 Dec 2005 15:44:06 +0000 bearing the following fruit:
>
>LOL sounds like you're saying
>
>Brain surgery: Open the skull, fix the issue, close the
>skull - why bother learning medicine for all those years,
>doesn't it just complicate things?
So you're saying that modern programming needs to be as complex as
brain surgery?
MM
| |
| Jan Hyde 2005-12-13, 6:56 pm |
| MM <kylix_is@yahoo.co.uk>'s wild thoughts were released on
Tue, 13 Dec 2005 16:46:55 +0000 bearing the following fruit:
>On Tue, 13 Dec 2005 15:51:04 +0000, Jan Hyde
><StellaDrinker@REMOVE.ME.uboot.com> wrote:
>
>
>So you're saying that modern programming needs to be as complex as
>brain surgery?
No, I'm saying that
'At the end of the day, here's a "bit" of data: Send it
somewhere, store it, retrieve it, manipulate it, test it.
Isn't that what all computing is about?'
is an oversimplification.
Jan Hyde (VB MVP)
--
Christmas is the time of year when mother has to separate the men from the toys.
| |
|
| On Tue, 13 Dec 2005 17:06:08 +0000, Jan Hyde
<StellaDrinker@REMOVE.ME.uboot.com> wrote:
>MM <kylix_is@yahoo.co.uk>'s wild thoughts were released on
>Tue, 13 Dec 2005 16:46:55 +0000 bearing the following fruit:
>
>
>No, I'm saying that
>
>'At the end of the day, here's a "bit" of data: Send it
>somewhere, store it, retrieve it, manipulate it, test it.
>Isn't that what all computing is about?'
>
>is an oversimplification.
But you said: "sounds like you're saying..." etc etc, as if you saw
brain surgery as a suitable analogy to modern software production.
Whereas almost anyone can learn to write useful computer software, no
one can safely carry out brain surgery unless he or she has been
through very extensive medical training over a number of years.
MM
| |
|
|
"MM" <kylix_is@yahoo.co.uk> wrote in message
news:klqtp1ts21neb8l3a518sbv0ef0139lal8@
4ax.com...
> On Tue, 13 Dec 2005 08:51:25 -0600, "Ralph"
> <nt_consulting64@yahoo.com> wrote:
>
>
> But nevertheless related, for even classes contain procedural code at
> the basic level. And XP is said to have failed miserably, being
> largely hype, rather like OOP, although I accept that some OOP designs
> may actually work to some degree. However, I believe that the
> fundamental reason why so many modern IT projects fail is because
> modern software design makes them far more complex than they need to
> be to accomplish the goal that the client actually wanted to achieve.
>
in[color=darkred]
of[color=darkred]
of[color=darkred]
single[color=darkred]
domain -[color=darkred]
>
> Aren't all these buzz words and associated methodologies just
> complicating IT design even more? At the end of the day, here's a
> "bit" of data: Send it somewhere, store it, retrieve it, manipulate
> it, test it. Isn't that what all computing is about?
>
> MM
LOL
I've been setup again. <g>
I remember an ol' COBOL programmer I had in class once - just kept saying -
"Everything is just a subroutine!" Never varied - never saw any use for OO.
Left the class as unaffected as when he entered. Wrote decent code I was
told. Was well thought of and did well for himself. So yes I believe that
one can perhaps get along quite well without OO - assuming you have some 15+
years to chew on a system, know it inside and out, and can spend your days,
w s, and months keeping it running.
For the rest of us - the only safe, sane, reliable, and economical way to
build quality software, on time, is by using OO and OOP. Period.
IT projects fail for many reasons. Too much complexity is just one of a
couple of zillion. But interestingly enough projects don't fail today any
more so than they did 20 and 30 years ago - and for pretty much the same
reasons.
There is more engineering going on today and that likely colors our view. I
bet if someone took a real look (someone without something to sell, <g> )
more projects actually succeed now days and have shorter over-runs than 20
years.
It is just as easy to make a bad decision whether you are using data-centric
methods, object-centric methods, or some combination of the two.
-ralph
| |
| Dmitriy Antonov 2005-12-13, 6:56 pm |
|
"MM" <kylix_is@yahoo.co.uk> wrote in message
news:u51up11lslo7335bbifbklevearakotcvs@
4ax.com...
>
> But you said: "sounds like you're saying..." etc etc, as if you saw
> brain surgery as a suitable analogy to modern software production.
> Whereas almost anyone can learn to write useful computer software, no
> one can safely carry out brain surgery unless he or she has been
> through very extensive medical training over a number of years.
>
> MM
IMO, analogy is appropriate.
As with any other field of human activity, software development is
constantly changing. I don't think the term "Modern" is synonym to the word
"Simple". Modern state of this field is just extending the ways, how
software can be built, and giving more tools of doing this, but this by
itself doesn't simplify process overall - it just simplified some parts of
the process, while complicating others.
Same happen in most other fields: Medicine, Building Design, Astronomy and
so on.
Returning to analogy, if you use "comparable" equivalents, then you might
see that they make sense. Comparing brain surgery with everyone's ability to
develop software in general is not, IMO, correct.
Everyone can put bandage - no need for any training. Everyone can make a flu
shot - it requires some hours or days of training. Everyone can study, how
to make a brain surgery - if he spends certain amount of time studying and
practicing it. Some gifted people could successfully start doing this after
couple years of study (it is just a Law, which, generally prevents it, and
not actual readiness) and some people will never be ready, no matter how
much time they spent on this.
Everyone can design and make a wooden box for pencils - no need for training
(well, maybe some). You can design and re-build some parts of your house,
but it would require more knowledge and skills. And everyone yet can study
how to design a bridge or skyscraper. Same as with brain surgery - it may
take years until you are ready of doing this and not everyone will be able.
Everyone can open the book and, using step by step instruction, create a
"Hello World" program with a little preparation. In order to build something
useful, which is not taken from textbook or someone's sample, you still need
certain amount of time for studying and practicing. And still everyone can
try to build another Operating System or design and develop compiler for new
Programming Language. But as above, it may take many years, until you can be
ready for that after huge amount of studying, and, again, not everyone will
be able to do it (at least, not the one, which will successfully work).
There are a lot of developers with 20+ years of experience, who can do
nothing more than to build a procedure based on someone's template or given
explanation of input and output required. But not everyone (no matter, how
many years of experience) can design complex software system taking in
account all requirements, constraints, trade-offs and numerous other
factors, doing it in the most rational way and producing least amount of
defects. That was true 30 years ago and, most likely, this continues to be
years ahead, no matter how more "modern" the process become.
Well, I don't think there is direct connection here to OOP.
Dmitriy.
| |
| J French 2005-12-14, 7:55 am |
| On Tue, 13 Dec 2005 13:48:37 +0000, MM <kylix_is@yahoo.co.uk> wrote:
>Well, what is the fundamental purpose of OOP? Has it been successful
>so far? Is Extreme Programming waiting in the wings to supplant it as
>the Next Big Thing? What future developments are expected? Could the
>procedural approach enjoy a resurrection?
OOP is just a fancy name for what many people have been doing for
years.
Consider :-
DoSomeProcedure( SomeData )
and
SomeData.DoSomeProcedure
Under the hood they are both the same thing, but I must confess the
second looks nicer to work with.
Bolted onto OOP are 'Events' which are really CallBacks, yet again,
nothing new, although they were tricky in older BASICs
Another thing is 'polymorphism' which is not new, all that happens is
that the code takes a good look at the data passed in and behaves
slightly differently.
Then we get 'inheritence', also nothing much new, and  ly not really
implemented in VB5/6
Having said all that, shoving things in Classes and using RaiseEvents
makes VB code a lot easier to follow (less spaghetti like) and
wrapping graphical controls in UserControls makes nice neat bundles
that are eminently re-useable
- OOP is really just another implementation of 'Black Box'
programming, which does make things simpler and easier to debug.
I've no idea what 'extreme programming' is
- and rather doubt that I'll buy into it until it is old technology
| |
|
| On Tue, 13 Dec 2005 14:17:04 -0500, "Dmitriy Antonov"
<antonovdima@netzero.net_NOT_FOR_SPAM> wrote:
>
>"MM" <kylix_is@yahoo.co.uk> wrote in message
> news:u51up11lslo7335bbifbklevearakotcvs@
4ax.com...
>
>IMO, analogy is appropriate.
>
>As with any other field of human activity, software development is
>constantly changing. I don't think the term "Modern" is synonym to the word
>"Simple". Modern state of this field is just extending the ways, how
>software can be built, and giving more tools of doing this, but this by
>itself doesn't simplify process overall - it just simplified some parts of
>the process, while complicating others.
>
>Same happen in most other fields: Medicine, Building Design, Astronomy and
>so on.
>
>Returning to analogy, if you use "comparable" equivalents, then you might
>see that they make sense. Comparing brain surgery with everyone's ability to
>develop software in general is not, IMO, correct.
>
>Everyone can put bandage - no need for any training. Everyone can make a flu
>shot - it requires some hours or days of training. Everyone can study, how
>to make a brain surgery - if he spends certain amount of time studying and
>practicing it. Some gifted people could successfully start doing this after
>couple years of study (it is just a Law, which, generally prevents it, and
>not actual readiness) and some people will never be ready, no matter how
>much time they spent on this.
>
>Everyone can design and make a wooden box for pencils - no need for training
>(well, maybe some). You can design and re-build some parts of your house,
>but it would require more knowledge and skills. And everyone yet can study
>how to design a bridge or skyscraper. Same as with brain surgery - it may
>take years until you are ready of doing this and not everyone will be able.
>
>Everyone can open the book and, using step by step instruction, create a
>"Hello World" program with a little preparation. In order to build something
>useful, which is not taken from textbook or someone's sample, you still need
>certain amount of time for studying and practicing. And still everyone can
>try to build another Operating System or design and develop compiler for new
>Programming Language. But as above, it may take many years, until you can be
>ready for that after huge amount of studying, and, again, not everyone will
>be able to do it (at least, not the one, which will successfully work).
>
>There are a lot of developers with 20+ years of experience, who can do
>nothing more than to build a procedure based on someone's template or given
>explanation of input and output required. But not everyone (no matter, how
>many years of experience) can design complex software system taking in
>account all requirements, constraints, trade-offs and numerous other
>factors, doing it in the most rational way and producing least amount of
>defects. That was true 30 years ago and, most likely, this continues to be
>years ahead, no matter how more "modern" the process become.
>
>Well, I don't think there is direct connection here to OOP.
But has OOP helped or hindered the progress to ever more enlightened
software design? Where are the vast repositories of code waiting to be
reused? I should have thought that by now any software proposition
would be achievable simply by bolting together large enough chunks of
repository code, however, I would also have to believe that cloud
cuckoo land were just around the corner.
I see a bridge, an old bridge. One that was built in the 1700s. It's a
solid structure all right! It hasn't fallen down, despite once
carrying foot traffic, then the occasional rider on horseback,
followed by carts and now tractors. Still it stays. There, it seems,
for all eternity. Simple. Straightforward. Serving a purpose.
Imagine how the bridge might have fared if an army of white-coated
specialists fresh from uni and as far away from Inkey$ as Bush is from
victory in Iraq had descended upon the countryside, demanding that
bridges be constructed according to their deliberations. "No, you
cannot be serious! That bridge you've built is far too massive and is
a waste of bricks!" Then they proceed to design their own lightweight
version, which starts to wobble as soon as people set foot on it so
that they are forced to revisit their design and patch it up.
MM
| |
| Jim Mack 2005-12-14, 7:55 am |
| MM wrote:
>=20
> I see a bridge, an old bridge. One that was built in the 1700s. It's a
> solid structure all right! It hasn't fallen down, despite once
> carrying foot traffic, then the occasional rider on horseback,
> followed by carts and now tractors. Still it stays. There, it seems,
> for all eternity. Simple. Straightforward. Serving a purpose.
>=20
> Imagine how the bridge might have fared if an army of white-coated
> specialists fresh from uni and as far away from Inkey$ as Bush is from
> victory in Iraq had descended upon the countryside, demanding that
> bridges be constructed according to their deliberations. "No, you
> cannot be serious! That bridge you've built is far too massive and is
> a waste of bricks!" Then they proceed to design their own lightweight
> version, which starts to wobble as soon as people set foot on it so
> that they are forced to revisit their design and patch it up.
There's an old saying in engineering: Anyone can build a bridge that =
stands -- it takes an engineer to build a bridge that barely stands.
That initially sounds like a knock, but really it expresses a core truth =
of the discipline.
--=20
Jim
| |
| J French 2005-12-14, 7:55 am |
| On Wed, 14 Dec 2005 10:34:13 +0000, MM <kylix_is@yahoo.co.uk> wrote:
<snip>
>Imagine how the bridge might have fared if an army of white-coated
>specialists fresh from uni and as far away from Inkey$ as Bush is from
>victory in Iraq had descended upon the countryside, demanding that
>bridges be constructed according to their deliberations. "No, you
>cannot be serious! That bridge you've built is far too massive and is
>a waste of bricks!" Then they proceed to design their own lightweight
>version, which starts to wobble as soon as people set foot on it so
>that they are forced to revisit their design and patch it up.
Nice example, but you really mean Victorian engineering, and I guess
you are referring to the bridge over the Thames to the New Tate.
However, there are advantages in using things like UserControls and
Classes, they box things up nicely and using Classes instead of .BAS
modules really helps restrict Scope.
Incidentally, it is quite possible, and fairly easy, to write a
substantial App that relies on a variation of InKey, and is strictly
procedural.
I regard this sort of stuff as a 'smorgasbord', one uses what one
reckons best for the task
- for example I am an avid user of UserControls and Classes, but never
make OCXes or AX DLLs, in the good old DOS days nothing stopped me
re-using library code from .LIB files ...
On balance I agree with your cynicism, but there are some useful
things in the pile of bullsh*t
The trouble is that (I reckon) the people who designed VB had an
interesting idea of how the language should be used, and where they
wanted to take it
- but neither are obvious from what we see
| |
| Stefan Berglund 2005-12-14, 6:57 pm |
| On Wed, 14 Dec 2005 10:34:13 +0000, MM <kylix_is@yahoo.co.uk> wrote:
in <vksvp19bdddg85375ca6fnt74inekdij5g@4ax.com>
>On Tue, 13 Dec 2005 14:17:04 -0500, "Dmitriy Antonov"
><antonovdima@netzero.net_NOT_FOR_SPAM> wrote:
>
>
>But has OOP helped or hindered the progress to ever more enlightened
>software design? Where are the vast repositories of code waiting to be
>reused? I should have thought that by now any software proposition
>would be achievable simply by bolting together large enough chunks of
>repository code, however, I would also have to believe that cloud
>cuckoo land were just around the corner.
>
>I see a bridge, an old bridge. One that was built in the 1700s. It's a
>solid structure all right! It hasn't fallen down, despite once
>carrying foot traffic, then the occasional rider on horseback,
>followed by carts and now tractors. Still it stays. There, it seems,
>for all eternity. Simple. Straightforward. Serving a purpose.
>
>Imagine how the bridge might have fared if an army of white-coated
>specialists fresh from uni and as far away from Inkey$ as Bush is from
>victory in Iraq had descended upon the countryside, demanding that
>bridges be constructed according to their deliberations. "No, you
>cannot be serious! That bridge you've built is far too massive and is
>a waste of bricks!" Then they proceed to design their own lightweight
>version, which starts to wobble as soon as people set foot on it so
>that they are forced to revisit their design and patch it up.
>
>MM
<applause>
Most excellent allegory.
</applause>
---
Stefan Berglund
| |
| Stefan Berglund 2005-12-14, 6:57 pm |
| On Wed, 14 Dec 2005 10:04:25 +0000 (UTC), erewhon@nowhere.uk (J French) wrote:
in <439fea6e.431351568@news.btopenworld.com>
>On Tue, 13 Dec 2005 13:48:37 +0000, MM <kylix_is@yahoo.co.uk> wrote:
>
>
>OOP is just a fancy name for what many people have been doing for
>years.
>
>Consider :-
>
> DoSomeProcedure( SomeData )
>and
> SomeData.DoSomeProcedure
>
>Under the hood they are both the same thing, but I must confess the
>second looks nicer to work with.
>
>Bolted onto OOP are 'Events' which are really CallBacks, yet again,
>nothing new, although they were tricky in older BASICs
>
>Another thing is 'polymorphism' which is not new, all that happens is
>that the code takes a good look at the data passed in and behaves
>slightly differently.
>
>Then we get 'inheritence', also nothing much new, and ly not really
>implemented in VB5/6
>
>Having said all that, shoving things in Classes and using RaiseEvents
>makes VB code a lot easier to follow (less spaghetti like) and
>wrapping graphical controls in UserControls makes nice neat bundles
>that are eminently re-useable
>- OOP is really just another implementation of 'Black Box'
>programming, which does make things simpler and easier to debug.
>
>I've no idea what 'extreme programming' is
>- and rather doubt that I'll buy into it until it is old technology
>
Yes, this strikes at the heart of the present situation regarding our so called
benefactor microsoft.
microsoft is .NOT a technology company. microsoft is .NOT a software company.
microsoft is .NOThing more than an overblown marketing firm.
---
Stefan Berglund
| |
| J French 2005-12-15, 7:55 am |
| On Wed, 14 Dec 2005 10:33:44 -0800, Stefan Berglund
<keepit@in.thegroups> wrote:
<snip>
>Yes, this strikes at the heart of the present situation regarding our so called
>benefactor microsoft.
>
>microsoft is .NOT a technology company. microsoft is .NOT a software company.
>microsoft is .NOThing more than an overblown marketing firm.
I'm inclined to agree with you
- however, my instinct is that they are digging a pit for themselves
|
|
|
|
|