Banging the Bottom End
Join Date: Jun 2004
|
Quote:
Quote:
As far as RMI / CORBA goes, it is possible to serialize an object, transmit to a local or remote receiver who can then unserialize and use the object. In order for this to happen, you have to build an interface and an object that implements said interface. This way, the interface (which is just a description of data and functions, like an Obj-C header file) can tell the receiver how to work with the serialized object it just received. It's really cool, and some languages like Obj-C and Java make it pretty simple to add this type of functionality to your objects. |
|||
quote |
‽
|
Quote:
I understand now that the author was talking about a unified, mostly language-agnostic means such as CORBA. It's not a feature of OOP per se, so I don't think the remark belonged in that document. Oh well. |
|
quote |
is the next Chiquita
Join Date: Feb 2005
|
As^Lan,
I'm just curious- Would you agree that OO programming is all about seeing? That is, what you see is what influences how program will work? |
quote |
Banging the Bottom End
Join Date: Jun 2004
|
Quote:
If you're interested you could download the source to my Musical Scales program from the link in my sig. I'm not sure how readable the code is for other people (I can read it ) but it may give you an idea of how OOP is used if you look at the usage of the Note and ScaleGenerator objects and how they're referenced by the main program object (forget the name of that one : ). |
|
quote |
Member
|
Whoever said you need to just start coding in OO is 100% correct. It's not like you get the concepts of OO and can then whip out perfect OO designs. It takes a while to know what to put in the various classes. I heartily recommend that since you are using a Mac you use probably the best OO framework around, Cocoa. It won't take long for you to get the hang of it. The simple act of reading data from and sending data to textfields, along with changing the state of buttons will have you thinking OO in no time.
[button doSomething]; myData = [textField giveMeMyString]; etc... "Slow vehicle speeds with frequent stops would signal traffic congestion, for instance." uh... it could also signal that my Mom is at the wheel... |
quote |
Not a tame lion...
Join Date: May 2004
Location: Narnia
|
Quote:
As far as "seeing" is concerened, I think you might be talking about the Model, View, Controller approach to coding with an object oriented language. In my latest project I have attempted to implement MVC but I'm not sure I would do it differently if I weren't purposely trying to separate the MVC. I subscribe to the top down approach to programming where I start with a basic vision of how I want my program to operate and refine individual parts of the program. I find object oriented programming really facilitates the top down approach, there is nothing in OOP that couldn't be constructed in BASIC with meticulously designed GOTO's but the OOP paradigm definately helps my workflow, allows me to reuse my code (and others i.e. JFrame), and basically just makes sense to me. Like I was saying to ahdustin yesterday, when I first learned about classes and objects, the first thing I wanted to do was build a zoo full of animals, I wasn't sure what they would be doing but I just pictured them running around doing their own thing. I later learned how to write programs that acutally did something (its debatable whether my programs are useful or not ) and I wanted to reinforce Mr. Beardsley's point for others (chucker already ordered a book) who might be reading this thread. Good OOP design doesn't necessarily come from reading a book or following a tutorial, it comes from writing programs, resolving problems that come up (and they do), and accounting for those contingencies in your next programs. To do this, you need to be familiar with an object oriented programming languages syntax (just being an expert on OOP doesnt mean you can code any language without study and experience), and you need to push that language and do the things you know it can do.... start with console output, if you feel like you can handle it, move to GUI... start including event listeners in your programs etc... when you play around with these things enough, the object oriented principles reveal themselves to you, you subconciously know that if you dont put those methods into a class of their own then it will mean more work for you later, so... you do it |
|
quote |
is the next Chiquita
Join Date: Feb 2005
|
As^Lan, thanks so much for your view-
It does sounds like either 1) I'm mistaken about what I know, 2) I have a different paradigm in mind. See, I had a seminar years ago that was basically to introduce freshmen to computer science and they had us play with Visual Basic (blech), saying it was a example of OOL, Forward to recent past; at my work, they need a database and I was willing to do it for them so I use Access (double blech), which uses Visual Basic modules and other features. So when I'm working on the forms, I am basically programming what I want to be on the screen, so if I add a button, (mind you, I do it with wizards disabled, thankyouverymuch) I place it where I want it, size it, give it a name, then Visual Basic Editor opens up and I type in code I want this particular button to execute. So to me, it's all about what I see on the forms, ensuring that I have covered all possible/necessary events so the database will behave exactly the way I want (e.g. checking whether records are filled in before moving on to the next one, ensuring that data is consistent across the record, etc. etc.) Does that make sense now? |
quote |
Banging the Bottom End
Join Date: Jun 2004
|
Quote:
I like this quote the best though: Quote:
|
||
quote |
is the next Chiquita
Join Date: Feb 2005
|
Quote:
I guess I'm in deep doo doo and even worse off than Chucker. |
|
quote |
‽
|
Actually, I started out with BASIC on a Commodore 64 when I was six. Maybe fundamentally, that's my problem.
|
quote |
Not a tame lion...
Join Date: May 2004
Location: Narnia
|
Quote:
But isn't your program more dependant on the database than the form ? I mean, the form doesn't define the database... you already have a database with fields that need to be filled, so it's the database dictating what goes on the form. Your particular case doesn't sound particularly object oriented (although you may be using an OO language) especailly if you are re-typing the methods for each button (assuming that there is some redundancy going on). But I can't really say that without seeing the code or having intimate knowledge of your program. |
|
quote |
is the next Chiquita
Join Date: Feb 2005
|
Database itself is stored in tables, queries.
Forms are the one that user interacts with to store data. Whatever I discussed here were relevent only to my work in forms. Yes I don't work with building a program from ground up, but I do get to define how a error message should read, what buttons there can be, how the database should behave, etc etc. They call it "Visual Basic Modules." Not sure if it's meaningful to you, but that's what they call it. WRT redundancies, there are pre-defined codes for common commands (e.g. closing a form) that loads automatically. However, I usually hand code in custom commands if I need some conditions to be satisfied. Hope that gives a clearer idea. Chucker, we're in same boat; I grew up with Commodore 64. Best computer system evar. |
quote |
Banging the Bottom End
Join Date: Jun 2004
|
Quote:
[edit] BASIC for the C-64 was created by MS. Last edited by bassplayinMacFiend : 2006-01-28 at 15:31. |
|
quote |
Posting Rules | Navigation |
|
Thread Tools | |