•
•
•
•
What is DaniWeb IT Discussion Community?
You're currently browsing the Java section within the Software Development category of DaniWeb, a massive community of 391,571 software developers, web developers, Internet marketers, and tech gurus who are all enthusiastic about making contacts, networking, and learning from each other. In fact, there are 2,780 IT professionals currently interacting right now! Registration is free, only takes a minute and lets you enjoy all of the interactive features of the site.
Please support our Java advertiser: Lunarpages Java Web Hosting
Views: 650 | Replies: 19 | Solved
 |
•
•
Join Date: Jun 2006
Location: India
Posts: 6,774
Reputation: 
Rep Power: 23
Solved Threads: 330
> For example, in the Piece constructor, I simply give an array of Positions the piece will be
> governed by, and code around the possible positions the piece can move from/to ?
Huh? I thought it was pretty clear that Piece should *not* have inking as to what it has to do. It goes something along these lines. A 'Player' makes a 'Move'. The 'CheckerEngine', validates the move, does the necessary operations and updates the 'Board'.
> This can easily be changed by adding a 3rd dimension to the points and simply coding
> around it.
It's just a thought, I am not asking you to add a third dimension but abstract away the dimensional aspect of your game by encapsulating it in a class so that the contract of the methods which use them doesn't change, only the implementation does. Something roughly along the lines of:
Though the idea is pretty vague, I hope you get the point.
> governed by, and code around the possible positions the piece can move from/to ?
Huh? I thought it was pretty clear that Piece should *not* have inking as to what it has to do. It goes something along these lines. A 'Player' makes a 'Move'. The 'CheckerEngine', validates the move, does the necessary operations and updates the 'Board'.
> This can easily be changed by adding a 3rd dimension to the points and simply coding
> around it.
It's just a thought, I am not asking you to add a third dimension but abstract away the dimensional aspect of your game by encapsulating it in a class so that the contract of the methods which use them doesn't change, only the implementation does. Something roughly along the lines of:
public class Position {
private int x;
private int y;
// and many other things
}
// With the position abstraction for 2D
public void renderPiece(Position pos) {
// Draw something at (x, y)
}
// With position abstraction for 3D
public void renderPiece(Position pos) {
// Draw something at (x, y, z)
}
// Without position abstraction for 2D
public void renderPiece(int x, int y) {
// Draw something at (x, y)
}
// Without position abstraction for 3D
public void renderPiece(int x, int y, int z) {
// Draw something at (x, y, z)
}Though the idea is pretty vague, I hope you get the point.
"I don't accept change. I don't deserve to live."
"Working a real job is a win if you're lazy, greedy, or unmotivated. If you're average, you fit right in. And if you're above average, the basic terms of employment and premise of the arrangement is against your interests."
"Working a real job is a win if you're lazy, greedy, or unmotivated. If you're average, you fit right in. And if you're above average, the basic terms of employment and premise of the arrangement is against your interests."
•
•
Join Date: Jun 2008
Location: Washington
Posts: 603
Reputation:
Rep Power: 3
Solved Threads: 50
Practically a Master Poster
I think I am starting to understand the Position concept. For some reason it's not clicking immediately, maybe it's because I'm not looking at the big picture like I really should be.
By the way, here's the current debugging that I'm using to test the functionality of the board using the temporary displayBoard() method I mentioned earlier.
I'm trying to chase down the error in the last board (where 5, 2 isn't marked as a challenger, even though it really is Red's turn still).
By the way, here's the current debugging that I'm using to test the functionality of the board using the temporary displayBoard() method I mentioned earlier.
init: deps-jar: Compiling 1 source file to F:\RemakesAndNEwProjects\Java_Folder\Checkers_Project\build\classes compile-single: run-single: Starting with Red's turn... [ ][b][ ][b][ ][b][ ][b] [b][ ][b][ ][b][ ][b][ ] [ ][b][ ][b][ ][b][ ][b] [ ][ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ][ ] [R][ ][R][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 0 Red -Attempting to move from: (0, 5) to (1, 4) 1 SingleMove: Red is no longer a challenger. Black's turn. true [ ][b][ ][b][ ][b][ ][b] [b][ ][b][ ][b][ ][b][ ] [ ][b][ ][b][ ][b][ ][b] [ ][ ][ ][ ][ ][ ][ ][ ] [ ][R][ ][ ][ ][ ][ ][ ] [ ][ ][R][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 0 Black -Attempting to move from: (3, 2) to (2, 3) -1 SingleMove: Black is no longer a challenger. Red's turn. true [ ][b][ ][b][ ][b][ ][b] [b][ ][b][ ][b][ ][b][ ] [ ][b][ ][ ][ ][b][ ][b] [ ][ ][b][ ][ ][ ][ ][ ] [ ][R][ ][ ][ ][ ][ ][ ] [ ][ ][R][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 0 [ ][b][ ][b][ ][b][ ][b] [b][ ][b][ ][b][ ][b][ ] [ ][b][ ][ ][ ][b][ ][b] [ ][ ][b][ ][ ][ ][ ][ ] [ ][R][ ][ ][ ][ ][ ][ ] [ ][ ][R][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 1 (1, 4) Black Challengers: 1 (2, 3) Red -Attempting to move from: (1, 4) to (3, 2) 2 JumpMove: Red is no longer a challenger. Black's turn. true Incorrect piece selected! [ ][b][ ][b][ ][b][ ][b] [b][ ][b][ ][b][ ][b][ ] [ ][b][ ][R][ ][b][ ][b] [ ][ ][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ][ ] [ ][ ][R][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 2 (2, 1)(4, 1) Red Challengers: 0 Black Challengers: 2 (2, 1)(4, 1) Black -Attempting to move from: (2, 1) to (4, 3) 2 JumpMove: Black is no longer a challenger. Red's turn. [ ][b][ ][b][ ][b][ ][b] [b][ ][ ][ ][b][ ][b][ ] [ ][b][ ][ ][ ][b][ ][b] [ ][ ][ ][ ][b][ ][ ][ ] [ ][ ][ ][ ][ ][ ][ ][ ] [ ][ ][R][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 0 Red -Attempting to move from: (2, 5) to (1, 4) -1 SingleMove: Red is no longer a challenger. Black's turn. [ ][b][ ][b][ ][b][ ][b] [b][ ][ ][ ][b][ ][b][ ] [ ][b][ ][ ][ ][b][ ][b] [ ][ ][ ][ ][b][ ][ ][ ] [ ][R][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 0 Black -Attempting to move from: (4, 1) to (3, 2) -1 SingleMove: Black is no longer a challenger. Red's turn. [ ][b][ ][b][ ][b][ ][b] [b][ ][ ][ ][ ][ ][b][ ] [ ][b][ ][b][ ][b][ ][b] [ ][ ][ ][ ][b][ ][ ][ ] [ ][R][ ][ ][ ][ ][ ][ ] [ ][ ][ ][ ][R][ ][R][ ] [ ][R][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 0 Red -Attempting to move from: (1, 6) to (0, 5) -1 SingleMove: Red is no longer a challenger. Black's turn. [ ][b][ ][b][ ][b][ ][b] [b][ ][ ][ ][ ][ ][b][ ] [ ][b][ ][b][ ][b][ ][b] [ ][ ][ ][ ][b][ ][ ][ ] [ ][R][ ][ ][ ][ ][ ][ ] [R][ ][ ][ ][R][ ][R][ ] [ ][ ][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 0 Black Challengers: 0 Black -Attempting to move from: (4, 3) to (5, 4) 1 SingleMove: Black is no longer a challenger. Red's turn. [ ][b][ ][b][ ][b][ ][b] [b][ ][ ][ ][ ][ ][b][ ] [ ][b][ ][b][ ][b][ ][b] [ ][ ][ ][ ][ ][ ][ ][ ] [ ][R][ ][ ][ ][b][ ][ ] [R][ ][ ][ ][R][ ][R][ ] [ ][ ][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 2 (4, 5)(6, 5) Black Challengers: 0 Red -Attempting to move from: (4, 5) to (6, 3) 2 JumpMove: Red is Still a challenger. Red's turn. [ ][b][ ][b][ ][b][ ][b] [b][ ][ ][ ][ ][ ][b][ ] [ ][b][ ][b][ ][b][ ][b] [ ][ ][ ][ ][ ][ ][R][ ] [ ][R][ ][ ][ ][ ][ ][ ] [R][ ][ ][ ][ ][ ][R][ ] [ ][ ][ ][R][ ][R][ ][R] [R][ ][R][ ][R][ ][R][ ] Red Challengers: 1 (6, 3) Black Challengers: 1 (7, 2) BUILD SUCCESSFUL (total time: 4 seconds)
I'm trying to chase down the error in the last board (where 5, 2 isn't marked as a challenger, even though it really is Red's turn still).
Last edited by Alex Edwards : 31 Days Ago at 3:36 pm.
•
•
Join Date: Jun 2008
Location: Washington
Posts: 603
Reputation:
Rep Power: 3
Solved Threads: 50
Practically a Master Poster
•
•
•
•
Originally Posted by ~s.o.s~ 
Design choices you make have to direct impact on your thought process. Had not the pieces implemented theMoveableinterface, would the flow have remained the same? Does the 'Moveable' interface logically make sense? And now do you really think that 'GameBoard' sounds like an Interface name or more so like a name of a Class? Would it make any difference if it were not an interface? Does making it an Interface solve any immediate problem you face?
This is absolutely correct.
I need to take a step back and rethink the design.
Once I'm finished getting it to work, I think I'll write out what objects/functions are dependant on each other, re-write the design, then add concepts that are necessary to get things going (for example, an Engine is made up of parts. I should be delegating specific jobs to the right engine parts to make a CheckersEngine functional).
I'd like to email you my "junk" code as it is before dismembering it later.
I know it's kinda against the rules, and I'm sorry but I really don't want someone else in the class to have any copy of the assignment. I'm technically weeks ahead of the due date and I'm nearly done getting the game to be restrictive to the rules of Checkers, all that is left is making the GUI (easy) and making the Client/Server with Multi-threading (I'm assuming it will be harder than I think).
Last edited by Alex Edwards : 31 Days Ago at 5:19 pm.
•
•
Join Date: Jun 2006
Location: India
Posts: 6,774
Reputation:
Rep Power: 23
Solved Threads: 330
> I know it's kinda against the rules
And the reason it is against the rules is because instead of the thousands of beginners / needy out there, only a single person gets the solution. Reading individualistic emails / PM's would be kind of difficult given the little time I get for helping people out, not to mention the moderation duties which need to be performed. I hope you understand.
You have been supplied with a lot of good ideas and I am pretty sure you will be able to come with a relatively better implementation than your peers. And hey, getting things right in the first go is kind of a sin. :-)
And the reason it is against the rules is because instead of the thousands of beginners / needy out there, only a single person gets the solution. Reading individualistic emails / PM's would be kind of difficult given the little time I get for helping people out, not to mention the moderation duties which need to be performed. I hope you understand.
You have been supplied with a lot of good ideas and I am pretty sure you will be able to come with a relatively better implementation than your peers. And hey, getting things right in the first go is kind of a sin. :-)
"I don't accept change. I don't deserve to live."
"Working a real job is a win if you're lazy, greedy, or unmotivated. If you're average, you fit right in. And if you're above average, the basic terms of employment and premise of the arrangement is against your interests."
"Working a real job is a win if you're lazy, greedy, or unmotivated. If you're average, you fit right in. And if you're above average, the basic terms of employment and premise of the arrangement is against your interests."
•
•
Join Date: Jun 2008
Location: Washington
Posts: 603
Reputation:
Rep Power: 3
Solved Threads: 50
Practically a Master Poster
•
•
•
•
Originally Posted by ~s.o.s~
> I know it's kinda against the rules
And the reason it is against the rules is because instead of the thousands of beginners / needy out there, only a single person gets the solution. Reading individualistic emails / PM's would be kind of difficult given the little time I get for helping people out, not to mention the moderation duties which need to be performed. I hope you understand.
You have been supplied with a lot of good ideas and I am pretty sure you will be able to come with a relatively better implementation than your peers. And hey, getting things right in the first go is kind of a sin. :-)
Do you use NetBeans? I can draw out some example diagrams of possible designs to code around by making interfaces and using Reverse Engineering (or simply starting from scratch).
I've already, on paper, written out a few possible designs but I am not sure any of them make sense.
Even if something does make sense, applying the concept is a lot harder than simply simulating a theory.
For example, I currently have my pieces being added to the CheckersEngine, which I don't know if it really makes sense.
It would make sense if the pieces were demoted to a different class like...
wait... is this where posiiton would come in? Is this what you were trying to explain to me?
It would make sense for a CheckersEngine to keep track of Positions, then have a GameBoard (which implements displayable) take GamePieces (which implements displayable also) and simply display the pieces based on the location of the Positions within the CheckersEngine.
In order to interact with the pieces I'll most likely have methods in the Engine to select a position if the turn is correct.
Ok... before I continue, am I on the right track?
Edit: If I'm tracking positions, and simply make extensions of Position objects, I can load the engine with the custom extensions, where the engine simply keeps track of the Positions, but I can possible find a way to make the position displayable... bah... serious mind blocks @_@
This is much harder than simply "coding."
Last edited by Alex Edwards : 30 Days Ago at 11:34 pm.
•
•
Join Date: Jun 2008
Location: Washington
Posts: 603
Reputation:
Rep Power: 3
Solved Threads: 50
Practically a Master Poster
I re-thought the process of making the game, and started from scratch pretending I knew nothing and didn't start coding.
I know what I need for the game.
-I need a way for the user(s) to interact with each other during play (Client/Server)
-I need a way for the users to see the game (Display)
-I need a way for the game to be restricted to the rules of some game (Engine)
I know that these are the fundamental elements, and have no real order.
From here I've decided to place these 3 classes away from each other. I know that they will have relationships with each other, I just don't know how yet.
I'm trying to look at the big picture.
The first thing the users need to do is connect to the Client/Server, so I'll make a class called Connect that will deal with the connection of the clients to the server.
When the users are Connected, the game should be displayable. The question is what should I use to tie the Client/Server with the Display, and the Engine in all of this?
I suppose I need a new object called UserInterface that encapsulates the Connect and Display objects.
The UserInterface will have commands that allow the user(s) to interact with the Display. The Display has commands that accept coordinates, but Display is either an abstract class or interface so it must be redefined.
Because Display is just a Display, I'd like to have more functionality so I created a derived object called GameDisplay. Before I could implement methods, I thought to myself "a GameDisplay does more than just move pieces. Games in general don't just move pieces, sometimes they just show things but I want these users to interact with pieces!" So I stopped myself and derived an object called BoardGameDisplay where Board games are known to have pieces, therefore it is acceptable to have commands like selectPiece(int, int) to select a piece at a given location. The int arguments are provided for dual functionality between Mouse and Keyboard messages (and possibly other joysticks too). BoardGameDisplay IS-A display so it also has a display() command just like a general display object.
This is nice and dandy, but the display has no idea what it should be restricting the user to, so I decided to make an Engine object. I don't know how a display works with an Engine directly, but I guess I can make a general GameDisplay Object take a GameEngine that will decide how objects will be displayed. I decided to make the GameEngine much less general by turning it into a BoardGameEngine, but GameEngine will still have its functionality, such as do(Command c), where Command will be specific commands for a game (in this case I'll make them very general but they will exist).
I'm close to something, I can feel it. This makes some sense finally and it's a design I like. It also shows some essence of potential re-use but I can't see it right away.
I know what I need for the game.
-I need a way for the user(s) to interact with each other during play (Client/Server)
-I need a way for the users to see the game (Display)
-I need a way for the game to be restricted to the rules of some game (Engine)
I know that these are the fundamental elements, and have no real order.
From here I've decided to place these 3 classes away from each other. I know that they will have relationships with each other, I just don't know how yet.
I'm trying to look at the big picture.
The first thing the users need to do is connect to the Client/Server, so I'll make a class called Connect that will deal with the connection of the clients to the server.
When the users are Connected, the game should be displayable. The question is what should I use to tie the Client/Server with the Display, and the Engine in all of this?
I suppose I need a new object called UserInterface that encapsulates the Connect and Display objects.
The UserInterface will have commands that allow the user(s) to interact with the Display. The Display has commands that accept coordinates, but Display is either an abstract class or interface so it must be redefined.
Because Display is just a Display, I'd like to have more functionality so I created a derived object called GameDisplay. Before I could implement methods, I thought to myself "a GameDisplay does more than just move pieces. Games in general don't just move pieces, sometimes they just show things but I want these users to interact with pieces!" So I stopped myself and derived an object called BoardGameDisplay where Board games are known to have pieces, therefore it is acceptable to have commands like selectPiece(int, int) to select a piece at a given location. The int arguments are provided for dual functionality between Mouse and Keyboard messages (and possibly other joysticks too). BoardGameDisplay IS-A display so it also has a display() command just like a general display object.
This is nice and dandy, but the display has no idea what it should be restricting the user to, so I decided to make an Engine object. I don't know how a display works with an Engine directly, but I guess I can make a general GameDisplay Object take a GameEngine that will decide how objects will be displayed. I decided to make the GameEngine much less general by turning it into a BoardGameEngine, but GameEngine will still have its functionality, such as do(Command c), where Command will be specific commands for a game (in this case I'll make them very general but they will exist).
I'm close to something, I can feel it. This makes some sense finally and it's a design I like. It also shows some essence of potential re-use but I can't see it right away.
•
•
Join Date: Jan 2008
Posts: 1,403
Reputation:
Rep Power: 6
Solved Threads: 179
Here is my approach, based on what i believe the reasonable assumptions should be. One, a good checkers game should be able to function in a variety of environments. Thus it should be written so that it can play the game so that it can be played using sockets using multiple computers or on a single computer without having to be completely rewritten. Thus the Engine and the Display should be written so as to be independent of the socket communication code/classes. The Display should be written in a way that the Engine can be rewritten to account for different checkers rules and the Display would not need to be rewritten at all. The Engine should be written so that the Display could be made into a console a display rather than a GUI display class and the Engine would not have to be rewritten. The Socket class should not care about the rules and should not care about the rules of the game and should not care about whether the Display is GUI or console. Board and Piece similarly should be written to not care whether Display is console or GUI.
So, one thing to consider. What starts the whole thing off Where should main be and how does the pre-game socket connection occur? You can have the socket connection dance start immediately when the program starts, thus having the IP and port information that the sockets need hard wired into the code or you can have a JPanel that is independent of the Display GUI where there are buttons that a user can push to sponsor a game (be the host/server computer) or to join another game (be the guest/client computer), and you can ask the user for the IP/port information when those buttons are clicked.
So since we want versatility, main should not be in the Engine, it should not be in Display, and it should not be in the socket communication class. So write a Main class and stick main in there. Let's say that you decide that you want to have the IP/port information hard coded (or passed by command line argument to main), and a computer knows whether it is the server or the client also by command line argument. If you decide that the client will always be black and the server will always be red, and that the guest always moves first, you only need one socket for all of this, which the server, started first, will create and listen to, and the guest will connect to. So main is in Main and is run and it creates the socket connection and when it connects, then it makes a call to the Display class (or some middle class that coordinates everything) to paint the board and the pieces.
You're doing a GUI, so let's have a MouseListener and a Move class. A piece is selected and a Move function is called from the Display class, which interacts with the Engine and returns the possible legal moves based on the rules. Assuming there is at least one move using that piece, the board is redrawn with the possible moves highlighted. The user clicks on the square that finishes the move, a Move function is called to actually make the move (communicating with the Engine class) and update the Board and Pieces, then redraw the board/pieces. That Move class function then calls the Socket class, which sends the two grid coordinates which comprise the move that was made down the socket, the Socket class on the other calls the Move class function, which implements the move and updates the board, pieces, and now it's the other player's turn and they select their move on the board just like the last player did, call the Move class function, update the board, send the coordinates down the socket, etc.
So if you change anything (i.e. no sockets, console instead of GUI, etc., rules of the game, etc.), the whole thing doesn't have to be written. The socket class is concerned only with socket communication. Remove the sockets and Move stays the same except you are commenting out the last step where it calls the socket class functions. Board and Piece don't care about the Display or the Engine. Display is "dumb" concerning the rules and the sockets. Move handles all of the coordination between the Engine and the sockets and the display. Main is small and simply gets things started. I think that's the best, most versatile, and easiest to revise approach.
So, one thing to consider. What starts the whole thing off Where should main be and how does the pre-game socket connection occur? You can have the socket connection dance start immediately when the program starts, thus having the IP and port information that the sockets need hard wired into the code or you can have a JPanel that is independent of the Display GUI where there are buttons that a user can push to sponsor a game (be the host/server computer) or to join another game (be the guest/client computer), and you can ask the user for the IP/port information when those buttons are clicked.
So since we want versatility, main should not be in the Engine, it should not be in Display, and it should not be in the socket communication class. So write a Main class and stick main in there. Let's say that you decide that you want to have the IP/port information hard coded (or passed by command line argument to main), and a computer knows whether it is the server or the client also by command line argument. If you decide that the client will always be black and the server will always be red, and that the guest always moves first, you only need one socket for all of this, which the server, started first, will create and listen to, and the guest will connect to. So main is in Main and is run and it creates the socket connection and when it connects, then it makes a call to the Display class (or some middle class that coordinates everything) to paint the board and the pieces.
You're doing a GUI, so let's have a MouseListener and a Move class. A piece is selected and a Move function is called from the Display class, which interacts with the Engine and returns the possible legal moves based on the rules. Assuming there is at least one move using that piece, the board is redrawn with the possible moves highlighted. The user clicks on the square that finishes the move, a Move function is called to actually make the move (communicating with the Engine class) and update the Board and Pieces, then redraw the board/pieces. That Move class function then calls the Socket class, which sends the two grid coordinates which comprise the move that was made down the socket, the Socket class on the other calls the Move class function, which implements the move and updates the board, pieces, and now it's the other player's turn and they select their move on the board just like the last player did, call the Move class function, update the board, send the coordinates down the socket, etc.
So if you change anything (i.e. no sockets, console instead of GUI, etc., rules of the game, etc.), the whole thing doesn't have to be written. The socket class is concerned only with socket communication. Remove the sockets and Move stays the same except you are commenting out the last step where it calls the socket class functions. Board and Piece don't care about the Display or the Engine. Display is "dumb" concerning the rules and the sockets. Move handles all of the coordination between the Engine and the sockets and the display. Main is small and simply gets things started. I think that's the best, most versatile, and easiest to revise approach.
•
•
Join Date: Jun 2006
Location: India
Posts: 6,774
Reputation:
Rep Power: 23
Solved Threads: 330
The craft of good design comes from knowing what a bad design is. Unless you do something wrong, you won't know what is right. It's about time you started implementing something and stopped achieving maximum perfection. Re factoring is a part and parcel of software development and IMO is the thing which makes you learn. This thread has many good contributions so the only thing which remains to be done is; Just do it!
"I don't accept change. I don't deserve to live."
"Working a real job is a win if you're lazy, greedy, or unmotivated. If you're average, you fit right in. And if you're above average, the basic terms of employment and premise of the arrangement is against your interests."
"Working a real job is a win if you're lazy, greedy, or unmotivated. If you're average, you fit right in. And if you're above average, the basic terms of employment and premise of the arrangement is against your interests."
•
•
Join Date: Jun 2008
Location: Washington
Posts: 603
Reputation:
Rep Power: 3
Solved Threads: 50
Practically a Master Poster
•
•
•
•
Originally Posted by ~s.o.s~
The craft of good design comes from knowing what a bad design is. Unless you do something wrong, you won't know what is right. It's about time you started implementing something and stopped achieving maximum perfection. Re factoring is a part and parcel of software development and IMO is the thing which makes you learn. This thread has many good contributions so the only thing which remains to be done is; Just do it!
I've tried hard to prevent a bad design, but you're right. I probably wont know until I experience a bad design (for example, make a design then later realize the flaws of the design when it comes to versatility and adding new features).
Apparently I have quite a lot to learn about OOD and OOP. I'll probably stick with one design during the course, then after I'll remake this project a few times using some of the designs here and some of my own to get some practice in.
I'll also probably look at all of my old OLD projects and try to make a better design with the concept behind them.
I really didn't think something like this would be this hard. It's going to take awhile, and a lot of study and practice, but I am going to eventually figure it out.
•
•
Join Date: May 2007
Location: USA
Posts: 2,599
Reputation:
Rep Power: 11
Solved Threads: 257
•
•
•
•
Originally Posted by Alex Edwards
I really didn't think something like this would be this hard. It's going to take awhile, and a lot of study and practice, but I am going to eventually figure it out.
While good design skills only come with experience, there are several good books available with valuable and thought-provoking advice. If you're interested, I would recommend:
Design Patterns: Elements of Reusable Object-Oriented Software - the canonical book on software design patterns. You will surely here criticism regarding the overuse of patterns and some can certainly be "overkill" for a lot of simple design tasks, but reading and knowing about them will give you a perspective on design and object interaction that you won't get from simple coursework or tutorials.
Refactoring: Improving the Design of Existing Code covers just what the title says: Improving the design of code you already have written and working.
Code Complete, Second Edition has all kinds of useful information and advice on many aspects of programming, design, and software project management. While geared more towards working professionals rather than students, there is a wealth of information for students who wish to look beyond the basics and into things that professionals deal with in larger projects.
|
•
•
•
•
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
•
•
•
•
•
•
•
•
DaniWeb Java Marketplace
Linear Mode
•
•
•
•
- Previous Thread: Chatting Program - Throws IO Exception
- Next Thread: topics for java project
