how to start programming in practice?
i am still at my java class (course)
have been reading all for the third time (first time years ago,
second time last year, third time now)
finally i do 'understand' the theory, i could reproduce excercises,
but it seems i don't know how to really do something myself ...
i understand the concept of a class, to write a constructor (how to overload it, and override)
to create an object, how to give it real values, to create methods.
variables, constants, super, this, ...
i understand, abstract classes, interfaces,
and also if, while, for, case, etc
(don't worry about my vocabulary, i'm bad with words...)
but i have so many difficulties to know how to start, if i have an assignment, how to approach it, how to decide what will be the classes, and certainly if i have decided a few good things how to complete it. it seems there are always in new assignment things that 'pop up from nowhere'
it is as if i have a large box of lego, but have no plate to build on, nor a plan, and never seen one, except for completed programs written by others, but don't know where they started.
i don't know where to begin, how to start, what to do first, etc
i sound more desperate than i actually am (but well ... words ....)
maybe experienced people here could tell me about their/your approach ?
It depends on what the program needs to do. The best approach is to build it in pieces- figure out what the large chunks are, write a separate class for each chunk and as you go, test each piece so when its all put together everything works. Start with the smallest piece that functions on its own and keep adding on until you approach something usable, debugging as you go. Also sometimes after the thing is half finished you discover that the way you divided the classes up is ugly and you have to break them apart into different classes or functions.
Hope that helps.
Yes the best way is to do schematics (flow charts). Often they just focus on the language, but this can lead to bad design if you can't step outside of that and determine what it is you want to do. In other words it leads to botchy patchy code.
You should do two types of schematics. The first one is the basic model, which outlines in lay terms how you want it to work. After you have done that you do a second one which is the actual software architecture. It is at this stage you can use references, what you know, etc but you aren't actually coding yet.
I think languages like Java are bad for beginners. I would try a procedural language first. something like Perl, Pascal, C
etc. because you can focus on the language itself and the logic flow through your program instead of focusing on the
object model before you can even start. the APIs are usually a lot more simple in a procedural language as well.
Just install Linux or some other Free UNIX and try out all of the different languages avialable until you find something you like. even PHP can be a nice simple start. once you learn to make a good structured program you can take what youve learned and learn how objects can be useful to you and apply them to solve really complex problems.
I could get a good book with lots of practical examples in it. don't look for the first glossy book onthe subject you get, look aroudn for reviews and what the pros use. find the best quality book you can find that fits your learning style and dive in. and learn by programming.
Another thing to keep in mind while learning is in order to write a program you have to have a problem you wish to solve. pick something that you wish to solve using a computer, even if software already exists for that problem and work out how you want to make that happen. try to visualize the entire process in your head from start to finish and then onc eyou have a pretty good idea of the process then you implement the process using the library calls, operators, data structues and flow control statements your language of choice provides. and if somethign doesnt work as expected experiment with it until you understand why it doesnt work the way you expect and then fix it using what you've learned.
Once you have mastered one language learning your next one wont be very hard as almost every fundamental principal you learned with one language can be readily applied to another (it may just be said in a slightly different way, or in some cases its the same)
In terms of how to set up an object oriented application, you just need to think about what your program does, and what objects it will have. More specifically, what classes of things are in it. Don't think of things programaticially at first, you don't need to care about the actual code until you figure out what objects (read: nouns) you need and what they are capable of doing. For example, say we have a forum such as this one.
In VERY simplified terms, you'd have this setup.
These are the things in your application:
Users
Threads
Posts
These things are capable of performing these actions:
Users can create threads, and can have many threads.
Users can make posts on threads.
Users can edit posts.
And these things have these properties:
Threads can have many posts.
Any given post belongs to any given user or thread.
And so on and so forth.
Once you've got that set up, the classifications of things you come up with are your classes, the actions they can do are the methods, and the things that they own or properties they have are the attributes (or properties, or class variables, depending on what you call them). Once you've got that down you can start writing code.
As a side note, I also agree that Java is a bad language for beginners wanting to learn OOP (or really, a bad language in general from a theoretical perspective, but in practice it's an industry standard so it's likely you'll use it at some point). Personally, if you really want to learn how to do object oriented programming, I would say a language like Python, Ruby, or Smalltalk would be a better choice to learn from, but Java does the job (For the record, I learned OOP on C++, which is arguably worse than Java for OOP from a theoretical standpoint).
thanks corvillus,
could you tell me more about your 'what it does system',
on the one hand i learn the vocabulary (theoretical and by looking at programs of others), so that i can use it,
on the other hand i have to conceptually visualise it, it's because i have no experience that i have difficulties doing so.
especially at the level of putting it all together.
i might be able to say what kind of stuff is going to be needed (although i also forget about things, and have a hard time finding what those things are) but how to make that in one program is difficult.
could you tell me how you put all the elements together (conceptually) once you have your 'objects' written?
as for the choice of the language, as said i have no choice it's a class (course) at the univ
(i do like it but i am in a class with people with a higher level, they can already program, i think they know C++, so they skipped some steps, i come from literature, no program experience, only a basic java class last year)
OK, take an online store. I think we can both agree that a store's purpose is to provide products to customers, and perform transactions to collect money for said products.
So right off the bat, you can say that you'll have these things involved in your application:
-customers
-products
-transactions
Which gives us classes Customer, Product, and Transaction
Now, let's look at what a customer can do in the store:
add items to their shopping cart
remove items from their shopping cart
checkout
Now we get 3 methods in Customer from this, addToCart, removeFromCart, checkout. But also, we introduced another object in this process, the shopping cart itself. Which means we now need to have a ShoppingCart class. In addition, we need to have a ShoppingCart object as a property of the Customer class, since each customer has a shopping cart.
Shopping carts can really only add or remove products, they don't do anything else. So we'd have an addProduct and removeProduct method.
OK, now onto the products, those basically just have a few properties, like name, price, id. Maybe more but we'll keep it simple for now.
So we should have something like this
ShoppingCart cart;
void addToCart(Product product) {
cart.add(product);
}
void removeFromCart(Product product) {
cart.remove(product);
}
Transaction checkout() {
// do something to process the transaction and return it
}
}
class Product {
float price;
String name;
int id;
}
class ShoppingCart {
Vector<Product> products;
void add(Product product) {
products.add(product);
}
void remove(Product product) {
products.remove(product);
}
}
class Transaction {
//whatever you'd need for transactions
}
Anyway...that's extremely simplified and incomplete, but you should get the idea. Think of what your program needs to have in it, model those as objects, then think of what those objects have, belong to, and can do. Then write the classes and methods for them.
After all your classes are set up, your actual program shouldn't need to do very much other than instantiate some objects and use them based on input given by the user, then provide output to the user of the results. Although in most larger applications even this task has it's own object(s) (typcially called controller(s)), and the actual main() method does little other than initialize objects and get the ball rolling.
After all your classes are set up, your actual program shouldn't need to do very much
... the actual main() method does little other than initialize objects and get the ball rolling.
I think you have made the important point here, Corvillus. The beauty of OOP is that you spend a lot of time, digging around in classes, getting their properties and methods sorted out, and then - as if by magic - the program is complete!
[quote="lemon]... could you tell me how you put all the elements together (conceptually) once you have your 'objects' written? ...[/quote]
In other words, the answer to this us "You don't... you've finished the program."
In practice, once you have got all your objects written, you find yourself being forcibly reminded of all those places where you weren't quite sure exactly what you wanted a method to be doing - all the "stub" code you wrote for those bits starts complaining. Plus all those useless(!?) cross-checks for errors - that you were sure wouldn't ever happen - do happen.
But just once in a while, it all works perfectly, first time.
_________________
"Striking up conversations with strangers is an autistic person's version of extreme sports." Kamran Nazeer
hm sounds encouraging ...
i think i can do that raw draft of what will need to be done (but as said i always miss
some important things)
but i need more than that to have a real program.
to say that in a game, i have a snake, food, and obstacles
and that the snake can die, eat, grow, move
and that the user can click
and that we need a frame, a canvas, mouseEvents, ...
is ok,
but i have no idea how to make a snake grow, or move
how to make my frame so that i can control all these squares where it can move
etc
and yeah, i can look at examples, but it's different every time,
i'd need some kind of way of reasoning for myself i think
and how to make these objects interact with eachother
some kind of path laid out, or understanding how someone comes to make that path in a particular way.
just like i first didn't know that i had to make a snake class, i couldn't even tell the difference
between a class and a method.
Similar Topics | |
---|---|
What's your favorite way to practice piano? |
17 Oct 2024, 3:18 pm |
Grace Hopper - Pioneer of Computer Programming |
24 Oct 2024, 10:47 pm |