MatPolygonDraw: LF More Responsibility, Better Name.

So, naming scheme aside, my "MatPolygonDraw" function is quite a capable function. It defines the vector of colors used to determine the fill color of the polygon in question, it draws the labels for each point, the bounds of the full shape, and the lines connecting each point to the maximum value for that point. In achieving these goals, it takes an input string, checks it for validity, determines its numerical value, converts the numerical value combined with its string position to work out the variable the value applies to and then determine X,Y coordinates of where that point is.

I'm sure it does more, but, meh, I'm still working on it so there's no need to keep explaining it. I updated it today to contain a nested class entitled matButton, a subclass of the JButton. Now, rather than creating a new JButton and assigning it an actionListener to make everything work as it should, the frame that hosts the MatPolygonDraw instance simply calls the getButton class, passes any pertinent information over, and receives a new JButton appropriately configured for the task.

Tomorrow will see the expansion of this concept. Rather than just the the JButton, I'll include the JTextField component and place both of them on a panel. This way I'll just call getInputPane or whatever I decide to name it and I'll receive both of these, properly configured. I'll do the same to create a getEditPane for manipulating the material's properties, and any other panes I may need to accomplish any task I can imagine that requires a material graphic interpretation.

Then I just make the structure for any other objects that need manipulation, I go ahead and follow the same process for getting the necessary interfaces, and voila, simple finished product.

In other words, I think I'm getting this, because suddenly I'm realizing just how little  work I'll have to put into the final assembly of everything compared to the creation of the manipulating classes.

In all, I'm content. It's time for bed though, and that leaves this post open for discussion. Any recommendations for a better name for this class? Preferably something that defines what it does, very concisely. Best name gets immortalized in my code! And... a cyber cookie?

P.S: I'm going to stop going ridiculously overboard on the tags for my posts. They're all about computing, no need to continue labelling that.

Compartmentalization, Encapsulation, and Isolation, oh my!

I've been focusing a lot on these inheritance features today. I know, for instance, that I can create a class Planet, and that I can also create a class Moon extends Planet, so that the two are differentiated in name but don't need repetitive coding. I've been considering the pros and cons of making all of the attributes I've taken to calling low-level attributes (a planet's name, for exmaple... the things that the object stores that don't reference other objects) implement a custom interface.

Time for some explaining? I think so. In Java, a class (known as a child or a subclass) can extend another class (known as a parent or a superclass). This means that, unless an underlying method in the child overrides the parent's method (this is done simply by creating a method in the child with the same name as the parent's method), the methods defined in the parent are equally as applicable to the child. In the case of class Planet and class Moon extends Planet, as above, the method getSize() would return a number representing the planet's diameter, and would do the same for a Moon even without explicitly rewriting the code.

Now on to implementing interfaces. An interface is an abstract class, which means that it cannot be used directly. Instead, when a class implements an interface, everything written into that interface MUST be overridden by the new class. If I have attributes, to use the example above, which all have different variables within them (say, a description attribute holds text describing the object, an armor attribute holds a value representing the armor's strength), I can create an interface that defines getType() and getValue() as methods that MUST be overridden, therefore making the attributes universal in structure.

A Java class can extend only one parent lass, but can be extended by infinitely many children. A Java class can implement as many interfaces as it wishes, so long as all of the underlying methods are overridden. Because of the way these two aspects of "inheritance" work, they are known as two related but separate pathways of defining a new class. By making a new class a child of a parent class, you are inheriting behavior. That is to say, all of the 'hows' in the class are defined by the parent class, except for the occasional overriding method or additional method. By having a new class implement an interface, you are inheriting structure, because the layout of the new class must match the interface, but the specific algorithms used are specific to the new class.

There's my brief lecture on Java's inheritance. That out of the way, I haven't done coding work today, seeing as I instead attended a showing of "Willy Wonka and the Chocolate Factory" (that's right, the original) at the University. I did get a lot of (additional) thinking in and I realized one of the shortcomings in the current embodiment of the interpreter I showed yesterday. I have a button that is specialized for the window I showed you, not one I can place into just any window I place the graphic into. This also means that when I go to make a more capable "administrator" version that allows me to generate material codes on-the-fly, I'll have to completely reprogram that button.

Instead I can use some nifty features of Java's by including a specialized button subclass into the class that creates the material graphic. This subclass would be inherently tied to the material graphic that the button updates, and wouldn't require any coding except placement in the larger window.

Overall this would greatly increase the capabilities of the materials panel I've made, as well as the capabilities of any future classes I make. I consider this Compartmentalization (and I think the textbooks agree with me) because it means that any frame that uses the MatCodeInterpreter will, without extra work, be able to add the necessary buttons and fields to manipulate it.

I think tomorrow will see me working on making that a reality.