OOP and Console Apps

[=?Utf-8?B?UGFvbG8=?=]

I'm learning C# via console apps (to avoid getting bogged down in Windows
stuff). I'm wondering how the OO paradigm would work.

Say I'm developing 'classic' menu-driven apps where a menu gives a number of
options, you choose an option and then do something. Traditionally I would
set up a loop - waiting for the Exit option - and, say, create database
records, update them or delete them.

This would make my Main() look a bit 'procedural', I think. Are there any
examples for console apps which implement 'good' OO design?

Thanks

[Peter Duniho]

On Mon, 18 Aug 2008 19:10:08 -0700, Paolo
<Pa***@discussions.microsoft.comwrote:

I'm learning C# via console apps (to avoid getting bogged down in Windows
stuff). I'm wondering how the OO paradigm would work.

Say I'm developing 'classic' menu-driven apps where a menu gives a
number of
options, you choose an option and then do something. Traditionally I
would
set up a loop - waiting for the Exit option - and, say, create database
records, update them or delete them.

This would make my Main() look a bit 'procedural', I think. Are there any
examples for console apps which implement 'good' OO design?

I don't know about examples. But I would say that the question of OOP is
basically orthogonal to the question of user-input paradigm, as well as to
the question of "procedural" or "imperative" versus other ways of
describing the code.

OOP has to do with how the code is structured and related to the data.
You can easily have OOP with or without an event-driven input model.
Conversely, you can implement an event-driven input model with or without
OOP. In fact, event-driven user input -- as part of GUI operating systems
-- has been around a lot longer than OOP has been popular for OS and
application development.

In your "'classic' menu-driven" application, just because you have a loop
waiting for user input and you're dispatching operations based that in an
imperative way, that doesn't mean that the code and data can't be
organized in an object-oriented way. So, if you want to code your program
in an OOP way, I'd say just do that. :) Heck, writing your code in C# I
think you're going to have some significant effort avoiding OOP (but I
can't speak for whether you'll do _good_ OOP or not :) ).

Pete

[Jonathan Wood]

I concur with Peter's comments. Being procedural does not mean it is less
OOP. OOP is about organizing your code into objects. Most applications are
not procedural simply because they are written to respond to Windows events,
which you are currently avoiding.

Beyond that, I would recomend that you start using the Windows interface.
It's not easy and you need to learn that as well for most application types.
..NET also provides many UI-related objects to help further provide examples
of OOP.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Paolo" <Pa***@discussions.microsoft.comwrote in message
news:86**********************************@microsof t.com...

I'm learning C# via console apps (to avoid getting bogged down in Windows
stuff). I'm wondering how the OO paradigm would work.

Say I'm developing 'classic' menu-driven apps where a menu gives a number
of
options, you choose an option and then do something. Traditionally I would
set up a loop - waiting for the Exit option - and, say, create database
records, update them or delete them.

This would make my Main() look a bit 'procedural', I think. Are there any
examples for console apps which implement 'good' OO design?

Thanks

[=?Utf-8?B?UGFvbG8=?=]

Peter: as you say, with C# I am led down the OOP path. As it happens I have
already started, having developed a ScreenManager class and a Menu class. I
need to spend a bit more time researching/thinking about class(es) to
encapsulate database operations.

"Peter Duniho" wrote:

On Mon, 18 Aug 2008 19:10:08 -0700, Paolo
<Pa***@discussions.microsoft.comwrote:

I'm learning C# via console apps (to avoid getting bogged down in Windows
stuff). I'm wondering how the OO paradigm would work.

Say I'm developing 'classic' menu-driven apps where a menu gives a
number of
options, you choose an option and then do something. Traditionally I
would
set up a loop - waiting for the Exit option - and, say, create database
records, update them or delete them.

This would make my Main() look a bit 'procedural', I think. Are there any
examples for console apps which implement 'good' OO design?

I don't know about examples. But I would say that the question of OOP is
basically orthogonal to the question of user-input paradigm, as well as to
the question of "procedural" or "imperative" versus other ways of
describing the code.

OOP has to do with how the code is structured and related to the data.
You can easily have OOP with or without an event-driven input model.
Conversely, you can implement an event-driven input model with or without
OOP. In fact, event-driven user input -- as part of GUI operating systems
-- has been around a lot longer than OOP has been popular for OS and
application development.

In your "'classic' menu-driven" application, just because you have a loop
waiting for user input and you're dispatching operations based that in an
imperative way, that doesn't mean that the code and data can't be
organized in an object-oriented way. So, if you want to code your program
in an OOP way, I'd say just do that. :) Heck, writing your code in C# I
think you're going to have some significant effort avoiding OOP (but I
can't speak for whether you'll do _good_ OOP or not :) ).

Pete

[=?Utf-8?B?UGFvbG8=?=]

Jonathan: thank you. I have quite a bit of experience of event-driven Windows
programming through using Delphi/Object Pascal and that should stand me in
good stead when I tackle .NET WIndows forms etc.

I decided to concentrate initially on console apps so that I could focus on
learning 'pure' C#, its features and OOP before digging into the class
libraries.

"Jonathan Wood" wrote:

I concur with Peter's comments. Being procedural does not mean it is less
OOP. OOP is about organizing your code into objects. Most applications are
not procedural simply because they are written to respond to Windows events,
which you are currently avoiding.

Beyond that, I would recomend that you start using the Windows interface.
It's not easy and you need to learn that as well for most application types.
..NET also provides many UI-related objects to help further provide examples
of OOP.

--
Jonathan Wood
SoftCircuits Programming
http://www.softcircuits.com
"Paolo" <Pa***@discussions.microsoft.comwrote in message
news:86**********************************@microsof t.com...

I'm learning C# via console apps (to avoid getting bogged down in Windows
stuff). I'm wondering how the OO paradigm would work.

Say I'm developing 'classic' menu-driven apps where a menu gives a number
of
options, you choose an option and then do something. Traditionally I would
set up a loop - waiting for the Exit option - and, say, create database
records, update them or delete them.

This would make my Main() look a bit 'procedural', I think. Are there any
examples for console apps which implement 'good' OO design?

Thanks

[Jeff Louie]

>I'm learning C# via console apps (to avoid getting bogged down in
Windows
stuff). I'm wondering how the OO paradigm would work.<

Paolo... IMHO, if you are trying to learn OOP there is no reason to
avoid using
Windows Forms under .NET. You are on the right track in writing a
console
app first. Specifically, you can write a class that encapsulates the
logic and
algorithms of your application and test it as a console application.
This
separates the MODEL from the event handling and GUI code, the VIEW-
CONTROLLER. Once you have written and tested the model class, you can
write a Windows Form application that uses the logic in the model class.

As an example. Many GUI Unix Chess programs differ only in the GUI code.
The actual logic to mimic the chess game is in a separate class that can
be
called and queried from a console. So in Unix terminology the chess game
logic and algorithm is the ENGINE. Different programmers can then write
their
own "chess games," actually different GUIs, that call the same engine.
In Unix
the GUI is considered the user_INTERFACE.

>>Say I'm developing 'classic' menu-driven apps where a menu gives a

number of options, you choose an option and then do something.
Traditionally I would set up a loop - waiting for the Exit option - and,
say,
create database records, update them or delete them. <<

The framework takes care of all this event looping code. It has been a
very
long time since I wrote my own event looping code and I don't miss it at
all.
NET has the concept of delegates and events that _could_ be thought of
as
"sending messages to interested objects" that implement the delegate.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***