Hi Chris,

I fully understand where you are coming from.  I did a software
engineering degree some years back when OO was just becoming the norm in
such courses and I thought I understood OO after the first semester, but
then I realised that I hadn't really understood it until half way
through the second year when the penny really dropped, and I still find
that I am appreciating additional nuances even after all of these years.
 Different people pick it up at different rates, and it is really just
a matter of working through it.  Though studies suggest that if you have
a procedural background you will have a harder time doing so, and some
people no matter how many years coding "OO" still never get it, and
possibly never will.  Most of what others on this thread has said is
correct, but it is still difficult to take that and conceptually apply
it to your own individual problem.  So lets look at yours, bearing in
mind that there are hundreds of ways of addressing the same thing.

First some definitions.

Definition of an object:

Contains state, behaviour and identity.

So an objects state is stored in its class variables.  Hiding this state
behind accessor methods is called encapsulation.  The behaviour that the
object provides is in how it manages its state, as well as what services
it provides to its clients through its methods.  If the behaviour of the
object is not multi-faceted, then the class is cohesive. Identity is
what makes it unique from other objects derived from the same or other
classes.

Definition of a class:

Think of it as the blueprint (ignoring static state and behaviour for
this exercise) of the object.  So the class is the skeleton or outline
of what you want, it is the compiled source code.  The object is the
instantiation, the hydrated, living implementation of the blueprint.  So
an architect may design a house (the class), and a builder(the jvm) will
implement the design and build any number of individual houses (objects)
of the same plan.

Definition of an interface:

This is the beginning of conceptualising OO, and as such don't be too
concerned if you think you understand what is written but struggle to
understand how to apply it.  Think of a interface as a contract.  It has
no behaviour, state or identity.  However it does have methods (again
ignoring static imports and static final constants).  Any class that
implements an interface is saying that it will offer those methods of
the interface and will take on the responsibility of providing the
behaviour of these methods.  Because an interface is simply a contract
with no behaviour or state, you can never instantiate an interface like
you can an object from a class.  Accessing objects through their
interface contracts rather than directly eg List list = new ArrayList()
vs ArrayList list = new ArrayList is preferable and contributes to
loosely coupled design.

Definition of inheritance:

This is where things start to really twist your mind.  There are loads
of examples and analogies and I don't know that I will make things any
clearer.  However, a simplified summary.  When a class (child class)
extends another class (parent class), we are saying that the child class
belongs to the same family as the parent, but provides some additional
or modified behaviour, above and beyond its parent.  Classic examples
you see all the time in books and online: poodle (child) is a type of
dog (parent), dog (child) is a type of mammal (parent), mammal (child)
is a type of animal (parent).  Leave abstract and concrete classes for
another day.

Some basic design heuristics:  encapsulation, strong coherence, and
loose coupling.  Stick to these as much as possible.

However putting all of that into a real world implementation is easier
said than done, even for someone who does it a lot, because the more you
learn, the more you need to consider and there often is no "correct"
way, though some design choices are better than others, which is where
you start venturing into the world of patterns, which help you
communicate design concepts and use design choices that others have
found useful.  Plus there are always critics who believe that their way
is the only way...  Which then spills over into development processes,
unit tests, test driven development, etc.

Back to your example.  First thing, all of your code is in the main().

First step, create a method in your class, paste all the code into that
method, do a MyProg myProg = new MyProg(); from the main, then call your
new method myProg.newMethod();  Congratulations, you now have an object.
 Now test that it still works.

Then create a new interface: public interface Facility {}
Add methods:  public int getAgeRestriction(); and public void
setAgeRestriction(); as well as a method: public String getFacilityName();

Create a different class for each facility that implements the Facility
interface.  eg public class XxxxxFacility implements Facility {} and
provide each class a private final static String name constant, specific
to the facility type.

Next, create a new class: public class Venue{}
In this new class have a private List facilities = new ArrayList();
As well as a method to add a facility to the venue and another method to
print out the facilities that this menu contains based on the minimum
age passed in as a parameter.

In your MyProg class, create a List venues = new ArrayList();

Then for each row, add a new venue to your venues list.  Then for each
column in the row, add the appropriate facility class (reflection and /
or a Factory would make this easier, but leave that as a later learning)
to the venue, setting the facilities age restriction.

Finally in the MyProg class, you can iterate through the venues and have
the venues print out the facilities that it contains that match the age
criteria.

As an additional exercise, you could have the excel sheet name passed in
as a command line parameter, rather than as a hard coded string.  Basic
rule, use parameters as much as possible.

Now there are lots of things to say why the approach just taken is not
that good.  For one thing, why not just do an array of an array? why
over-engineer things?  why did you do this and not that?  Well, what you
have done using this approach is taken the first steps to using an OO
design using interfaces and classes.  So it acted as a good example to
learn from.  Secondly, you now have the beginnings of data objects that
could be used in other ways, or passed to other applications, not just
to print out the contents of a spreadsheet.  It is also easily
extensible.  What if a new attribute was added for disabled access?
This just becomes another attribute of the facility or perhaps the
venue.  As would contact details, booking details, etc.  In fact, each
facility could potentially have its own calendar object.  Then you could
check which ones were available for a given time period that met your
min age restriction, as per the command line parameters passed in on
running the application, and the spreadsheet may in future have
different facilities with min ages ranging from 6 to 21 or any other
range.  Treating it as a value rather than as a flag will allow for
future changes to the data without breaking your code.

I don't expect you to suddenly see the light from this one little
example, but I hope it helps clarify or shed some light on some aspects
for you. You have also just gone from 0 objects (excluding Strings) and
1 class to 22 classes (20 of which are different facilities) and 1
interface.  The number of objects you will have (excluding ArrayLists)
are 20 facilities * number of venues plus one excel parser object that
you created from your main method (ignoring your JExcelApi object).

All the best on your journey towards OO enlightenment.

AA

[Pseudo code snipped. It does what you'd expect: Scans through a 2D array,
and uses String.startsWith("18").]

   I think this solution is more naturally expressed in procedural terms
than OO terms.

   - Oliver

<snippage>

I think I agree with Oliver.  The problem has been decomposed enough
that additional objects don't seem to be very useful.  Nevertheless,
I'll make a few comments.

First, rather than one big long main method, it might be nice if you
broke the design up a little, perhaps into a simple
input-processing-output model, using methods instead of functions.

(Let's see if I can do this without invoking Lew to comment on my style
or syntax :))

class MyProg {

    private void readFile() {...}
    private void processData() {...}
    private void printTable() {...}
}

You can then have the main method call each of these as appropriate.
There might be even more ways to break each method up into a few smaller
methods each.

Second, it might be nice if you actually added some instance variables,
and designed MyProg to be instatiated.  Let's rename it
ExcelTableProcessor and go from there:

class ExcelTableProcessor {

    String fileName;
    // etc.

    public ExcelTableProcessor( String file_name )
    {
        this.fileName = file_name;
    }

    public doIt
    {
        readFile();
        processData();
        printTable();
    }

    public static void main ( String args[] )
    {
        ExcelTableProcessor x =
           new ExcelTableProcessor(args[0]);
        x.doIt()
    }
    private void readFile() {...}
    private void processData() {...}
    private void printTable() {...}
}

This to me shows a bit more structure than one 300 line blob in a single
method.

Lastly, give some thought to testing.  Maybe look at JUnit, or design
you own test.  Just thinking about it, testing and reading from a file
might be hard, so maybe this needs to be refactored to take an input
stream and an output stream, and that'll help testing a bit.

Oh, and Java contains some tags to help with documentation, check into
that too.

Overall, this is not really OO though, just basic design.

Just my 2 nickels.

On Mar 26, 10:09 pm, "Chris Uppal" <chris.up...@metagnostic.REMOVE-
THIS.org> wrote:

Cute, but you don't seem to know what you are talking about.

Apples and oranges. The Relational Model has a solid mathematical
foundation, and Normalization is built on RM. Normalization has stood
the test of time. OO has no formal basis, and its design techniques
are ad-hoc (best practices.)

Normalization is a strategy for designing databases whose goals
include: accurate representation of the entities involved, robustness,
redundancy elimination, easing future changes, ... Do you see a
problem with achieving these goals?

You seem to see proper database design as a trap and prefer a seat-of-
the-pants approach. That may be true for OO designs but not
Normalization.

--
Lee Fesperman, FFE Software, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)