This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi, first I'd like to introduce myself. I'm a first year comp science undergrad, and this place looks pretty cool, so I'd love to stick around and become a (hopefully) valued member of the forum. I particularly like the terms and conditions when you sign up (... "be nice").
Anyway, down to my problem:
We handed in a project a while ago that was, in a nutshell, to read in data from a .DAT file, store it in appropriate collections, then use a basic query language to filter through the stored data. I wasn't really happy with my querying though, as it was basically a huge succession of control statements. Worked... but it was one monolithic method.
The queries were of the form "select OBJECTNAME where ATRIBUTE COMPARITOR VALUE and ATRIBUTE COMPARITOR VALUE", there could be as many conjugate clauses (the bit after "and") as desired (0... 200 whatever). For example "select planet where magnitude > 2 and rightascension <= 60". Not sure if comparitor is the right word... What I mean is <=, <, =, >, >= anyway. The objects could be planets, stars etc. Each object has those attributes and is stored in a collection of its own type.
As feedback, we had a comment back that we should have used a Query interface and a two subclasses to represent a simple query (e.g. magnitude > 2) and then a conjunctive query (ie simplequery1 AND simplequery2 ). The Query interface would then have a match method. I'm struggling to get my head around this, does anyone have an example of something similar I can look at or a simple explaination that might help me out?
I've not used interfaces before, I am basically familiar with the concept, but this will be me implementing the concept for the first time... so be gentle!
Originally posted by R.B.: Hi, first I'd like to introduce myself. I'm a first year comp science undergrad, and this place looks pretty cool, so I'd love to stick around and become a (hopefully) valued member of the forum. I particularly like the terms and conditions when you sign up (... "be nice").
Welcome to the Ranch We are cool
Had a similar question about 4 weeks ago. Have a look at this thread. See how far you get, without me confusing you about trees and engines. Any more questions: please ask.
Joined: Oct 13, 2005
There isn't a Query interface in the standard API so I presume you have been given that already. To copy the Engine interface I mentioned earlier, what you get is headings, method signatures, and probably most important, javadoc comments, which I am adding here.To implement the interface your class (unless abstract) has to have methods with the same
Return type (or compatible covariant return type), and
Intention: ie it must fulfil the requirements of the javadoc comments.
Each of these methods should have public access.
Joined: May 16, 2008
We weren't given a query interface. I should perhaps have said
As feedback, we had a comment back that we should have designed a Query interface...
I'm working my way through your engine and tree examples in the other thread, I'll let you know how I get on. [ May 16, 2008: Message edited by: Samuel Allaby ]
Joined: May 16, 2008
That's helped, thanks very much. Though I'm still really not sure how I can use that to apply queries without massive if and loop statements. Allow me just run through my stream of consciousness for a minute!
Currently, the queries are read in from a .DAT file that was provided, presumably so they could unify marking... Anyway, these are read in, and the main query is stored as an object "Query", the constructors for which are:
In hindsight I clearly don't need to be storing things like "select" and "where", but they're there so nevermind!
If there is an "and" clause in the query then the next bit is stored as a SubQuery, that has the constructor:
Each subquery is stored in a list, then once there are no more subqueries, the whole query (the main query and all its subqueries) is stored in a list to be accessed later. Ultimately I'd like to get it to respond to user input in a TextField, so I could get rid of the query collection altogether. But that's later.
I feel stupid to an epic degree, but I just can't see how to do this without a ton of control statements for every eventuality.
I didn't read the other thread, but I immediately had to think of the Interpreter design pattern. You might want to research into that direction for a bit. The wikipedia entry has a nice example.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus