Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #3384 > unrolled thread

Object oriented programming?

Back to article view | Back to comp.programming

Contents

  Object oriented programming? root <NoEMail@home.org> - 2013-05-29 14:25 +0000
    Re: Object oriented programming? Melzzzzz <mel@zzzzz.com> - 2013-05-29 18:19 +0200
      Re: Object oriented programming? root <NoEMail@home.org> - 2013-05-30 13:51 +0000
        Re: Object oriented programming? Melzzzzz <mel@zzzzz.com> - 2013-05-30 19:48 +0200
    Re: Object oriented programming? Patricia Shanahan <pats@acm.org> - 2013-05-29 09:21 -0700
      Re: Object oriented programming? root <NoEMail@home.org> - 2013-05-30 13:56 +0000
    Re: Object oriented programming? James Harris <james.harris.1@gmail.com> - 2013-05-29 13:05 -0700
      Re: Object oriented programming? root <NoEMail@home.org> - 2013-05-30 14:07 +0000
        Re: Object oriented programming? "osmium" <r124c4u102@comcast.net> - 2013-05-30 10:49 -0500
        Re: Object oriented programming? James Harris <james.harris.1@gmail.com> - 2013-06-01 12:18 -0700
    Re: Object oriented programming? Kicer <a@b.c> - 2013-05-29 22:13 +0200
      Re: Object oriented programming? root <NoEMail@home.org> - 2013-05-30 14:22 +0000
        Re: Object oriented programming? Kicer <a@b.c> - 2013-06-01 02:54 +0200
          Re: Object oriented programming? Patricia Shanahan <pats@acm.org> - 2013-06-01 07:43 -0700
            Re: Object oriented programming? Kicer <a@b.c> - 2013-06-05 18:16 +0200
    Re: Object oriented programming? rugxulo@gmail.com - 2013-05-30 22:22 -0700
      Re: Object oriented programming? root <NoEMail@home.org> - 2013-05-31 14:05 +0000
        Re: Object oriented programming? "Charles Hottel" <chottel@earthlink.net> - 2013-05-31 12:12 -0400
          Re: Object oriented programming? root <NoEMail@home.org> - 2013-05-31 20:31 +0000
            Re: Object oriented programming? "BartC" <bc@freeuk.com> - 2013-06-01 00:59 +0100
    Re: Object oriented programming? Willem <willem@turtle.stack.nl> - 2013-06-01 07:54 +0000
      Re: Object oriented programming? Jongware <jongware@no-spam.plz> - 2013-06-07 11:05 +0200
    Re: Object oriented programming? Paul N <gw7rib@aol.com> - 2013-06-02 13:11 -0700
      Re: Object oriented programming? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-06-03 11:06 -0700

Page 1 of 2  [1] 2  Next page →

#3384 — Object oriented programming?

My programming experience began before the advent of Object Oriented
Programming so the concepts are vague to me. It would help if
someone could sketch out how OOP would enter into some of tasks
I have done.

I have written my own text editor, the general structure is:

Initialize stuff
read in any starting text

while(1)
	display text
	accept user command
	process user command

If one were to use OOP concepts and start writing a new text
editor, how would objects change this picture?

Similarly, a program such as Mathematica would look like

Initialize stuff
Read program
Read data

while program
	interpret line
	process data

In this case steps in the program would include various operations
on the data. Not unlike the editor case.


Simpler programs, such as filters look like:

read stream
filter stream
output filtered stream

How do OOP concepts come into such program design.

Thanks for any help.

[toc] | [next] | [standalone]

#3385

On Wed, 29 May 2013 14:25:05 +0000 (UTC)
root <NoEMail@home.org> wrote:

> My programming experience began before the advent of Object Oriented
> Programming so the concepts are vague to me. It would help if
> someone could sketch out how OOP would enter into some of tasks
> I have done.
> 
> I have written my own text editor, the general structure is:
> 
> Initialize stuff
> read in any starting text
> 
> while(1)
> 	display text
> 	accept user command
> 	process user command
> 
> If one were to use OOP concepts and start writing a new text
> editor, how would objects change this picture?
> 
> Similarly, a program such as Mathematica would look like
> 
> Initialize stuff
> Read program
> Read data
> 
> while program
> 	interpret line
> 	process data
> 
> In this case steps in the program would include various operations
> on the data. Not unlike the editor case.
> 
> 
> Simpler programs, such as filters look like:
> 
> read stream
> filter stream
> output filtered stream
> 
> How do OOP concepts come into such program design.
> 
> Thanks for any help.

You would program in same way except that you write objects
and methods instead of structures and functions/procedures.
Method is function that has first parameter structure/object.
Difference is that you could write polymorphic objects,
those with virtual functions (runtime dispatch on type), but than again
perhaps it is not necessary in your case.
All in all program logic is same...

[toc] | [prev] | [next] | [standalone]

#3390

Melzzzzz <mel@zzzzz.com> wrote:
> 
> You would program in same way except that you write objects
> and methods instead of structures and functions/procedures.
> Method is function that has first parameter structure/object.
> Difference is that you could write polymorphic objects,
> those with virtual functions (runtime dispatch on type), but than again
> perhaps it is not necessary in your case.
> All in all program logic is same...
> 

Thanks for responding, but your comments are incomprehensible to
me. Can you translate them into examples with respect to
my text editor example? For instance, what would an object
be if you were writing a text editor? vi is mostly line
oriented, would an object be a line of text?

If an object were a line of text, then would one method
be something like:
MoveLineMethod (line, from place, to place)

to move the line from one place to another? Is
that something like you describe?
> 

[toc] | [prev] | [next] | [standalone]

#3395

On Thu, 30 May 2013 13:51:24 +0000 (UTC)
root <NoEMail@home.org> wrote:

> Melzzzzz <mel@zzzzz.com> wrote:
> > 
> > You would program in same way except that you write objects
> > and methods instead of structures and functions/procedures.
> > Method is function that has first parameter structure/object.
> > Difference is that you could write polymorphic objects,
> > those with virtual functions (runtime dispatch on type), but than
> > again perhaps it is not necessary in your case.
> > All in all program logic is same...
> > 
> 
> Thanks for responding, but your comments are incomprehensible to
> me. Can you translate them into examples with respect to
> my text editor example? For instance, what would an object
> be if you were writing a text editor?

How many data structures you have? Each data structure
can be object.

 vi is mostly line
> oriented, would an object be a line of text?

I don;t really know if that would be useful.

> 
> If an object were a line of text, then would one method
> be something like:
> MoveLineMethod (line, from place, to place)

Yes, but again with OOP you have to simplify , not
complicate.
Again you can recognize in your program what objects
would be.

> 
> to move the line from one place to another? Is
> that something like you describe?

Yes.
it would be line.Move(fromplace,toplace),
but than again you could have text object,
which is collection of lines,
and then text.Move(line,fromplace,toplace)
You may recognize in your program what are
objects (I guess you have data structures already).

[toc] | [prev] | [next] | [standalone]

#3386

On 5/29/2013 7:25 AM, root wrote:
> My programming experience began before the advent of Object Oriented
> Programming so the concepts are vague to me. It would help if
> someone could sketch out how OOP would enter into some of tasks
> I have done.
>
> I have written my own text editor, the general structure is:
>
> Initialize stuff
> read in any starting text
>
> while(1)
> 	display text
> 	accept user command
> 	process user command
>
> If one were to use OOP concepts and start writing a new text
> editor, how would objects change this picture?
>
> Similarly, a program such as Mathematica would look like
>
> Initialize stuff
> Read program
> Read data
>
> while program
> 	interpret line
> 	process data
>
> In this case steps in the program would include various operations
> on the data. Not unlike the editor case.
>
>
> Simpler programs, such as filters look like:
>
> read stream
> filter stream
> output filtered stream
>
> How do OOP concepts come into such program design.
>
> Thanks for any help.
>

You show only one aspect of your program structure, the sequence of
operations. Presumably, each of your programs also has data structures.
To get into an OO mindset, begin by stating the structure primarily in
terms of the data. Then associate the relevant operations with each data
structure.

Patricia

[toc] | [prev] | [next] | [standalone]

#3391

Patricia Shanahan <pats@acm.org> wrote:
> On 5/29/2013 7:25 AM, root wrote:
>> My programming experience began before the advent of Object Oriented
>> Programming so the concepts are vague to me. It would help if
>> someone could sketch out how OOP would enter into some of tasks
>> I have done.
>>
>> I have written my own text editor, the general structure is:
>>
>> Initialize stuff
>> read in any starting text
>>
>> while(1)
>> 	display text
>> 	accept user command
>> 	process user command
>>
>> If one were to use OOP concepts and start writing a new text
>> editor, how would objects change this picture?
>>
>> Similarly, a program such as Mathematica would look like
>>
>> Initialize stuff
>> Read program
>> Read data
>>
>> while program
>> 	interpret line
>> 	process data
>>
>> In this case steps in the program would include various operations
>> on the data. Not unlike the editor case.
>>
>>
>> Simpler programs, such as filters look like:
>>
>> read stream
>> filter stream
>> output filtered stream
>>
>> How do OOP concepts come into such program design.
>>
>> Thanks for any help.
>>
> 
> You show only one aspect of your program structure, the sequence of
> operations. Presumably, each of your programs also has data structures.
> To get into an OO mindset, begin by stating the structure primarily in
> terms of the data. Then associate the relevant operations with each data
> structure.
> 
> Patricia

I thought the idea of text editor implied the data structure: a chunk of text.
You can imagine that as all characters, lines, words, or whatever. If the
concept of an "object" is to be applied then does that mean one has to
choose a fixed way to consider the text, such as a group of lines?

I ask you to think about writing a text editor from an OOP standpoint.
Most people don't write their own editor, but give it a shot.

Thanks for responding.
> 

[toc] | [prev] | [next] | [standalone]

#3388

On May 29, 3:25 pm, root <NoEM...@home.org> wrote:
> My programming experience began before the advent of Object Oriented
> Programming so the concepts are vague to me. It would help if
> someone could sketch out how OOP would enter into some of tasks
> I have done.
>
> I have written my own text editor, the general structure is:
>
> Initialize stuff
> read in any starting text
>
> while(1)
>         display text
>         accept user command
>         process user command
>
> If one were to use OOP concepts and start writing a new text
> editor, how would objects change this picture?

Be careful not to mix up event-driven processing and OOP. From what
you have described it seems you might be thinking of the processing
model.

You can think of OO programming as bundling data and code together.
With OOP for a text editor you might define an object type (i.e. a
class) to represent the document and add to it functions (i.e.
methods) to process the text.

You could then set up instances of (i.e. instantiate) different
documents, each of which would use the same common code.

If the code had a method to save the file to disk and you had two
documents, doc1 and doc2, you could save then with calls such as

  doc1.save()
  doc2.save()

There would be just one save() method and it would know which instance
to save.

>
> Similarly, a program such as Mathematica would look like
>
> Initialize stuff
> Read program
> Read data
>
> while program
>         interpret line
>         process data
>
> In this case steps in the program would include various operations
> on the data. Not unlike the editor case.
>
> Simpler programs, such as filters look like:
>
> read stream
> filter stream
> output filtered stream
>
> How do OOP concepts come into such program design.

I don't know that I would use OO for such a filter, unless forced. You
could but it might not help much. Again, you may have the wrong basic
ideas about OOP.

James

[toc] | [prev] | [next] | [standalone]

#3392

James Harris <james.harris.1@gmail.com> wrote:
> On May 29, 3:25 pm, root <NoEM...@home.org> wrote:
>> My programming experience began before the advent of Object Oriented
>> Programming so the concepts are vague to me. It would help if
>> someone could sketch out how OOP would enter into some of tasks
>> I have done.
>>
>> I have written my own text editor, the general structure is:
>>
>> Initialize stuff
>> read in any starting text
>>
>> while(1)
>>         display text
>>         accept user command
>>         process user command
>>
>> If one were to use OOP concepts and start writing a new text
>> editor, how would objects change this picture?
> 
> Be careful not to mix up event-driven processing and OOP. From what
> you have described it seems you might be thinking of the processing
> model.
> 
> You can think of OO programming as bundling data and code together.
> With OOP for a text editor you might define an object type (i.e. a
> class) to represent the document and add to it functions (i.e.
> methods) to process the text.

In the case of a text editor, the data is simply a collection of
characters. Even characterizing it as a document implies more
structure than is justified. If the there are line feeds in
the data, then one might consider it as a series of lines.
If there are spaces, then one might consider the data to
be composed of words. Really it is only characters. The
number of potential operations which might be performed on the
data is unlimited. 

> 
> You could then set up instances of (i.e. instantiate) different
> documents, each of which would use the same common code.
> 
> If the code had a method to save the file to disk and you had two
> documents, doc1 and doc2, you could save then with calls such as
> 
>   doc1.save()
>   doc2.save()
> 
> There would be just one save() method and it would know which instance
> to save.

As I said above, the number of operations is unlimited. Consider
that in doc1 you want to change some occurences of THIS to THAT,
while in doc2 you want simply to delete any reference to THIS.
You use a text editor, think about all the different things you
have done and translate those into some OOP model.
>>
>> Simpler programs, such as filters look like:
>>
>> read stream
>> filter stream
>> output filtered stream
>>
>> How do OOP concepts come into such program design.
> 
> I don't know that I would use OO for such a filter, unless forced. You
> could but it might not help much. Again, you may have the wrong basic
> ideas about OOP.

What types of programs lend themselves to OOP and what don't?
> 

I am sure I don't grasp OOP, that is why I ask.
> James

[toc] | [prev] | [next] | [standalone]

#3394

root wrote:

> What types of programs lend themselves to OOP and what don't?

Data base oriented programs surely lend themselves.  You can have a reusable 
stack, linked list, tree, etc.  Reusable being the key.  In this case 
someone has already written these fundamental thingies and incorporated them 
in the System Template Library, STL.  And STL is a fundamental part of C++.

I think the best way to get started is to write your own string class. 
There is one in the STL, but writing your own is a big learning aid. A 
string class is a type on steroids, whereas a C int is wimpy by comparison. 
It will probably take a week or so to write, I actually did this and got it 
seriously wrong on my first pass. .  A vector class is a nice illustration, 
too, and easier.

Theorizing just (often) leads to snow jobs as you have already observed.

As far as what *don't* lend themselves, that is a much harder question.  IMO 
OOP is overused.  If you give someone a toolmaker's microscope they will use 
it.  Even if they are a plumber.

Be warned that C++ has a lot of stuff that isn't OOP,  I think the method 
was "As long as we've got the hood off, let's really tune this baby up." 
I'm thinking of function overloading, operator overloading, templates plus 
more I am too lazy to come up with.  If you use '+' for string 
concatenation, you are using operator overloading.  You could live without 
it. And since concatenation is not commutative, purity is not harmed.  It is 
easy to get carried away.

If I had more energy I would write a program to support a fictitious 
library.  I think OOP lends itself nicely to this, and it is open ended 
enough that I think one person could die before he finished it.  And since 
the spec is his, he can follow where his interest are.

OOP is nice, but it is FAR from a silver bullet. 

[toc] | [prev] | [next] | [standalone]

#3407

On May 30, 3:07 pm, root <NoEM...@home.org> wrote:

...

> As I said above, the number of operations is unlimited. Consider
> that in doc1 you want to change some occurences of THIS to THAT,
> while in doc2 you want simply to delete any reference to THIS.
> You use a text editor, think about all the different things you
> have done and translate those into some OOP model.

You have to write the code somewhere. OOP would be fine for a text
editor but not as a first project.

You mentioned you were doing a course in OOP. That's a good idea and
you should learn from that how to begin OO programming.

Once you have grasped how to use OOP for the basics you can start to
add inheritance and relationships to data abstraction. Then you will
be in a better position to come back to the editor if you still want
to.

>
>
>
> >> Simpler programs, such as filters look like:
>
> >> read stream
> >> filter stream
> >> output filtered stream
>
> >> How do OOP concepts come into such program design.
>
> > I don't know that I would use OO for such a filter, unless forced. You
> > could but it might not help much. Again, you may have the wrong basic
> > ideas about OOP.
>
> What types of programs lend themselves to OOP and what don't?
>
>
>
> I am sure I don't grasp OOP, that is why I ask.

Once you have done the course it will make more sense. There are
plenty of video lectures on the internet if the course you've chosen
doesn't give you what you want.

James

[toc] | [prev] | [next] | [standalone]

#3389

root wrote:

> My programming experience began before the advent of Object Oriented
> Programming so the concepts are vague to me. It would help if
> someone could sketch out how OOP would enter into some of tasks
> I have done.
> 
> I have written my own text editor, the general structure is:
> 
> Initialize stuff
> read in any starting text
> 
> while(1)
> display text
> accept user command
> process user command
> 
> If one were to use OOP concepts and start writing a new text
> editor, how would objects change this picture?
> 

You may search web for information about object oriented design.
In short: you hide implementation behind interface.
Example: your editor's engine should get constructed objects (look for 
builder or factory patterns) as an abstract interface.
There should be at least 3 objects and 3 interfaces: one pair for display, 
one for communication with user and one for command processor.

As your engine will use abstract interfaces for this 3 roles and you can (in 
your factory/builder) use various implementations and switch them according 
to situation (text/graphical user interface (or a fake one - for testing)).

regards

-- 
Michał Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519

[toc] | [prev] | [next] | [standalone]

#3393

Kicer <a@b.c> wrote:
> root wrote:
> 
>> My programming experience began before the advent of Object Oriented
>> Programming so the concepts are vague to me. It would help if
>> someone could sketch out how OOP would enter into some of tasks
>> I have done.
>> 
>> I have written my own text editor, the general structure is:
>> 
>> Initialize stuff
>> read in any starting text
>> 
>> while(1)
>> display text
>> accept user command
>> process user command
>> 
>> If one were to use OOP concepts and start writing a new text
>> editor, how would objects change this picture?
>> 
> 
> You may search web for information about object oriented design.

I have done so, in fact I am watching a lecture series on the
subject. Examples in texts such as a payroll program are not
easily translated into the types of programs I have worked
on. My text editor example seems completely unrelated to a
payroll program.

> In short: you hide implementation behind interface.

OK, I take that the "hide" part is to hide how something is done
from the rest of the program, not from the user. I take that
as dictated more from a program maintenance standpoint than any
other reason.




> Example: your editor's engine should get constructed objects (look for 
> builder or factory patterns) as an abstract interface.

I don't understand what builder or factory patterns are.

> There should be at least 3 objects and 3 interfaces: one pair for display, 
> one for communication with user and one for command processor.

Well, how is this for the display pair, the object is the block of text
which can fit into the current display, and the display object is the screen?

Can I say that a user object is a string of characters defining
operations to be performed?

The command processor is the real stumbling block for me. I can parse the
user command string for a sequence of operations, but these operations
themselves seem to define objects unique to the operations. Sometimes
the operations work on characters, sometimes lines, sometimes on the
whole block of text.

> 
> As your engine will use abstract interfaces for this 3 roles and you can (in 
> your factory/builder) use various implementations and switch them according 
> to situation (text/graphical user interface (or a fake one - for testing)).
> 
> regards

Thanks for responding.
> 

[toc] | [prev] | [next] | [standalone]

#3404

root wrote:

> Kicer <a@b.c> wrote:
>> root wrote:
> 
> I have done so, in fact I am watching a lecture series on the
> subject. Examples in texts such as a payroll program are not
> easily translated into the types of programs I have worked
> on. My text editor example seems completely unrelated to a
> payroll program.

I don't know which programming language do you use, but maybe start with 
more basic examples.


> 
>> In short: you hide implementation behind interface.
> 
> OK, I take that the "hide" part is to hide how something is done
> from the rest of the program, not from the user. I take that
> as dictated more from a program maintenance standpoint than any
> other reason.
> 

yeah ok, but there is more than one definition of hiding (which are somehow 
connected).

Consider a c/c++ program where you have .c and .h file.

.h is your interface to real stuff closed in .c/.cpp file. Your goal is to 
hide as much as possible in .c/.cpp file.

You can do the same with classes. You can prepare an abstract class which 
cannot be instantiated but which define a set of functions which will be 
provided by "implementation" class. This abstract class is an interface 
(like .h file) and the "implementation" class which will inherite from this 
interface is an "implementation".

> 
> 
> 
>> Example: your editor's engine should get constructed objects (look for
>> builder or factory patterns) as an abstract interface.
> 
> I don't understand what builder or factory patterns are.

then read about them :) For sure you will automatically get some examples 
about interface and implementation classes.

> 
>> There should be at least 3 objects and 3 interfaces: one pair for
>> display, one for communication with user and one for command processor.
> 
> Well, how is this for the display pair, the object is the block of text
> which can fit into the current display, and the display object is the
> screen?

no I rather meant it the way I described above.

> 
> Can I say that a user object is a string of characters defining
> operations to be performed?

I don't know what do you mean by "user object". You can use anything as you 
want for your list of operations to be performed but I believe that a list 
of classes describing operations would be better :)

> 
> The command processor is the real stumbling block for me. I can parse the
> user command string for a sequence of operations, but these operations
> themselves seem to define objects unique to the operations. Sometimes
> the operations work on characters, sometimes lines, sometimes on the
> whole block of text.

then You need to introduce an interface for commands and keep list of items 
which will be inheriting from this interface. Then you can close 
implementation of proper operation in a various classes inheriting from this 
interface.

Another way is to use visitor pattern (read about it:) ) which will match 
better here I think.

> 
>> 
>> As your engine will use abstract interfaces for this 3 roles and you can
>> (in your factory/builder) use various implementations and switch them
>> according to situation (text/graphical user interface (or a fake one -
>> for testing)).
>> 
>> regards
> 
> Thanks for responding.
>>

regards :)


-- 
Michał Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519

[toc] | [prev] | [next] | [standalone]

#3406

On 5/31/2013 5:54 PM, Kicer wrote:
...
> Consider a c/c++ program where you have .c and .h file.
>
> .h is your interface to real stuff closed in .c/.cpp file. Your goal is to
> hide as much as possible in .c/.cpp file.
>
> You can do the same with classes. You can prepare an abstract class which
> cannot be instantiated but which define a set of functions which will be
> provided by "implementation" class. This abstract class is an interface
> (like .h file) and the "implementation" class which will inherite from this
> interface is an "implementation".

This concept is relevant to the text editor example. The simplest ways
of representing a sequence of characters may be slow for insert and
delete if the file gets large.

If the program hides how the character sequence is implemented different
implementations can be tested and measured without affecting the rest of
the program.

Patricia

[toc] | [prev] | [next] | [standalone]

#3415

Patricia Shanahan wrote:

> On 5/31/2013 5:54 PM, Kicer wrote:
> ...
>> Consider a c/c++ program where you have .c and .h file.
>>
>> .h is your interface to real stuff closed in .c/.cpp file. Your goal is
>> to hide as much as possible in .c/.cpp file.
>>
>> You can do the same with classes. You can prepare an abstract class which
>> cannot be instantiated but which define a set of functions which will be
>> provided by "implementation" class. This abstract class is an interface
>> (like .h file) and the "implementation" class which will inherite from
>> this interface is an "implementation".
> 
> This concept is relevant to the text editor example. The simplest ways
> of representing a sequence of characters may be slow for insert and
> delete if the file gets large.
> 
> If the program hides how the character sequence is implemented different
> implementations can be tested and measured without affecting the rest of
> the program.
> 
> Patricia

yeah, exactly :)

-- 
Michał Walenciak
gmail.com kicer86
http://kicer.sileman.net.pl
gg: 3729519

[toc] | [prev] | [next] | [standalone]

#3398

Hi,

On Wednesday, May 29, 2013 9:25:05 AM UTC-5, root wrote:
>
> My programming experience began before the advent of Object
> Oriented Programming so the concepts are vague to me. It would
> help if someone could sketch out how OOP would enter into some
> of tasks I have done.
>
> (snip)
> 
> How do OOP concepts come into such program design.
> 
> Thanks for any help.

Try reading these two .PDFs (first one is only a few chapters,
second is a whole book):

1). http://edn.embarcadero.com/article/20803
http://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf

2). http://www.ssw.uni-linz.ac.at/Research/Books/
http://www.ssw.uni-linz.ac.at/Research/Books/Oberon2.pdf

[toc] | [prev] | [next] | [standalone]

#3399

rugxulo@gmail.com <rugxulo@gmail.com> wrote:
> Hi,
> 
> On Wednesday, May 29, 2013 9:25:05 AM UTC-5, root wrote:
>>
>> My programming experience began before the advent of Object
>> Oriented Programming so the concepts are vague to me. It would
>> help if someone could sketch out how OOP would enter into some
>> of tasks I have done.
>>
>> (snip)
>> 
>> How do OOP concepts come into such program design.
>> 
>> Thanks for any help.
> 
> Try reading these two .PDFs (first one is only a few chapters,
> second is a whole book):
> 
> 1). http://edn.embarcadero.com/article/20803
> http://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf
> 
> 2). http://www.ssw.uni-linz.ac.at/Research/Books/
> http://www.ssw.uni-linz.ac.at/Research/Books/Oberon2.pdf

Thanks, I downloaded the documents and will take a look. I
have a number of books on C++, but what I really need
are programming examples for the types of programs I
write, not large multi-programmer environments.

I have a suspicion that I am asking the question
"why would anyone ever need arrays" if all they
had programmed up to this point were scalar variables.

[toc] | [prev] | [next] | [standalone]

#3400

"root" <NoEMail@home.org> wrote in message 
news:koaao7$iec$2@news.albasani.net...
> rugxulo@gmail.com <rugxulo@gmail.com> wrote:
>> Hi,
>>
>> On Wednesday, May 29, 2013 9:25:05 AM UTC-5, root wrote:
>>>
>>> My programming experience began before the advent of Object
>>> Oriented Programming so the concepts are vague to me. It would
>>> help if someone could sketch out how OOP would enter into some
>>> of tasks I have done.
>>>
>>> (snip)
>>>
>>> How do OOP concepts come into such program design.
>>>
>>> Thanks for any help.
>>
>> Try reading these two .PDFs (first one is only a few chapters,
>> second is a whole book):
>>
>> 1). http://edn.embarcadero.com/article/20803
>> http://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf
>>
>> 2). http://www.ssw.uni-linz.ac.at/Research/Books/
>> http://www.ssw.uni-linz.ac.at/Research/Books/Oberon2.pdf
>
> Thanks, I downloaded the documents and will take a look. I
> have a number of books on C++, but what I really need
> are programming examples for the types of programs I
> write, not large multi-programmer environments.
>
> I have a suspicion that I am asking the question
> "why would anyone ever need arrays" if all they
> had programmed up to this point were scalar variables.

The book "Design Patterns, Elements of Reuseable Object-Oriented Software" 
by Gamma, Helm, Johnson and Vlissides contains in Chapter 2 "A Case Study: 
Designing a Document Editor".  It discusses the kinds of objects and 
patterns that you might want to use.  However no computer code for the 
design is presented.  In the rest of the book the examples are in C++, but 
hey are not complete programs.

I would suggest looking at a library copy before buying it.  When I first 
tried to read this book I had only a theoretical knowledge of OO concepts 
and I found out that that was insufficient.  For me the best way to obtain 
working knowledge familiarity with OO was to learn a language like Java or 
C# followed by "Head First Design Patterns" by Freeman, Bates and Sierra 
which has Java code examples (I believe C# examples can be found on the 
web).  I needed to associate in my head, the concepts with concrete code 
examples before I could appreciate that design patterns are at the heart of 
OO programming.

I know Java but not C# although I have heard they fairly analogous.  I know 
a little C++ and while it is a powerful language, based on my experience 
Java or C# are easier to learn. YMMV.

When coming from a non-OO programming background you need to keep an open 
mind. Non-OO languages may seem better to you because of funcionality built 
into the compiler.  For example if you know COBOL then the combination of 
PICTURE clause and MOVE statements may seem superior to creating and edit 
pattern object and a string object and passing them a parameters to a 
method.  The COBOL EVALUATE statment may seem better than the Java switch 
statement. OO programming may not seem better to you at first but if you 
stick with it you can learn to appreciate that it is better in some ways. 
For example in non-OO if you need multiple stacks you craft them both by 
hand, but in OO you craft one Stack class and you can use the constructor of 
that class to create as many stack objects as your program needs.  Of course 
Java comes with a library of such classes which you usually just use instead 
of creating your own.

 After all of this you may still prefer non-OO to OO but if you are flexible 
enough in you thinking you can see the strong and weak points of each 
paradigm.  OO is not everyones cup tea but it does have its advantages if 
you look for them.

[toc] | [prev] | [next] | [standalone]

#3402

Charles Hottel <chottel@earthlink.net> wrote:
> 
> "root" <NoEMail@home.org> wrote in message 
> news:koaao7$iec$2@news.albasani.net...
>> rugxulo@gmail.com <rugxulo@gmail.com> wrote:
>>> Hi,
>>>
>>> On Wednesday, May 29, 2013 9:25:05 AM UTC-5, root wrote:
>>>>
>>>> My programming experience began before the advent of Object
>>>> Oriented Programming so the concepts are vague to me. It would
>>>> help if someone could sketch out how OOP would enter into some
>>>> of tasks I have done.
>>>>
>>>> (snip)
>>>>
>>>> How do OOP concepts come into such program design.
>>>>
>>>> Thanks for any help.
>>>
>>> Try reading these two .PDFs (first one is only a few chapters,
>>> second is a whole book):
>>>
>>> 1). http://edn.embarcadero.com/article/20803
>>> http://edn.embarcadero.com/article/images/20803/TP_55_OOP_Guide.pdf
>>>
>>> 2). http://www.ssw.uni-linz.ac.at/Research/Books/
>>> http://www.ssw.uni-linz.ac.at/Research/Books/Oberon2.pdf
>>
>> Thanks, I downloaded the documents and will take a look. I
>> have a number of books on C++, but what I really need
>> are programming examples for the types of programs I
>> write, not large multi-programmer environments.
>>
>> I have a suspicion that I am asking the question
>> "why would anyone ever need arrays" if all they
>> had programmed up to this point were scalar variables.
> 
> The book "Design Patterns, Elements of Reuseable Object-Oriented Software" 
> by Gamma, Helm, Johnson and Vlissides contains in Chapter 2 "A Case Study: 
> Designing a Document Editor".  It discusses the kinds of objects and 
> patterns that you might want to use.  However no computer code for the 
> design is presented.  In the rest of the book the examples are in C++, but 
> hey are not complete programs.

I have to book, but haven't looked at it.
> 
> I would suggest looking at a library copy before buying it.  When I first 
> tried to read this book I had only a theoretical knowledge of OO concepts 
> and I found out that that was insufficient.  For me the best way to obtain 
> working knowledge familiarity with OO was to learn a language like Java or 
> C# followed by "Head First Design Patterns" by Freeman, Bates and Sierra 
> which has Java code examples (I believe C# examples can be found on the 
> web).  I needed to associate in my head, the concepts with concrete code 
> examples before I could appreciate that design patterns are at the heart of 
> OO programming.
> 
> I know Java but not C# although I have heard they fairly analogous.  I know 
> a little C++ and while it is a powerful language, based on my experience 
> Java or C# are easier to learn. YMMV.
> 
> When coming from a non-OO programming background you need to keep an open 
> mind. Non-OO languages may seem better to you because of funcionality built 
> into the compiler.  For example if you know COBOL then the combination of 
> PICTURE clause and MOVE statements may seem superior to creating and edit 
> pattern object and a string object and passing them a parameters to a 
> method.  The COBOL EVALUATE statment may seem better than the Java switch 
> statement. OO programming may not seem better to you at first but if you 
> stick with it you can learn to appreciate that it is better in some ways. 
> For example in non-OO if you need multiple stacks you craft them both by 
> hand, but in OO you craft one Stack class and you can use the constructor of 
> that class to create as many stack objects as your program needs.  Of course 
> Java comes with a library of such classes which you usually just use instead 
> of creating your own.
> 
>  After all of this you may still prefer non-OO to OO but if you are flexible 
> enough in you thinking you can see the strong and weak points of each 
> paradigm.  OO is not everyones cup tea but it does have its advantages if 
> you look for them.
> 

I know I can go the rest of my life without OOP. For some time I have
been intending to get a good enough grasp to see if it is worth
anything to me. The lecturer from Lynda.com on OOP gave me a
push to look into it.

Someone suggested that I try to write a string class. Good suggestion.
Instead, I pulled up the Java string class to see what is what.
Except for the fact that strings are constant, almost all of the
operations on strings correspond to something that a user might
want to do with a text file. It seems that I might start by
defining a TEXT class as a malloced region which will contain
characters. There are some operations on TEXT that are not
included in the STRING class, most important of which are
that the primary object can be changed.

I have to let this stew around in my head for a while before
I see how I might get my feed wet.
> 

[toc] | [prev] | [next] | [standalone]

#3403

"root" <NoEMail@home.org> wrote in message 
news:kob1bq$2a5$2@news.albasani.net...

> I know I can go the rest of my life without OOP.

I've managed to avoid using it for quite a few years.

When I first looked at it to see what it could do for me, the first examples 
where what I'd been doing for years with dynamically typed languages anyway! 
So it didn't buy me too much.

> Someone suggested that I try to write a string class. Good suggestion.
> Instead, I pulled up the Java string class to see what is what.
> Except for the fact that strings are constant, almost all of the
> operations on strings correspond to something that a user might
> want to do with a text file. It seems that I might start by
> defining a TEXT class as a malloced region which will contain

Or you could just create a bunch of functions to work on strings; you don't 
need a class. OO provides neat ways of encapsulating those functions, but 
that's about it I think.

I've just finished a new text editor actually. It doesn't use OO, but does 
use a dynamic language (which makes it easy to work with strings);  the 
latter I consider more important.

And perhaps my editor is a little primitive but it doesn't need to do tons 
of string processing anyway: the main data structure describing the edit 
text is a struct, of which only one element, out of about twenty, is the 
actual text.

(If I did use OO, this text descriptor, describing the editor state, would 
probably be a separate class. The text itself is just a list of strings; the 
language would likely already have means for handling lists, and strings, so 
you don't need anything new.)

> characters. There are some operations on TEXT that are not
> included in the STRING class, most important of which are
> that the primary object can be changed.

This comes up with other types of a data: whether an operation will return a 
modified version of it's operand (leaving the original unchanged); or 
whether it will do an in-place modification. Sometimes I just allow both 
kinds (for example, sort() to return a new object, isort() to modify one.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.programming

csiph-web