Object Orientated Programming Advice

  • Thread starter Thread starter aaj
  • Start date Start date
A

aaj

Hi

I'm not sure if I'm in the correct group but I'm after some advice on Object
Orientated Programming concepts.

I've move from structured programming into VB.NET. I can grasp the language
syntax Ok, but I'm having a few problems with the ideas of OOPS.

As an exercise I am converting some of my old VB6 code into VB.NET, trying
to look at what it does and splitting it into Interface, entity and control
classes, and I can get bits to work fine, but I don't think I'm solving the
problems using an 'OOPS' methology. I keep finding myself thinking of
classes as groups of functions rather than Objects.

In all honesty, what I have done so far seems to be more unwieldy that when
I used sequential methods. So what I'm looking for is some good information
on the web, or good books that cover the thought processes of OOPS,
inparticular how objects interact with each other and how the control should
be sequenced.

I hope this makes sense

many thanks

Andy
 
Hi

I'm not sure if I'm in the correct group but I'm after some advice on Object
Orientated Programming concepts.

I've move from structured programming into VB.NET. I can grasp the language
syntax Ok, but I'm having a few problems with the ideas of OOPS.

As an exercise I am converting some of my old VB6 code into VB.NET, trying
to look at what it does and splitting it into Interface, entity and control
classes, and I can get bits to work fine, but I don't think I'm solving the
problems using an 'OOPS' methology. I keep finding myself thinking of
classes as groups of functions rather than Objects.

In all honesty, what I have done so far seems to be more unwieldy that when
I used sequential methods. So what I'm looking for is some good information
on the web, or good books that cover the thought processes of OOPS,
inparticular how objects interact with each other and how the control should
be sequenced.

I hope this makes sense

many thanks

Andy
Click to expand...

Andy,

I recommend to read "Agile Software Development - Principles, Patterns, and
Practices" from Robert C. Martin.

This book introduces you to object oriented software development including
Design Patterns. And it shows you modern development approaches like test
driven development and refactoring.

Drawback: All code examples (and there are a lot) are written either in
Java or C++. That doesn't matter to learn OO principles, because they are
the same, in all OO languages. But you must be able to read the Java/C++/C#
syntax.

Agile Software Development - Principles, Patterns, and Practices
Robert C. Martin
Prentice Hall
ISBN 0-13-597444-5
 
Thanks for the 2 ideas so far, Ill look at buying them today.

How did you guys find the transition, or were you brought up with the 'OOPS'
way of thinking

Andy
 
Thanks for the 2 ideas so far, Ill look at buying them today.

How did you guys find the transition, or were you brought up with the 'OOPS'
way of thinking
Click to expand...


Pascal -> C -> Ada -> C++ -> C#
1988 1995 1996 1997 2002
(of course, there where some others, like Assembler, VB, Java, etc.)

It's a long way from procedural programming to "real" oo programming. OO is
not just about knowing what a class, an interface or an object is. That's a
complete different way of thinking. Even using classes (because you learned
the syntax) allows you with no problem to do plane old procedural
programming. And my experience shows, that a lot of so called 'OO
programmers' exactly do that.

So getting a real OO programmer is a long way (maybe you're a genious, of
course than it's not).

Another interesting book for you may be:
Object Thinking
David West
Microsoft Press
ISBN 0-7356-1965-4

That's a book with no (or allmost no) source code in it. It's really a book
showing you how to think object oriented. Thinking object oriented is the
base requirement to write good OO code.
 
Thats it in a nut shell!!!

I'm using vb.net, but I'm sure I'm thinking about the solutions in a
procedural fashion rather than as true objects.

thanks again

Andy
 
Hello aaj,

VB4 -> VB5 -> VB6 -> C#... I'm fairly new, but have really taken strides
to improve my skills. I've taken it upon myself to learn other languages
(Java and C++).

The hardest part was understanding the concepts. Just because you have classes
does *not* mean you're doing OOP. Its very easy to create a gigantic ball
of mud using OOP techniques when you're not familiar with them.

The key thing, in my opinion, is to start small. Don't go developing an enterprise
system after reading those books. Baby steps. Secondly, there is a wealth
of information on the web on how to effectively leverage the OOP principles
resulting in loose coupling and high cohesion. Study as much as you can.

It's a steep learning curve to get over, but once you do, the rewards are
well worth it. Also, feel free to ask here if you have questions. Most people
here are glad to help.
 
Andy,
while its important to understand OOP concepts, esp. in terms of how it
relates to use of NET framework and language syntax, i think its also
important to realize that OOP as a goal in itself is not important. In fact
depending on the type of application youre building it could be
counterproductive to place too much emphasis on making your design "OOP".
For example typical database-driven business applications should not, IMO, be
designed to be OOP-pure. If you study best-practice and design guidelines
from MSFT themselves you will see that they do not emphasize taking an OOP
approach, ie. witness .NET Pet Shop vs. Java Pet Shop. They clearly promote
a more data-centric approach, as opposed to worrying about creating and
maintaining state for collections of Customers and Orders and OrderDetails,
which is not useful except in tutorials about OOP, IMO.

so my point is: dont stress out or get discouraged if something youre doing
doesnt seem OOP enough! Just because youre using a OOP language doesnt mean
you need to or should adhere to OOP purity.

aaj said:
Thats it in a nut shell!!!

I'm using vb.net, but I'm sure I'm thinking about the solutions in a
procedural fashion rather than as true objects.

thanks again

Andy
Click to expand...
 
Thanks for the advice

The program I'm converting seems to be just as you describe, and I haven't
been able to decide if its my lack of OOP's thinking or infact it just isn't
suited to it.

Its a program that reads in lots of data from a variety of text files, it
then processes the raw data, performs some checks and then updates the
database.

Typical thoughts that run through my mind are something like whats an
object, is it each of the raw text files, is it a line of raw CSV data in
the text file, is it a piece of data between the commas, is it the IO
handler, how do they influence each other.........?????

Even though I'm finding what I'm doing long winded and complicated, I can
already see benefits, I'm just waiting for the penny to drop and hopefully
everything will fall into place!!!

thanks again

Andy


idi_amin said:
Andy,
while its important to understand OOP concepts, esp. in terms of how it
relates to use of NET framework and language syntax, i think its also
important to realize that OOP as a goal in itself is not important. In
fact
depending on the type of application youre building it could be
counterproductive to place too much emphasis on making your design "OOP".
For example typical database-driven business applications should not, IMO,
be
designed to be OOP-pure. If you study best-practice and design guidelines
from MSFT themselves you will see that they do not emphasize taking an OOP
approach, ie. witness .NET Pet Shop vs. Java Pet Shop. They clearly
promote
a more data-centric approach, as opposed to worrying about creating and
maintaining state for collections of Customers and Orders and
OrderDetails,
which is not useful except in tutorials about OOP, IMO.

so my point is: dont stress out or get discouraged if something youre
doing
doesnt seem OOP enough! Just because youre using a OOP language doesnt
mean
you need to or should adhere to OOP purity.
Click to expand...
 
In line
Thanks for the advice

The program I'm converting seems to be just as you describe, and I haven't
been able to decide if its my lack of OOP's thinking or infact it just isn't
suited to it.

Its a program that reads in lots of data from a variety of text files, it
then processes the raw data, performs some checks and then updates the
database.

Typical thoughts that run through my mind are something like whats an
object, is it each of the raw text files, is it a line of raw CSV data in
the text file, is it a piece of data between the commas, is it the IO
handler, how do they influence each other.........?????

Even though I'm finding what I'm doing long winded and complicated, I can
already see benefits, I'm just waiting for the penny to drop and hopefully
everything will fall into place!!!

thanks again

Andy
Click to expand...

Andy,

I do the same kind of stuff. I have to read a lot of text files with fixed
width columns where the lines in the files have mixed layouts. The lines are
flagged with "line type" markers though, so what I've done is constructed some
generic objects that know how to read a line by looking at it's flags.


Otis Mukinfus
http://www.otismukinfus.com
 
Back
Top