Linked Lists

Alright, so linked lists. This little concept has had me beaten and bloody since fall term. I remember in Atkins class barely getting the linked lists assignment in on time, like 15 minutes before it was due. I think it stems from a fundamental misconception of some sort. I think when I can write it out on paper my ideas are right. But when it comes time to actually code it, it becomes something completely different. I think if I had a better time relating what I think it lookls like in UML to the diagram we use to show the linkages, I might be alittle better off.

 Anyway, I think I understand the very basic most fundamental aspect of linked lists. If I am permitted to use nulls and all that ugly crap, I think I would be able to develop a linked list from scratch. But Zach and I decided to try and use the state pattern in a linked list. The idea initally being that this would remove the need for an empty list object. By having the last element assume the lastState it would take on the value of a node that is last in line. To remove the need to reference null we tried having the node reference itself. We have run into a few awkward problems however, it seems that given the driver code collection provided with us, the first element of a list also references null. Because of this, we felt we needed a firstState, which lead to another interesting problem, what if it’s the only node? then it would be trying to figure out which state to implment. I wrote some quick “if-else” statements, theyr’e ugly but their you are. These if else’s might help the program decide what state to be in. Unfortunately, theirs alot missing I believe that has nothing to do with the state pattern in Zach and mine’s design, because both of us are still lost trying to get this under wraps.

 Concerning idea’s with other patterns. The observer pattern would be the one to use to detect broken links. Though if I understand this right, the pattern would be a little wonky, as it would have many observables to one observer. The observer looking for broken links, and any broken link sending a changed() method to call the observers update method. So it’s a backwards many to one relationship. I think it still works. Their also seems to be an issue using the java api, as you cannot extend two classes, list and observable. I think that an object reference to a delegate that extended observable, calling that delegate’s reference variable and having it use methods like add like this:

Delegate delegate

delegate.add(this);

would work fine. put that reference in the abstract and youd be good to go. Concerning the decorator pattern. If seems like it’s a list itself, just you can only really use one object, the head. You also seem to not be able to recover previous objects. I just don’t seem to really like the decorator pattern. Outside that thought I can’t think of anything particullarly useful to work with it. The visitor is fun, it allows you to traverse a list or just find a single object, and then do stuff to it. It seems like the list is swiss army knife and the visitors are the blades. You use them to do different things with the bits of metal in them knife. That’s all for now. I think I will send two chunks of final project. The Initial main project has all the patternes, they work, but I do not think they work together that elegantly. It isin’t even a simulation. The secondary project does have a few patterns, and they work very closely to each other, and is technically a simulation. I hope To show that I can implement all the needed patterns, and given enough time can use them intelligently. I couldn’t finish the secondary project compeletely due to workload from other classes. Busting out logic to make stuff interesting in the secondary project was taking several hours a piece.  

Visitor and then some

So adding the visitor pattern was very peculiar to me… It was way to easy. I threw in the visitor interface, made a visitor whom looked at HP, and wrote the appropriate methods. Then threw in some accept visitors in the visitees, and voila, done. Only issue I encountered was that the decorators were also included in the visitee arena, which is bad. The problem is that when you decorate something, you change it’s type, so visit methods were needed for all decorations, and then the next problem was that decorators are not appropriate for the HP value thing. During lecture Kent came up with the idea of “stuffers” instead of “wrappers”, and since it sounds like doing this we would keep the objects being decorated their original type, this might work for my HP issue. Haven’t tried implementing it yet, but will soon. ALso, trying to comprehend the factory pattern, the book loves it, andit’s big. Will eventually stuff that monster into my code, but it will take some time. Feed back would be great. I have a question concerning the factory. I want to have invisible spawn points in my game, where monsters after a given interval of time and certain conditions met will spawn, as an independent monster with it’s own values. Is the factory pattern what I need? unfortunately I am kinda going off it’s name and trusting it does what it sounds like it does. Also, if we could have a closer look at that stuff idea, life would be great.

(not-so-mini) mini project.

Sorry about the late post, I forgot about this bit whilst working on the wee project. Speaking of which, is still in the works, I don’t know for sure where my problem is, but I am willing to bet it has something to do with the State pattern, cause I ahve yet to successfully implement it in either my big or little project. I continue to get null pointer exceptions.

The process was rather straight forward for me in the beginning. I started how I always start a program, I wrote it out in simplified UML. I was able to get 75% of the work done this way, as implementing  the Strat,Observer, and Decorator patterns are rather straight forward once you know what to do. My original mini project had about 23 classes, and this was due mainly to a couple factors:

1) I thought it was a good idea to show the patterns work on several different classes

2)My version of small is apparentally big, which as a student is reassuring

3)this thing I thought was kinda clever required alot of state’s to really show it’s inner beauty, problem is, I ain’t as clever as I thought, I still can’t make the state pattern work for some reason, and the idea happened halfway through the process, so I didn’t write it down and fit it in, I just tried hacking it in, which never seems to work for me.

The State,Observer, and Decorator pattern all function just fine in my program, but the state continues to elude me, and the frustrating part is I am not at all sure how, because it looks like it should all work fine (of course if something looked wrong I would have fixed it, so the previous point is kinda moot) Mainly, it’s null pointer exceptions, and I think I understand now that what I am having an issue with is the fact that I don’t exactly know what a state is, and thus am probably not initializing them correctly. I am going to seek help tomorrow, because I am getting really desparate here, cause I can’t afford to fall behind.

Outside writing it out, The creation went something like this. I don’t know if this is the easiest approach, but this is how I’ve always done my programming (which isn’t saying much, I haven’t got a ton of programming xp under my belt) but after getting the UML figured out, I generally know what classes I need to create, and how to connect them, so that was my next step. I created the Strat first, laying out the base class, sub classes, Behavior interface, and behavior implementers, and then created the reference variable inside the base class. Next, I worked with the observer pattern, which was much nicer this time around since I used Java API, it was actually extremely simple, and I think I am going to go ahead and try and remove my interface style observer pattern from my main project and reimplement the API version. Finally, I went ahead and made the Decorator pattern, which was not difficult at all. Once it was in place I got to thinking. It’s kinda lame that the decorations have to be hard coded in the driver, and you can’t dynamically create wrappers. So my first idea that didn’t work was to make a method that took in a subject to be wrapped and a wrapper. Then wrote out an algorithm that would return a wrapped object. It went kind like

public void Decorate(Object toBeWrapped, DecObject     Wrapper){

toBeWrapped = new Wrapper(toBeWrapped);

}

but it didn’t work cause of something with the Wrapper. So I thought, “well, lets have the decorations depend on the state then” And I was going to have wrappers change with the state. Which once I had created the states, I realized that I would need alot of references for each one. So, I created a parent class taht would hold the reference variables, and the states would exend this class. I thought it was nifty. Then I would write a method Progression()  that was specific to each state, and as each state passed it would wrap the different characters in different decorations. But I ended up getting an infinte loop of null pointers, then just a straight up null pointer, then kevin telling me to knock it off and just implement the patters. Which I did, cept for the state, which I need help on, cause I am lost.

Recipe for State.

1)write it out, figure out how the classes will interact, what your states will be, and what actions will create the transintions.

2) Create the interface with the State methods

3) follow this with the classes that represent the different states and implement the state interface, override methods where necessary

4) create the necesarry reference variables in the constructor of the subject of this pattern, the one whose state is going to be changing.

5)using these reference variables, you can now implement the given methods in your subject, but use the state reference variable to execute the methods, so that when it is executed, the output will be appropriate to whatever state the object is in.

6) I think this may have already been done somewhere along the way, but just in case, be sure you set up the code representing the actions that will create the shift changes. These will probably already be inside the overridden methods within your state interface implementers.

State Pattern

Alright, concerning the state pattern I thought I had a good understanding, but it’s turning out their are obviously bits I missed. Amazingly, I found bits in the book that were noticably ambiguous when it came to interpretation. I understand that essentially the State pattern is a suped up Strat pattern, at least in my eyes. it feels like we’re not just removing behaviors that change, but whole states of mind. So it does feel just like we’re taking out a bigger piece of change and managing it.   We manage it very intelligently, using the different states of mind as classes whom implement an interface that holds all the methods that each state has in common, but depending on the state, those methods act differently.  Now, I personally rather like this, it really does seem to allow radical changes to happen without alot of rigid logic. Because we are making the different states do all the work, it is relatively easy to add and expand to this program. I kinda wish we would have had an example of bad code alot earlier, because the example they give with all the conditionals really helped me understand just what we were saving ourselves from. I am having a difficulty though, and this concerns that ambiguity I was talking about. Working with a project like ours, it seems that we need to be well aware what each constructor is going to end up passing in. my Bear at the moment takes in one argument of type human I think. Now I thought that implementing the required bits for the State pattern in the abstract animal would be a good idea, because they would then all have the necesarry code without alot of recoding, and would all have the ability to use. I ran into a problem though when I I tried to put the necesarry int in the constructor of the abstract, and I had to do the same for it’s subclasses. Bear and Wolf both have arguments from previous patterns inside their constructors, and it seems that they don’t want to play nice with this new int “moral” I need to put inside it. Outside this little difficulty, I think Im doing fine.

Recipe Decorator

1) write it out

2) create abstract class to be decorated and abstract decorator class

3) in constructors of toBe decorated objects include descriptions and such

4) add whatever other methods your toBe decorated objects may require

5) in decorator subclass’s, create reference to toBe decorated objects superclass, and reference in constructor

6) apply description methods and other such things, remember to essentially extend them by calling the original and adding on to them.

7) in driver code, create object reference variable to whatever subclass of toBe decorated objects you want, but make it the type of the toBe decorated objects superclass (one step up the hierarchy)

8) create the appropriate methods and SOP to exress output,then go ahead and create new objects and call each appropriate decorator, with the new object that is being created as an input in the constructor.

9) hit run;

Decorator Pattern (rather fun)

my experiences with the decorator pattern have been much much more enjoyable. Playing the games I do I find the concept of character growth extremely enjoyable, and learning how to essentially add layers to objects, giving them unique traits and abilities, has been very amusing. Also, conceptually, I think the Decorator pattern is alot nicer than the observer, and it shows not only in diagrams but in the code itself. I am really getting a firm grasp of object references, and a large part is thanks to working with this pattern. It took me less than a couple hours to already have a rough implementation of it. Essentially, the first thing I had in mind, something that could affect objects interactions, was the idea of different objects conditions. From an animals perspective, a creature whom is visibly wounded is much more interesting looking than one whom is perfectly healthy, and thus much more likely to risk attacking and eating the injured creature. If a human NPC survivor meets another survivor, the initial interaction will be much more positive than if one of them was obviously diseased. So my first decorator pattern initially delt with what I call conditionals, things that affect an objects condition. They would print out a brief description, then would adjust a characters aggression and disposition levels (right now just towards animals). The next step I am going to add is Specialists. these are educated and/ or skilled individuals that survived whatever catastrophe took place, and have unique skills not available in the common survivor, such as a doctor to help with the visibly wounded trait, or an engineer to build stronger shelters or build them faster, or a militant, whom knows how to use bigger and meaner weapons to help stave off the terrors of the post-apocalyptic planet.

The actual design process has been rather straight forward, and I have not had any real hang ups, just mainly myself trying to differentiate the decorators and the objects they decorate.

implementing the Observer Pattern (way more tedious than it had to be, thanks to me)

hello everybody! I have almost finished the damn code by now!!!! I decided that making it REAL weird would be the best way to squeeze all the fun out of it with my white knuckled fist, and then throw it aside to cry itself to sleep on some cold wet rock.

ANYWAY, here’s how the process went for me. I first off wrote the extension of my code concerning the Observer Pattern down on paper, this included what I had already constructed with the strat pattern. This was no problem, I believe it was a good comprehensible diagram, the only ambiguous bits were more game affiliated than pattern affiliated. The interfaces were easy to understand and the over all idea was pretty rock solid in my head.

Second, I began working, and it went smoothly laying out the foundation of the code, I had decided to NOT use the Java API observer thing because of the limitations it may present with needing to extend the subject (I think it’s the subject, I’ll have to look that up). I felt that while perhaps their may be a slightly smaller bit of work involved, I would be better for it later when I realized the whole hierarchy of what I am doing is compromised because I decided to extend the subject instead of implement it(so avoiding this hypothetical mishap). Now, coding the stucture worked, but once I came upon the ambiguous bits of my code, and also realized I had payed way to much attention to the interfaces and not enough to the other specifics, I began to run into problems. Namely, I was really worried about not knowing how to differentiate my two observers (wolf and bear) because at the moment my code affects both objects data fields when setSituation() is called. That is big problem number one. My second big worry that I hope to have resolved soon is that I am not sure what is a second application of the observer pattern. Does this mean I need two subjects? Or does it mean that I need them to react to a completely different setSituation() method that apply’s to something totally different in my game? answering these questions is what has taken up most of my time.

In my journey to try and somehow remedy my two issues, I tried several different approaches. Concerning number one, trying to differentiate wolf and bear so that setSituation() would only affect one or the other or both, depending on how I choose to do it, I created a method called getStats(). Now ultimately I abandoned the idea because I realized that I was really going to go nowhere without a little guidance. The getStats was intended to retrieve a specific object(such as wolf) and its related attributes. I had hoped that I could use this somehow in combination with setSituation so that it would only apply to either wolf or bear. Initially i had getStats() looking like this:

getStats(Subject s, int hp…) where the subject would be whatever object I needed retrieving, but ultimately, I was not able to logic it out, so I scrapped it. That’s my first big question, how do I differentiate two different observers that share the same set method and same  Subject?

Second issue,  the second application of the observer pattern. I had planned on working this out by having an out of combat observer pattern. Now technically, this will either initiate combat, scare away an object, or gain an object as an ally, and is a way to build interactions between objects and resolve their future relationship. So upon realizing I had no idea how to differentiate update() methods, I decided to go ahead and make two observer interfaces (<—bad idea) each with it’s own specific update method. this way, things that you couldn’t be diplomatic with but could still do you harm (like napalm) would only implement CombatObserver, while things that can both fight and chat will implement both interfaces and both methods. I ran in circles a good deal here trying ot get them to work, ultimately realizing “now how do I make two different update()s print out on one display()?” answer, I couldn’t figure it out. So I crunched down the interfaces to one, renamed it observer, deleted the second subject interface I had made while running nowhere, and renamed CombatDATA to gameDATA, and deleted the other observer. The update method now takes in five different ints, and the display now works for both wolf and bear, and I intend to make a display that reacts to the differing values much more interestingly. At the moment however, it merely reads off whether something is being wounded.  So the second question is, what would I do for the second implementation of the observer method? Thanks.

Observer Recipe

1) Again, write out your logic so you don’t cry yourself to sleep cause your playing by ear manages to melt your computer and little mice run out with forks and stab your toes.

2) Since I assume that by writing out your logic you know where the pattern is most applicable, we can begin developing the code.  I first wrote the two interfaces Observer and Subject. I am not using Java API observable and such. Give Observer the appropriate methods and same with subject. These should be: Observer :Update(), Subject: NotifyObserver(); RegisterObserver(); and RemoveObserver();

3) okay, a little work in the main, create a variable that references your subject.

4)Now, let’s work with the subject, their some interesting goodies we need to throw in here. The subject you intend to use will of course need to implement the Subject interface we made earlier and thus it’s methods. Fill out the Overloaded method logic for each one. Im sure you know how to do that . Also, we need to create the parameters that set a change and notify the observers. Write out the situationChanged() method, and inside it implement notifyObserver(); the other method to create is setSituation() Which will take in whatever data fields are involved with the observation and set them to be the values with many “this dots” .

5) alright, lets work with our observer(s). first implement the observer interface and add all the necessary methods (namely update();).

6) in your observers constructor, go ahead and use it to register the observer as an observer with constuctor by passing it the Subject object. Use the  Subject.registerObserver(this); code line to do this.

7) fill out the update method, using the applicabel data fields, and follow that good stuff with a display() method to show off your work. Of course, you need to write the display method first though.

8) alright, back to main, remember that object reference you made? well now lets put it to use.  Create new instances of your observers, and pass them the Subject object.

9) finally, we’re going to pass some changing data values, and we’ll hard code these for now, but later when we can afford measuring devices or some such thing we’ll use them. implement a few setSituation() methods, with your data fields in thier, and when you run, your display() method should show the results of your hard work. Well DONE.

Recipe for success

1) write out your code on paper.

 2)Create your superclass’s and your subclasses, and figure out what’s special about each subclass. 

3)figure out what varies, and apply them to an interface, creating classes for each different variation that will implement the interface.

4) Create the necessary methods, remembering the empty body abstract methods in the superclass,  and the variable methods that will be overridden in the interfaces implementers.   

5) Create reference variables in your superclass

6) allow your reference variables to allow you to delegate method calls to the behavior (your interface classes) thus your actuall subclasses do very little work.

7) if necesarry, you can create set methods, which will take in a new behavior and reference to a new class. This allows you to set behaviors and changes in general dynamically as new subclasses are thought up and set up.

8) put it all together, and voila, you have a program that is organized to allow expansion and all around change.

6)