How could I draw a straight line with the equation y=m*x+n in a jfreechart chart?
Sounds simple enough ... I've never used it, but there is a XYPlot class which sounds like a decent place to start. You can create one using the ChartFactory, to make it a bit easier. You will need to implement a class that implements the XYDataSet interface, to return the actual points (i.e. evalutate your equation).
Related
I apologize in advance if this is a "downvotable" question but I really need help in understanding how to know what to make classes out of in a VBA project.
NOTE: I am not asking how to code a class. I am asking how to determine what to make a class for.
Example
I want to draw shapes on a PowerPoint slide. 2 of the 3 kinds of shapes I need to draw have the same properties and methods. Would I create one class called CShape or 3 classes: CCircle, CSquare, CRectangle? Furthermore, lines are considered shapes in PowerPoint. Should I add a CLine class or just lump everything together in CShape?
I have searched Google for Methodologies on determining classes in VBA and the like but can not find anything. Does anybody out there have a method or way they go about determining how to create classes for their projects (and the reasons behind it)?
Also, I am just getting into classes and interfaces and this is the first project I am using them in. Thanks!
UPDATE
I did find this: When to use a Class in VBA?
When you work with code that can be reusable, this is the perfect time to use classes.
You need to create classes that have procedure to handle errors and possible wrong entries. As much robust you can create your code, your class will work as you expect.
I worked with PowerPoint and build some classes to manipulate document properties, another to manipulate slides, another to resize shapes.
You can find several classes examples from Chip Pearson site and you can figure out how to make your own classes.
http://www.cpearson.com/Downloads/Downloads.aspx
Hope this helps.
VBA (which is almost the same as Visual Basic 6) doesn't support inheritance.
So you have some options, using Interfaces would the normal way to deal with this, so probably three classes each on which implements the IDrawable interface. You may want to have a base class that deals with these features and have the outer classes call down to the base.
IDrawable might have public members for drawing, position, color and penwidth with the other parameters being part of the individual classes.
In particular you should read up on the Liskov substitution principle. I've seen examples of it using rectangles and squares as examples of what not to do.
See this older question for example Is deriving square from rectangle a violation of Liskov's Substitution Principle?
I have been using VBA for over 20 years, and made very little use of class modules.
The most useful cases for me were to build classes representing some structured spreadsheets or complex text files (with logical rows spanning over several physical lines) you may have to query or browse.
You can then implement a .MoveNext method and some properties like .EoF, .Price, .Rate to read them sequentially, being able to reuse that class everywhere you use that specific input file 'layout', and having the complex logic encapsulated in the class.
C++ Should I make one abstract class with many derived classes or just one general class?
Classic example is the abstract Shape object with derived classes Square and Triangle that hold specific geometry and functions.
Why don't I just make one general class called Shape that includes a more general geometry data member to hold a dynamic amount of points that could either be a square or a triangle?
Functions could take some parameter indicating what type of shape it was e.g. Shape.process("square"); instead of something like Square.process();
Is my question clear? Is this purely a stylistic choice?
You should avoid creating "god" classes that do a bunch of stuff. What if you will have to implement a lot of shapes? A class should have only one responsibility, should be open for extension and closed for modifications. Check the class design principles or the SOLID principles of design. You should avoid complicated design and big classes that have multiple responsibilities just because at a moment it will become a pain to maintain them or add extra functionality. Unit testing will also be something more easy to do with a good design.
You cannot get an answer to this type of question in general. It is going to depend on the situation and requirements for whatever problem you are attempting to solve. In some cases, it will make sense to have an interface with derived classes. In others, it will make sense to have a generalized class. Without knowing the requirements for the problem, you will get no real answer.
It really depends on what you need the Shape for. For example if you are just drawing it, then yeah a general Shape class that just draws line from point to point would be perfect (for polygons anyway). But what if you wanted to calculate the area. It would probably be easier to have a Square and Triangle class where the getArea() function uses the appropriate area formula. There is no hard and fast rule it simply depends on what you need them for
My goal is to implement a (very simple) strategy game.
For the moment, I'll start with the map and two characters (I want the terrain to affect them differently) to experiment with pathfinding
The problem is that I have very little or no experience in object oriented design. I've used C++ classes before, but it was pretty straightforward: for instance, a class Graph implemented using an array of sets, with a method AStar. I didn't have in mind the concept of "several players".
I've thought of the following elements/classes: Game, Map and Character. Eventually a Pathfinder class.
First question: the position of a character is something the game should know? The map? or each character?
( I think the game should )
Second question: where would it be a good choice for a "findPath" method?
The Game?
Should a pathfinding algorithm be a method of Map? Something like map.findPath(character, srcpos, dstpos)
In the Character class? It makes more sense to do character1.findPath(map, srcpos, dstpos)
If I added a Pathfinder class, it would have to build its own representation of the map in order to determine the shortest path. And before doing that, it would have "to ask" the map how the terrain affects each player.
( I prefer the latter )
It seems the construction of an auxiliary structure (and asking the map) to apply, let's say, A* is something that I can't avoid.
Making things object-oriented is not a goal, it's a tool to be used when it makes sense. C++ is a language with lots of functionality that you can easily drown yourself with, so my advice is to keep things simple and easy.
This can mean keeping data and logic tightly together sometimes, or separating it completely other times.
First question: My initial reaction is that the character should know its position. But how you represent it with data depends on how you intend to use it, so both the game, the character and potentially also the map needs to know where the character is.
Second question: It depends on what the Map class is. Is it an object representing the map itself with necessary functionality exposed to the rest of your program, or is it a toolbox of functions that works on a simple data representation of the map?
If the Map class represents the map, it should have the necessary functionality exposed for a Pathfinder class to work on it (the pathfinding algorithm will need to have some additional data derived from the map, maybe temporary, maybe persistent).
If the Map class does not represent the map, you can put the pathfinding functionality in it. I think it would belong there in that case. If the pathfinding code causes the Map class to get too big, you should separate it into its own class anyway.
First Question: The position of the character should be a part of character itself (makes sense this way) for me.
Second Question: Finding a path logically cannot be a part of Map. Then you would be violating one of OOP principles i.e. Single Responsibility.
According to me you should create the PathFinder class. You can design it in this way
class PathFinder{
PathFinderAlgorithm algorithm;
//other required values according to your design
Path findPath(){
algorithm.apply();
}
//other required methods according to your design
}
PathFinderAlgorithm is an interface.
Using this you can also change the algorithm that you are using to find the path. Like if you in future need to find the longest path, all you have to do is create another class which will find the longest path and replace it in the PathFinder class.
If I`m programming a game in which there is a worker that cuts wood (from trees), where would I put the "cutWood" method, in the worker class, or the tree class?
EDIT:
The first example I read on OOD was about a circle (a class called circle) which has in it a method called "calculate area".
Now, sure enough a circle doesn't calculate its own area.
The only way to think of it is that calculating area is an operation that is relevant to the circle (an operation done on the circle)
So, cutWood method is relevant to both, the worker, and the tree.
I don't see any cohesion to have a wood cutting method in the worker. The cutting is done on the tree, and should therefore be part of the tree class. Presumably, cutting the wood will also involve changing some internal state of the wood class too.
A worker should call the cut method on whatever tree he wants, rather than the tree telling the worker that he should cut it. If you want to abstract this like Hans has hinted at, you could make an ICuttable interface for the Cut method, and have your tree implement it.
Consider something you're familiar with, a String. When you want to cut a string (split), you don't define a splitString method in every object which is going to do this. Whatever object decides to split the string, the same thing takes place - and will usually need to know the internals of the target object (the string) in order to do it. Many other objects simply call the split method of the string. The string object has high cohesion - because it's methods contribute to a common task - manipulating strings.
I don't see how cutting wood contributes much to the worker object itself.
Ask yourself: Do workers cut wood, or do trees cut wood?
You basically answered it in your question: "a worker that cuts wood". You should put it to the worker class.
Create a
cut(Material m)
method for the worker for extra object-orientedness.
do you have to modify the tree as it is being cut?
do you have to modify the worker as it cuts a tree?
i would imagine you'd end up with a WoodCutting service which handles the event possibly modifications to both, or in turn calling worker.cutWood() AND tree.woodCut()
ahah what a question ;)
Sounds like a candidate for the Strategy pattern to me. You may need a WorkerAction abstract class with a performAction method. Then subclasses of the WorkerAction class will implement the details such as cutting a tree, digging for gold and other worker actions. So the sub class knows about the details of the tree and can call the necessary methods on the tree to affect the tree as it is being cut.
The worker class then only need a reference to an instance of a concrete WorkerAction on which it calls performAction(). The worker does not know the details of the Tree or the Gold etc. This way the worker can perform the action but you are not limiting the worker to only one action. In fact you no longer need to modify the worker class if you want your worker to do more actions in the future.
You could have a cutWood method in the worker class, and a cutted method in the tree class. Obviously, worker.cutWood calls tree.cutted, which might return the amount of wood harvested.
tree.cutted would do all the stuff that is necessary to let the tree die.
If you consider method calls as "messages sent from one object to another", it makes a lot more sense to say "the player sends a 'cut wood' message to the worker who in turn sends a 'cut' message to the tree".
Object design is all about assigning responsibilities to your classes. That means there really is no good answer to this question. As it all depends how you model the responsibilities in your design. (see: Larman)
Thus you need to decide what object/class is responsible for what. This will lead you to correct answers on question about were to place what kind of methods.
Thus ask you’re selves questions like: does the worker decide on his own to cut wood? If he does, he probably does not need to be ordered so, thus he will not have a need for a method cut(tree). But if the user can order him to do that, he will need a cut(tree) method. An other example: does the tree have to know he is cut? Well, if a cut tree just leads to his removal from the forrest, he might not have a need for such a tree.cut() method. But if you assign to the tree the responsibility to (re)draw himself during cutting, you might have a need for a tree.cut() method. The tree could even be modeled as having a width and that he can calculate how many cuts are needed before he collapses.
Since a single worker might cut more than one tree, it sounds more likely that you'd want to put cutWood() in the worker class.
Doesn't the cut() method go on the Saw object?
More seriously, I think of the target of the method call as the "subject", the method itself as a "verb", and its parameters (if the verb is transitive) as "direct objects." So, in this example, it would be worker.cut(tree).
This question can only really be answered if you explain what cutWood does.
If cutWood only affects the state of a Tree then it belongs in Tree e.g.,
public void cutWood() {
this.height = 0;
}
In the case of calculateArea you only need the radius of a circle (assume pi is constant) to do this calculation - nothing else. That's why it belongs in Circle.
Stop trying to model the real world too closely and look at what your method actually needs to do.
This is an intresting topic. I thought about a likewise scenario myself sometimes. I think a good way to go, is to put the method into the class with the highest cohesion. Therefore the Tree class would be the first choice. On the otherhand if you try to match a real world model i would say the Worker class has to be able to perform some kind of actions which includes cutting a Tree. I often find myself in these kind of situations and wonder where is the right place to put this method. Another approach would be a class which knows about worker and tree's, and therefore handles the cutting tree meachnism. This way both classes (tree,worker) would not know anything about it.
I'm coming from AS3 to Obj-C, and classes are confusing me. I want to create a ball class as a test, with colour, radius etc. Looking through other people's code I've discovered they use structs to implement them, and this seems like a much nicer method. I've searched but am unable to find a really clear explanation of what structs are, and how to implement them.
In terms of my ball class, to implement it I'd want to use something like Ball *myBall = [Ball radius:(14), mass:(1)]; etc. This seems like a nice clean way to do it. Can anyone suggest some further reading on this?
Thanks.
Read Apple's own Objective-C Primer. It's worth reading. The documents linked there are also useful. You know, vendors (in this case Apple) often have a nice set of documentations because they need to sell their technology...
For a comparison of ActionScript and Objective-C, see this series of blog posts for example.
Using classes straight of the bat would be a better idea as once you start developing you'll probably want to extend the functionality like object orientated methods (what classes are for).
Creating a class for ball with an appropriate constructor and properties would fit your needs.
I recommend starting here.