Re: Methodology

I'm not sure what you mean by procedural. I think I am object oriented
being an Access developer. I'm certainly event oriented. I look at an
object and want to know what events are available and maybe am prodecural
within the events. I don't see programming as a continuous pages of code
with subroutines and goto's.

There is a subtle (but very important) difference between object-orientation
and pseudo-object-orientation. Functions, for example, may seem
object-oriented, as you treat the block of execution statements as if it
were a single execution statement. But true object-orientation includes
Encapsulation, Abstraction, Polymorphism, and Inheritance. I talked a bit
about Abstraction, Encapsulation, and Inheritance in my post, but if you
want to really dig into it, check out the following WikiPedia article, and
the links it references:

http://en.wikipedia.org/wiki/Object-oriented_programming

One thing that may help you to understand it better is to keep in mind that
object-orientation is an abstraction in and of itself. One way to understand
this is to look at Mathematics, which is, at the core of all of it, simply
counting. Addition is counting up; subtraction is counting down.
Multiplication is addition, and division is subtraction. Algebra
incorporates the concept of working with numbers which are not yet known, by
substituting variables for those numbers. Trigonometry takes this a step
forward, by including the concept of functions, which are an encapsulation
of multiple arithmentic operations into an aggregate type. And so on.

In other words, as I mentioned before, a processor can perform exactly *one*
operation at a time. So, underneath all programming is the sequential or
procedural process. It's all done by using nested loops. What
object-orientation is, is a way of thinking about all of this without
thinking about the deep underlying details, things which are not necessary
to think about unless you're building an Operating System, for example. It
introduces concepts, tools, and techniques for working with programs in a
way which is easier and more efficient for a developer to think about and
work with.

Object-orientation is a model of computing which is closer to the "real
world" that we are accustomed to operating in. It incorporates procedural or
sequential programming at various levels, as sequence and procedure are
important at a certain level. But it takes a lot of the lower-level detail
out of the picture, that detail which we don't need to be bothered with in
order to be an effective developer.

For example, we understand the concept of a vehicle in the real world. A
vehicle is a mechanical device that transports objects from one point to
another. It may have wheels, tracks, or a cushion of air under it to perform
the mechanics of movement. It may have any number of characteristics and
still be a vehicle. But "vehicle" is not a thing; it is a type (or "class").
It is a set of properties or rules which constitute our ability to identify
a mechanical device as being a vehicle.

A car, on the other hand, must have wheels. It is a vehicle, but it is not a
truck, a plane, or a hovercraft. Again, like "vehicle," car is an abstract
concept, a set of rules by which we can identify a type (or "class") of
mechanical device. A car is a vehicle, but a vehicle is not necessarily a
car. "Car" *inherits* "Vehicle".

Now, a 2006 Toyota Matrix XR is a further abstraction, and it is not yet an
actual car. Each type in the hierarchy further defines or specifies the type
it inherits from. In OOP, we might refer to it as
Vehicles.Cars.Toyota.Matrix.XR.2006.

To refer to an actual car, we would need to create an "instance" of a 2006
Toyota Matrix XR, with all of the options specified, and built to spec. The
car itself is an object, or an "instance" of a 2006 Totyota Matrix XR. It is
not a class, but an object.

I don't want to get too deep into the actual concepts of OOP (they are
Legion), but only to give you an idea of what the abstraction, and
derivative rules of OOP provide to the developer. In the .Net platform, for
example, every class has the ancestor of System.Object. All classes share
all of the code and characteristics of System.Object. From System.Object,
each successive generation in the hierarchy is more specific, and has more
characteristics, than System.Object.

Of course, this only touches on 2 aspects of OOP, Inheritance, and
Abstraction, But you should be able to see how just these 2 pillars of OOP
provide very powerful tools for the developer, in that a well-designed
hierarchy of classes makes incredible use of reusability, and presents
programming concepts to us humans in a much more intuitive and abbreviated
fashion. Read the Wikipedia article. I think you'll enjoy the heck out of
it!

I guess I'm lost here. I don't write code over and over (other than DAO),
I write it usually once, then copy and past it then modify it. Are you
saying that creating a class is different or more advantageous?

Exactly, my friend! Note what you said: "I... copy and past it then modify
it." Now, what happens when the underlying object model changes, or a bug
you were not aware of is suddenly made apparent? Well, you have to find all
of the places you copied and pasted code, and change each one. If instead,
you create a single class, and use it in all of your projects, all you have
to do is change that one class, and all of the projects are now up to date!

It sounds like more than I want to tackle.

I suppose it may. At times I have certainly felt a bit overwhelmed with new
technologies. But on the other hand, you may eventually find it so
fascinating that you can't stop! (like I do!)

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

"Mark A. Sam" <msam@xxxxxxxxxxxxxxxxx> wrote in message
news:Ozse2%23BUGHA.4600@xxxxxxxxxxxxxxxxxxxxxxx
Hello Kevin,

Thank you for the dissertation. I understood it all. I'm going to snip
to where I want to address what you wrote:


It also seems to me however, that
your mindset remains procedural, rather than object-oriented. This is the
most important difference in the .Net platform.

I'm not sure what you mean by procedural. I think I am object oriented
being an Access developer. I'm certainly event oriented. I look at an
object and want to know what events are available and maybe am prodecural
within the events. I don't see programming as a continuous pages of code
with subroutines and goto's.


The difference between a class and an object is that a class is a pattern
or
design for objects. An object is an "instance" (working copy) of a class.

There's a good bit more to it than that,


That helped me a lot. I never had a clue what class was, and now it makes
sense, especially the inheritance part.


but I'm hoping to give you
enough
to get you interested and started, and let you take it from there.

You gave me a lot here. I don't think however that I'll get to intimately
involved the intricacies. I have a couple clients that want websites and
want me to do them, which is the only reason I am in it. After
researching and coming across Visual Web Developer, I saw that I could do
what one client wants and control the output easily with programming. I
hope to get funding to revamp the website you wrote for me years ago and
is still "truckin". When that happens, by programming days are done,
because I will hire it out to people who can do it better than me.



The beauty part is that one can design one's own classes, just as one can
design car or truck engines by combining various engine parts together in
different configurations. Once you develop a good set of configurable (or
"extensible") classes, you can re-use them in various applications which
perform similar work, without having to write them all over again.

Getting back to the code you posted, you may have noticed that similar
code
appears throughout your application. The process of opening a Connection
and fetching data, when using the same database or data source, is almost
identical. The classes of the .Net CLR are designed like engine parts, to
be useful in a large variety of configurations, to connect to any kind of
data source. But *you* Mark, are only connecting to one. So, you can
create your own "Database tier" of custom classes which perform all of
these sequences in the same way without having to rewrite all that code
over and over again.

I guess I'm lost here. I don't write code over and over (other than DAO),
I write it usually once, then copy and past it then modify it. Are you
saying that creating a class is different or more advantageous?



If you want to expand your enterprise, you can get even more
compartmentalized, by creating a business tier, which performs operations
"under the hood" without having any user interface, and a "presentation"
(user interface) tier, which exposes the business objects in a
user-friendly way. This way, you can create, for example, another
interface for the same type of applications, exposed as a Windows Form
executable, or perhaps a Web Service.

It sounds like more than I want to tackle.



At any rate, the link I posted should give you a lot of useful
information,

I'll definitely check it out and thank you for the time and effort in
writing this excellent reply.


and a lot to think about, as well as some really nice, pre-built
libraries for implementing various common "patterns" of applications.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Numbskull

Show me your certification without works,
and I'll show my certification
*by* my works.

Even so faith, if it hath not works, is dead, being alone.
Yea, a man may say, Thou hast faith, and I have works:
show me thy faith without thy works, and I will show thee my faith by my
works. James 2:17-18 (KJV)


Those that can do, those that can't become talk show hosts. Mark A. Sam




.

Relevant Pages

  • Re: an old geezer running visual studio for the first time
    ... and wants to be in control of his/her app as much as possible. ... >hard-core programming, which is why the SDK has articles and tutorials on ... >the developer to delve as deeply into the technology as one can go, ... >> can actually write more code than you could have in classic ADO. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Is MCSD worth doing?
    ... good C developer usually has to be a highly disciplined ... programming - and you don't want to hit them over with OO ... On an even more general level an understanding of Business ... >quote you stated sums it up! ...
    (microsoft.public.cert.exam.mcsd)
  • Re: Lets be honest about ASP.NET...
    ... shits all drag & drop, ... formatted pages with a bunch of place holders. ... The point was, this ain't real programming... ... The next time you meet an "ASP.NET developer", ...
    (rec.sport.pro-wrestling)
  • Re: Help with research
    ... I am an experienced OO developer and have a friend that is so too. ... We tried to do pair programming: ... I think with respect to the larger scale design we are not so different. ...
    (comp.lang.php)
  • Re: edit asp site?
    ... I had reached the end of what I could pay and said just finish it ... tires and periodic service for free during the life of the car. ... If you could actually find a new developer willing to work ...
    (alt.html)