View Full Version : OOP learning book with Ruby focus?
I've been coding for years, and I have enough experience to pick up new languages easily, understanding the differences in syntax, features, etc. This all works really well for procedural programming.
...and there's the dilemma. It goes without saying that procedural programming is on the way out to make room for object-oriented paradigms. I understand very well that this isn't a choice by the people up there to deliberately make my life as a programmer hard, but that a lot of things, especially in a GUI, simply necessitate it, or, to say the least, make the resulting application lot more efficient.
When I write code, my brain has a workflow in mind. I could easily lay out the code as a flowchart instead, in OmniGraffle, for instance. It would be a graphical 1:1 representation. Trouble is: you can't do that with OOP. OOP isn't linera in any way; it doesn't follow the "this happens after that" or "under these conditions, this happens next" schemes at all. It's driven by events and other triggers, and while there may be micro-units where the same linearity applies, it just doesn't work that way for the entire app. It shouldn't. It wouldn't really work well that way.
But that's the way my mind lays it out, making me inherently incompatible with the concepts of OOP. No matter how much I understand them. I get what a class is, what an object is, what a method is and what messages are. But that still doesn't help me. I could continue as before and buy random books about this language and that language, or read tutorials or "electronic books" online. But no matter what, the stumbling block will always be the same: I don't think that way!
So what I need is a way to start learning to think different (hah). I don't much care for theory, so I'd much prefer to learn it by example, and since my most recent and perhaps most favored language is Ruby, there would be bonus points if it used that. (Preferably, no C++ and no Java; Objective-C, Python, C# and similar would be okay.)
So, any ideas? I realize this is a very… vague request, but if someone can think of something, that'd be great. Doesn't have to be a book.
rollercoaster375
2006-01-25, 10:26
From my experience (Which is small, as it's limited to 3 years with PHP), OOP is still very much linear. There's no way to escape that with traditional computing abilities.
As for a book recommendation - I don't really know many books that lay out OOP...
There are very few books on Ruby on shelves as of yet, so you'll be hard-pressed to find one with a Ruby focus.
http://en.wikipedia.org/wiki/Object-oriented_programming is a Good reference on OOP, and I'd suggest reading it before purchasing anything.
Chucker, I have the exact same problem.
I've been coding for years in Perl and do quite a bit of PHP in my current job. I've been trying to get my head around OOP and have had little success.
I have yet to find a book/tutorial that worked for me.
I'll be keeping close watch on this thread.
No book recommendation here, but a suggestion.
When I start with developing Access database, which is in a weak sense, a OOB environment, I make decision on what I want to see on the screen, and what I can do at this point.
Here linearity applies.
Splash screen -> Main Form <-> Subforms (I think of them as subroutines) -> Data Integrity Checks and Error handling
Something like that. So instead of words, it's all about objects; but you still have to arrange it in a logical (e.g. linear) way so even an idiot can use it.
HTH
Well, it's good to see I'm not the only one with the problem :) All the more surprising that there seems to be no good resource for this. It's not the concepts I need to learn (there's plenty of information on that); it's the way of thinking, so to speak. I don't know how to put it any better. Ditching old habits and acquiring new ones, sort of.
From my experience (Which is small, as it's limited to 3 years with PHP), OOP is still very much linear. There's no way to escape that with traditional computing abilities.
In simpler applications, that may be the case, but as soon as you need to deal with, say, socket programming, you are forced to think of run loops, for example. Not that linear any more.
There are very few books on Ruby on shelves as of yet, so you'll be hard-pressed to find one with a Ruby focus.
Eh, that's fine.
http://en.wikipedia.org/wiki/Object-oriented_programming is a Good reference on OOP, and I'd suggest reading it before purchasing anything.
I did in fact look at that; they have (http://en.wikibooks.org/wiki/Computer_programming/Object_oriented_programming) a WikiBooks entry on that, too. Doesn't really help though. Again, it's not the concepts I'm trying to learn.
No book recommendation here, but a suggestion.
When I start with developing Access database, which is in a weak sense, a OOB environment, I make decision on what I want to see on the screen, and what I can do at this point.
Here linearity applies.
To an extent, yes. But what if the user does something in an order you didn't expect? The interactivity the user gains means, at the same time, that the programmer loses predictability.
Ahh, yes.
That's why I always think about UI. I probably spend 90% of my time making decisions on how I want UI to work.
You already saw how Apple have a concise UI by generally having only one thing in one place, resistance against hidden contextual menus, and some more.
So for myself at least, I make decisions on what a particular screen is supposed to do, then wrap UI around that particular goal. The order shouldn't really affect how it will behave; only that certain conditions be satisfied before allowing one to moving on/returning to the starting point.
I looked at my old post and thought that my analogy was weak. I will try and post a flowchart of what I usually do when working on the database.
HTH.
Ahh, yes.
That's why I always think about UI. I probably spend 90% of my time making decisions on how I want UI to work.
You already saw how Apple have a concise UI by generally having only one thing in one place, resistance against hidden contextual menus, and some more.
I'm very interested in UI design and Usability, but for me, that's entirely unrelated to code.
I looked at my old post and thought that my analogy was weak. I will try and post a flowchart of what I usually do when working on the database.
Can't wait :)
[QUOTE=chucker]I'm very interested in UI design and Usability, but for me, that's entirely unrelated to code.[QUOTE]
Well, with OOB, it *is* the code. At least I look at it that way.
When you say OOB, you mean OODB, right? ;)
Well, here's an example.
It takes me only about half a day to whip up a quick and dirty client for a network protocol, even in a language I barely even know. (I know, because I've done just that about half a year ago, with Ruby.) But, being procedural, the client essentially already has scripted in advance what it's going to do. E.g., I could write it to connect to the server, log in under a specific account, post some messages, then log back out. I could even give the user some degree of interaction through CLI arguments, e.g. let them customize the server, username and password. So far, so good.
The trouble comes when none of that is a given. What if the user only wants to run the client, but not actually connect to anything? What if the user wants to connect, but not log in? What if he wants to log in twenty minutes later? Then things aren't linear any more. And then I'm screwed, because I just can't program this kind of interactivity.
Does that illustrate the issue better?
My 2c before I go to bed....
I'm not sure what you've got against java, its a great language and a great way to learn OOP principles... and there is a whole lot more documentation, courses, and books etc. than on cocoa/obj-c.
Now that being said... say you want to learn Obj-C, why not just start coding in it. It will come to you, and soon you will learn the ins and outs of instantiating objcets, methods calls, reusing objects, extending classes etc. trust me you will.
When I say "just start coding in it" I mean exactly that, dont worry if you are using procdeural or object oriented coding techniques... become familiar with an object oriented languages' syntax and the concepts will reveal themselves to you, thats how they do it with intro level java anyway. I recommend a program that tests for Palindromes as your next program following HelloWorld, that's what I've been using and it's just complex enough to be interesting, and give the language a bit of a workout.
If you are so inclined, you could always post your creations back here for critique.
I sincerely recommend java, I really do think the available resources for cocoa are sub-standard (this is my opinion), and if you are learning OOP, you should start on something where you can google it and get an answer... or post it here and have all the closet java programmers look at your code.
EDIT: Please dont get the idea I hate cocoa, I've been having some real fun coding for the Spider Solitaire X project (in cocoa) theres just been a couple of speedbumps here and there that have really bugged me because they came about from (IMHO) inadequate documentation.
I'm not sure what you've got against java, its a great language
Too similar to C++. I just don't like it; matter of personal preference, simple as that. ;)
For the record, I don't like ObjC that much either, but at least it has a use for me (creating OS X software). Java has no use to me. As far as I'm concerned, "runs anywhere" translates to "runs subpar everywhere". If I want something cross-platform, I prefer to use an uncompiled language, such as Perl, Python, Ruby, you get the idea. If I want something for Windows, I prefer to use a .NET language, and if I want it for Mac OS X, I can sort of understand ObjC code if I really have to. I prefer not to, however, if only for the need to manage memory.
Now that being said... say you want to learn Obj-C, why not just start coding in it. It will come to you, and soon you will learn the ins and outs of instantiating objcets, methods calls, reusing objects, extending classes etc. trust me you will.
Trust me, that doesn't work for me. I still stick to my patterns which ultimately leads to an inflexible, non-modular application.
I recommend a program that tests for Palindromes as your next program following HelloWorld, that's what I've been using and it's just complex enough to be interesting, and give the language a bit of a workout.
That's funny, since my first Ruby "program" was indeed a palindrome check. I had very little trouble designing it. However, that has almost nothing to do with OOP. It's very procedural.
If you are so inclined, you could always post your creations back here for critique.
I get flamed enough as it is. :D
I sincerely recommend java, I really do think the available resources for cocoa are sub-standard (this is my opinion), and if you are learning OOP, you should start on something where you can google it and get an answer... or post it here and have all the closet java programmers look at your code.
I'm sorry, but I'm not sure you really understand what exactly I'm trying to learn. I could learn Java if I were so inclined, but I would still approach it with a procedural idea, and that's just bad™.
I'm sorry, but I'm not sure you really understand what exactly I'm trying to learn. I could learn Java if I were so inclined, but I would still approach it with a procedural idea, and that's just bad™.
I understand exactly what you are trying to do :AllKnowingGrin:
You want to break your procedural habits and learn object oriented programming... you stated as much.
Here's a secret, that you hinted at before, object oriented programming starts out procedural. You dont think they jump into extending an class right after hello world do you ? although they do jump into methods which is a key part of OOP, if you are familiar with functions... you'll have no problems with it.
As for not liking java or obj-c, well... you have to start somewhere, and if you are wanting to learn, the cutting edge is probably not the best place to start (i.e. ruby, python). Start with a language that has well entrenched coding practices so you can learn the basics. Time spent learning java for the purpose of learning OOP is not wasted even if you have no desire to code java apps.
As for the palindrome example... this is what you need to do to make it object oriented, very simple... two classes:
Create one class for reading in user input and passing that input to the other class.
The other class evaluates the string passed and determines if it is a palindrome or not, then passes back a boolean.
The first class then informs the user on whether they typed a palindrome or not based on the results of the answer it got from the other class.
It is very similar to a function call, but it is object oriented.
I will be up for about another three minutes to see if you respond ;)
I'm gonna respond, but I've already passed the three minutes, so good night. ;)
For reference, here's the original palindrome code (here's hoping vBulletin, unlike WordPress, doesn't mangle it). It strips uppercase, spaces and the last character of a line, so it works with a lot of things. But it's not object-oriented. And your two-class approach doesn't strike me as particularly object-oriented either. After all, my code is already pretty much split in two (a procedure that returns the results of the check, and a main block that handles the input).
#!/usr/bin/env ruby
def isAPalindrome?(text)
puts text
if text.downcase.delete(" ").chop == text.downcase.delete(" ").chop.reverse then
return true
else
return false
end
end
input = gets
if isAPalindrome?(input) then
puts "\""+input.chop+"\" is a palindrome indeed!"
else
puts "But no, it is not."
end
Goodnight then... I really am going to bed this time !
rollercoaster375
2006-01-25, 19:06
To an extent, yes. But what if the user does something in an order you didn't expect? The interactivity the user gains means, at the same time, that the programmer loses predictability.
Enter OOP: if the user does something unexpected, make sure that the methods you're using aren't overaccomplishing. By this I mean any time the user is presented with something, make sure that it's using a different method. In essence the code isn't a single linear line, it's multiple linear lines, starting from a single point.
That probably was a *terrible* explaination.
I understand what you're talking about though. Not in the strict sense however. Attempting to learn ObjC from my knowledge of PHP isn't easy, mainly because it's a paradigm shift - PHP handles each request with a fresh slate, ObjC doesn't (if you want to call them requests, that is).
I can see I'm not being of much help, so I'm going to go be quiet now ^_^
After seeing how horrible my proto-flowcharts were, I did some research and came across this link (http://www.developer.com/design/article.php/3304881). I think this will answer what you want to know.
Meanwhile, improvishing my flowchart.
bassplayinMacFiend
2006-01-25, 20:15
First, let's try to define an object. Let's say an object is a collection of data and functions that work on said data. Let me try a simple example.
For my example, I will use book and library objects. The book will contain pertinent information about the book, and the library will be a collection of book objects.
So, a book object has the following data attributes:
BookName
ISBN
Author
Date
Publisher
The object will need gettor/settor methods to set/change and retrieve each data element from an object. For example a couple of book functions would be
public string bookName() {
return bookName;
}
public void setBookName(string bName) {
bookName = bName;
}
The idea behind OOP is encapsulation, everything related to an object is accessed through publicly defined functions. You don't just manipulate bookName directly, you use methods to get and set the bookName variable. The same applies to the other data elements, plus any object functionality you may add to the object.
Now let's move onto the library object. The library will contain a collection of book objects, because that's what a library is. :) But, in order to be useful, the library will need to keep track of whether or not a book is checked out, who checked a book out, whether a late fee is due. Also, a library will need to add newly purchased books to and removed damaged/destroyed/lost books from the library collection.
To do this, let's create a new inventory object. The inventory object contains the following data elements:
a Book object
inLibrary? boolean
dateDue (if not inLibrary)
lastCheckedOutBy (reference to person object)
Now the library object will have to manage the inventory collection.
I know you said you didn't like Java, but here's a library example I did in Java for a grant project in 2002 (paid for my 20GB iPod :) ). If you have any questions, I'll try to answer them, but it's been awhile. http://members.cox.net/pevac/ex8code.txt
The reason why my flowcharts were so messed was that OOP inherently has a lot of recursive programming, as BassplayinMacfiend has said, there's a library for you to call upon.
However, I decided an outline would work better. Realize it's more of a pyrmaid, so as you work downward, you may have to branch out as if it was a nested loop, until it's satisfied, return to the question you left at and continue until all questions are answered.
Remember this is from my frame of reference of Access so I would want to check with other programmers to see if they can agree with the process.
1. what do I want on the screen?
i. What do I want user to do there?
1. What can user input?
2. What conditions must be satisfied before user moves away?
ii. What commands user can enter? (see 1.i.1)
iii. What menu or options user can have?
iv. What do I want the computer to do there?
1. What conditions should be satisfied before it loads?
2. What should computer know about it? (variables, objects, events)
3. Should computer monitor user’s inputs?
a. What conditions should inputs satisfy?
b. What actions should the computer take to accomplish the purpose?
c. Should the computer prompt user for more details?
i. Do I want the details on same screen or a new one? (if no, a new screen returns to 1 as a nested loop)
So in a nutshell, instead of thinking how to order your code, think how you want it to behave. Kinda like homebrewing a puppy of your own. :p
And your two-class approach doesn't strike me as particularly object-oriented either. After all, my code is already pretty much split in two (a procedure that returns the results of the check, and a main block that handles the input).
Perhaps, the Palindrome example seems pointless, but it can be split up into two objects, but perhaps it is not obvious.
How about a zoo, similar to baseplayingmacfiends bookshelf with books.
For whatever reason, you want to create a zoo object, and that zoo object contains animals, the animals all have a type etc. and reflect the basic animal attributes.
Let's start with the animal class...
public class Animal
{
//these following class variables make up our Animal object
String name;
boolean hasBeenFed;
public Animal() // our default constructor... creates primordial ooze
{
name = "Primordial Ooze - why dont you subclass Animal";
hasBeenFed = false;
}
public Animal(String aName, boolean fed) // another constructor, for creating an Animal with custom specs
{
name = aName;
hasBeenFed = fed;
}
public String getInfo() // a method (similar to a function) that returns a String built from this animals instance variables
{
if (hasBeenFed)
{
return (name + "and it is not hungry.";
}
else
{
return (name + "and it is hungry !";
}
}
Okay... now we have an animal.... let's create a zoo to put it (and it's friends) too.
public class Zoo {
Animal animalArray[50]; // we want 50 animals in our zoo, stored in an array
public Zoo() // a constructor method to create the zoo object.
{
//use a for loop to seed our array with animal objects
for (int i = 0; i < animalArray.length; i++)
{
animalArray[i] = new Animal();
// the "new" keyword in java instantiates a new object, calling its constructor method
}
}
public static void main(String[] args) // this is a standard line in java for defiing your "main" method in
java, the "main" method is called automatically at runtime.
{
Zoo myZoo = new Zoo(); // creates a zoo object and calls its default constructor, we
created that above...
for (int i = 0; i < animalArray.length; i++)
{
System.out.println( animalArray[i].getInfo() );
}
}
}
Okay... there we have a Zoo object storing 50 Animal objects in an array, the only problem is all our animals are hungry Primordial Ooze, which isnt too interesting.
Notice to get the information string from the animal we call the .getInfo() method... this operates like a
function but its specific to the object where we defined it.
To liven up our zoo we should subclass Animal into the different kinds of animals we want. A subclassed Animal needs to be defined like any other class but it will "inherit" the methods from the parent...
public class Tiger extends Animal
{
public Tiger()
{
super("Tiger", true); // this call to super will call the constructor in the "superclass" (Animal) and
specifically will use the constructor that is looking for a String and a boolean (the one we didnt use before)
}
//no need to re-write the getInfo method, the Tiger object has inherited it
}
and perhaps a Lion object too...
public class Lion extends Animal
{
public Lion()
{
super("Lion", false); // someone forgot to feed the lion
}
}
So now we have two kinds of animal, and some Primordial Ooze, because they are all derived from the Animal superclass, I can keep them in the Animal array. So now I modify the constructor in my Zoo object...
public Zoo() // a constructor method to create the zoo object.
{
//use a for loop to seed our array with animal objects
for (int i = 0; i < animalArray.length; i++)
{
if (i % 2 == 0) // This says if the remainder of i divided by 2 is equal to zero....
{
animalArray[i] = new Tiger();
}
else
{
animalArray[i] = new Lion();
}
}
}
Okay now... we have a zoo, with 25 tigers and 25 lions... super :)
How does this develop into larger applications with EventListeners and GUI's etc... well all the elements of a GUI have already been created and encapsulated into objects. By knowing the syntax of the language and basic OOP principles, you can instantiate and use these GUI objects (IDE's can obscure this somewhat.. best to do it by hand first).
Since you mentioned you liked to use flow charts to help visualize and understand your programs, you might want to look into UML. UML tends to be used in a very informal sense by most programmers without them ever even knowing it. Ever seen a diagram with different boxs linked by arrows that represented the design of a program? That could be considered very, very basic UML.
One concept that seems to have always helped me design OO code was to think about what logical objects could be created in my design. The basic idea is that an object will encapsulate everything that it should logically represent: the data that it is relevant to it and the methods that operate on this data or present it to the user. I think encapsulation is the key area to concentrate on when starting with OOP. Once you start to see how to use a class to represent an abstract idea, it will probably become easier to see how to string together operations on objects to create an entire program.
Something else to consider is the study of design patterns. The most famous book on this topic was written by the Gang of Four and is called, simply enough, Design Patterns (http://www.amazon.com/gp/product/0201633612/qid=1138247778/sr=11-1/ref=sr_11_1/002-2712588-0182457?n=283155). The idea here is that problems that are common in software engineering can be abstracted into reusable classes. I'm not sure that this would be a good place to start when just learning OOP, but once you get framiliar with it, this book will really be able to show you some of the benefits of OOP. The GoF book may be a bit dated, but the information it contains is still very vaild. If you prefer a book that is on the same topic but is more recent, just searching for design patterns should get you on your way.
I wish you good luck wrapping your head around OOP. I remember that I initially struggeled with the transistion, but luckly I was able to learn it early in my studies. In the end, OOP really is just a stylistic difference from functional programming -- anything that can be accomplished one way can be accomplished using the other. Just don't give up and keep reading as much as you can on the subject and hopefully it will become second nature soon enough.
--Edit--
One thing I forgot to mention: I would suggest learning OOP using Python. In Python, everything is an object yet you can still code in a procedural way if you like. However, once you start to understand OOP, the language will unfold before you. I don't have much experience with Ruby, but I understand it has a similar approach. So I suppose either language would be a good choice.
After seeing how horrible my proto-flowcharts were, I did some research and came across this link (http://www.developer.com/design/article.php/3304881). I think this will answer what you want to know.
Thanks, reading. :)
From http://www.developer.com/design/article.php/3317571 :
The fundamental advantage of OO programming is that the data and the operations that manipulate the data (the code) are both encapsulated in the object. For example, when an object is transported across a network, the entire object, including the data and behavior, goes with it.
Um, what?
Let's try and play this out practically. Let's say I have a C++-compiled program as the client, with some data, and it encapsulates that in an object.
On the other end, I have the server, which might be written in, say, Java. It then receives the object.
How the heck does that work? How could a Java server understand the behavioral annotations in the object? Sure, if you were to come up with some language-agnostic format for describing behaviour, say, XBL, and wrap it in that. But that's not what the article is saying.
The author seems to imply that you could transmit the methods of an object as part of the object. I would argue that's impossible.
Anyone care to clarify?
Wouldn't that be an example of APIs?
Access developers share their codes all time. There's a library of commonly used codes that you could load in your own project.
So instead of having to redraw "Ok" dialog boxes you just use the one that's already out there.
I'm not sure whether it's multi-lingual, though but then agian, *nix can use different flavors' library, provided that they are re-compiled.
Wouldn't that be an example of APIs?
Not in the way the author has worded it, at least nto to me.
So instead of having to redraw "Ok" dialog boxes you just use the one that's already out there.
Sure. But the way I read this is that an object is transmitted between two network peers (a client and a server), and that that object includes both data and behaviour. How do you define behaviour? Wouldn't behaviour be a set of methods? Accessors/getters/setters?
Now that I've read it second time, I realized I wasn't thinking the same thing.
You'll need to ask someone else; right off the top of my head is that with OO environment, you could wrap objects' behavior into the object (e.g. the black box), and give client the black box, so you know that the client's end will behave exactly the way you want it to as the black box brings with it its attributes.
Actually, the article is just wrong.
Object oriented programming doesn't involve encapsulating objects and sending them across the wire to other programs for processing (although that is possible if you were to design client/server applications to facililtate it, you wouldn't send "objects" through the wire though, you'd send data and it would be reassembled into an object by the receiver). The example they used of a "web object" is just wrong... the java applet is a fully functional application that just happens to run inside a browser it can only run if you have java installed, your java environment is set up, and your browser properly configured. The fact that java is an object oriented language has nothing to do with transmitting or running java applets.
Upon consulting my java network programming book... it appears there is something called RMI (Remote Method Invocation) which apparently allows a program to access methods of objects across the wire. And something else called CORBA which lets objects written in different languages communicate with each other.
This is definately beyond the scope for an introduction to OOP, or even an introduction to whatever programming language you plan on using (and actually CORBA is beyond the scope of my book too).
Perhaps you should go to the library and see if they have any books that explain it properly :)
Actually, the article is just wrong.
That's what I figured, sadly, which is why I asked.
Upon consulting my java network programming book... it appears there is something called RMI (Remote Method Invocation) which apparently allows a program to access methods of objects across the wire. And something else called CORBA which lets objects written in different languages communicate with each other.
I've heard of CORBA, but not of RMI.
This is definately beyond the scope for an introduction to OOP, or even an introduction to whatever programming language you plan on using (and actually CORBA is beyond the scope of my book too).
Perhaps you should go to the library and see if they have any books that explain it properly :)
Agreed. Well, I did order a book which a friend recommended to me; the first edition of this (http://www.amazon.com/gp/product/0131249339/104-1750825-7156731?v=glance&n=283155). I won't be able to read it for a while, however.
So in the meantime, I'll continue to try and find a decent non-printed introduction ;)
You might get something out of this A Gentle introduction to OOP (http://www.stc.org/confproceed/1994/PDFs/PG254256.PDF)
It only takes about five minutes to read (2 pages) and I found it on the Smalltalk website.
Well, that was a nice read, thanks. I guess reading it with fresh analogies was kind-of-helpful.
bassplayinMacFiend
2006-01-26, 08:38
From http://www.developer.com/design/article.php/3317571 :
The fundamental advantage of OO programming is that the data and the operations that manipulate the data (the code) are both encapsulated in the object. For example, when an object is transported across a network, the entire object, including the data and behavior, goes with it.
The author seems to imply that you could transmit the methods of an object as part of the object. I would argue that's impossible.
Anyone care to clarify?
Hey, that's what I said in my earlier post:
The idea behind OOP is encapsulation, everything related to an object is accessed through publicly defined functions. You don't just manipulate bookName directly, you use methods to get and set the bookName variable. The same applies to the other data elements, plus any object functionality you may add to the object.
I'm glad some of this stuff stuck in my head.
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.
The idea behind OOP is encapsulation, everything related to an object is accessed through publicly defined functions. You don't just manipulate bookName directly, you use methods to get and set the bookName variable. The same applies to the other data elements, plus any object functionality you may add to the object.
No, I totally get that part. That's nothing new to me. The idea, however, that this encapsulation can be transmitted not only over the network, but also across entirely different languages, seems absurd to me.
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. :)
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?
bassplayinMacFiend
2006-01-26, 09:13
No, I totally get that part. That's nothing new to me. The idea, however, that this encapsulation can be transmitted not only over the network, but also across entirely different languages, seems absurd to me.
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. :)
I agree. You need to learn the basics of OOP before you start delving into network stuff, serializing objects, etc. You can build tons of programs in OOP without ever opening a network port, so it does seem far beyond a basic description of OOP.
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 :o: ).
Mr Beardsley
2006-01-26, 10:54
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...
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?
Perhaps I'm not sure what you mean but, no I don't thing OOP is all about "seeing". OOP is about segregating your program into managable chunks which can be re-used (optimally).
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 :)
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?
bassplayinMacFiend
2006-01-26, 20:55
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
:) :)
I like this quote the best though:
The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
Yes, we still have COBOL programs as part of our daily data movement.
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
:eek:
I guess I'm in deep doo doo and even worse off than Chucker. :(
Actually, I started out with BASIC on a Commodore 64 when I was six. Maybe fundamentally, that's my problem. :)
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?
I see what you're saying :)
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.
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. :)
bassplayinMacFiend
2006-01-27, 16:46
Actually, I started out with BASIC on a Commodore 64 when I was six. Maybe fundamentally, that's my problem. :)
I traded my TI99/4A to my buddy for his C-64. He really liked a dungeon game I had for the TI. :)
[edit]
BASIC for the C-64 was created by MS. :D
vBulletin® v3.6.4, Copyright ©2000-2024, Jelsoft Enterprises Ltd.