OOP and Console Apps

[Paolo]

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

 

[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.

 

[Paolo]

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.

 

[Paolo]

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.

 

[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.
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