With the way that the University of Phoenix organizes their classes I find myself having finals week a lot more than most students. Instead of semesters we have "blocks" of classes, two classes at a time, each class is 9 weeks long. But they stagger the classes in a block so class A starts one week and class B starts the following week. Next week is finals week for one of my current classes and the following week after that is finals week for my other class and then I start the next block the week after that. I, personally, really like this format because it keeps the classes short and sweet so that I can engage in a varying curriculum without being bogged down by taking 4 or 5 classes at a time but I have to admit that it can be kind of stressful to have two finals weeks in a row every 9 weeks.
My two classes are IT 210: Programming with algorithms and logic and IT 236: Beginning web design. I am enjoying both classes and, so far, pulling an A in each as well. After these finals I have only two more blocks to go before graduation. Weeeeeeee.
Food:
160 oz of water
1 cup of coffee w/creamer
1 tbsp peanut butter
1 healthy choice lunch
1 - 100 calorie snack pack
1 Fish burrito
1 veggie wrap
---------------------------------
Daily Caloric Intake: 1,231
Activity:
Jumping Jacks: 100
Stairs: 5.5 flights
Hard Labor: 3.5 hours helping Snackers clean carpets, tile, and rugs at a big commercial job he had tonight. FUN STUFF, details tomorrow!
Yeah well imagine being the guy who had 4 or 5 finals in a single week every 12 weeks!
ReplyDeleteEven worse, imagine having 2 finals one day and 2 finals the next.
Or even worse, 4 finals in a single day -- 2 of which overlap each other! (never happened to me, but I saw other students in that position). YIKES!
I'm excited that you are getting into programming finally! NICE! :) I assume your web design class is going over HTML/CSS/Javascript but language are you learning in your algorithms class?
Oh no, I'm grateful for the way UofP sets up their classes!!!
ReplyDeleteThe beginning web design class is only covering HTML and CSS.
Programming with algorithms and logic is actually strictly pseudocode. It's designed to teach the basic fundamental principles of programming in general but doesn't focus on any specific language. It's kinda lame but a lot of the people in my class are having a really hard time with it so I guess it has a purpose. If these people can't handle a pseudocode class they'll never make it through an actual language. We spent the first 6 weeks of the class learning the basic principles of structured programming and code etiquette. In weeks 7 and 8 we touched briefly on object oriented programming (what you were trying to teach me in our java emails) and, I admit, I still struggle with a tendency to over-define classes. Like the "Dog" class we were working on. Sub classes are head, body, legs, tail. But then those have sub classes of eyes, ears, nose, mouth, neck. Then those have sub classes of tongue, and teeth. It seems like I tend to want to break everything down into such miniscule sub classes that I start to confused about what constitutes a subclass versus and attribute. BUT, I got a 100% on my OOP pseudocode for the basic functions of a microwave so I guess I have a reasonable grasp on it.
Ah, the good old OOP conundrums! Hehe. You are experiencing one of the problems us developers deal with every. single. day.
ReplyDeleteThe good news: there's no fundamentally wrong answer (provided you stay within certain basic lines)
The bad news: there's no totally right answer either
For example: pure OOP states that your object should encapsulate it's own behavior. Users of that object should never dictate to an object *HOW* to do something, they should merely tell it *WHAT* to do. ie: "wag your tail" as opposed to "swing your tail back and forth from side to side at a rate of 1 swing per second in a 30-degree arc". You always do it the first way, never the second. In other words, you always tell the dog to "come here" -- but you never tell the dog exactly HOW to do that... that's up to the dog to determine. That's pure OOP. However, in current practice, it's *extremely* common to see coders violating that; in fact, in some languages and frameworks (most Java web apps, in fact) it's a de-facto standard to write your objects to encapsulate attributes but not behavior and to instead write a "controller"-object that determines the *HOW* and then simply tells your "value"-object what result-value to store.
It's sort of maddening.
So just realize that, for now, you are learning VeryGoodAndUsefulTHEORY -- fantastic stuff to understand in-depth and debate it for years on-end in your professional life; but, in actual working code, you may not ever use it correctly.
:)
As for what constitutes an attribute vs. an object... the answer is: it depends.
ReplyDeleteYeah, I know, not very deterministic/scientific, huh? Yeah, well, it is what it is. One of the interesting things to realize about Computer Science, something I didn't realize until after I'd graduated, is that (despite the term 'science' in it's name) this field is also sort of an art-form (in that it's constantly evolving, varies from one engineer to the next, and has no absolutely set and defined standards). That fact is supported by the college that most universities place it: The School of Applied Science. I don't know where UofP places it, but in both my 2yr and 4yr schools it was in the College of Applied Science -- NOT the College of Science.
That's because in the College of Science you deal mostly with memorizing facts and regurgitating answers. But not so in the applied sciences; in our world you learn a whole lot of nice theory that, in theory, is built on a solid foundation but, in practice, is anything but solid.
So the answer to your question is: it depends on which programmer you ask and on what day of the week you ask them. One possible answer that you'll commonly hear is: it depends on the PURPOSE of your design. For example, a Mouth could be an object with a property called numberOfTeeth which is just a simple integer. And, for the purposes of your design, maybe that's all you'll ever need to know about the teeth: how many that dog has. Maybe your design is to provide a website where people can learn the differences of one breed from another. Maybe the number of teeth from one breed varies from another (I don't know if that's true or not, but let's say that it is). If so, that would be good info to know for that sort of website. But you probably wouldn't care about factors of individual teeth because you are looking at a dog from the perspective of an entire group, not individual dogs. So, given the fact that all dogs have mouths that have a different number of teeth it then makes sense that the Mouth is an object which has a property to keep track of number of teeth; thus, no Tooth object is necessary because you have no intention of tracking details about any individual teeth.
However, if you were designing a program for a veterinarian, the answer changes dramatically. In that case you almost certainly would want a Tooth object because you'd want a way to track individual variations from one tooth to the next; such as: decay, repairs made, cleanliness, etc.
ReplyDeleteSee how that works?
There is an acronym in our industry that is called "YAGNI". It means: "You Ain't Gonna Need It". It's along the lines of entire design philosophies which, at their core, teach to keep the design to the absolute simplest needed in order to achieve your goals; don't build complexity in until you actually need the complexity. So, with a vet program, you know you are almost certainly going to need a Tooth object -- so you go ahead and write it. But, with the breed program, you can't foresee (in any significant likelihood) any real reason to have a Tooth class because you aren't planning on tracking anything about individual teeth. So DON'T WASTE YOUR TIME writing a tooth class; it just doesn't earn you anything (at this point). Sure, you could probably imagine some use-case far in the future where *MAYBE* you'll want to track individual teeth properties... but leave that problem where it currently is: in the future realm of distant maybes. Why? One reason: "You (probably) Ain't Gonna Need It".
YAGNI. Learn it. Live it. Love it.
Because, honestly, if you design your app with the right amount of abstraction and separation of concerns, adding that Tooth class later will be really easy. But, if it turns out you never needed it, the constant pain of having to deal with a whole extra object is going to prove a huge mental burden -- and literally waste hours of a developer's time maintaining it and navigating around it.
YAGNI.
Look it up on Wikipedia. Consider writing a paper on it if the opportunity presents itself. It, and other concepts related to it, is (IMO) one of the best philosophies to learn in our profession.
YAGNI.
If you aren't feeling me pushing this into your brain, well, you must be sedated.
YAGNI.
:)
Actually YAGNI made perfect sense the very first time that I read it. THAT is the answer I wish my instructor had given me because she just confused me so I gave up and though "If I'm writing a program where a little dog runs around on the screen and barks, do I really even need to worry about teeth and retina's? Probably not" and ... here you are confirming that for me.
ReplyDeleteI ended up doing the same thing with my microwave pseudocode. So my microwave has multiple cooking levels and it has a defrost feature etc. but I never use them so I opted to leave them out of my pseudocode and focus on the primary functions of cooking, timers, buttons, and displays. I did, however, end up including the door latch and plug since, without them the other feature would cease to work. But I YAGNI'd the rest of the fancy shmancy stuff it does.
Haha... awesome to read this! I got into a moderately-heated twitter-argument with programming-buddy -- he totally thought I was wrong for having taught you YAGNI at such an early stage.
ReplyDeleteI disagreed, of course.
I remember what it was like early on thinking "how will you ever finish a program if it always has to be so complex and perfect!?!??!" It confused and frustrated me.
Then I discovered YAGNI.
He argues that teaching it to you so early will make you lazy.
I say you'll be lazy whether you know YAGNI or not. Instead, it will help you realize you should focus on what's important *RIGHT NOW* instead of focusing on crap you may or may not use at some future point -- and that will free your mind (and time!) up to accomplish the task at hand.
Hopefully you'll use that extra time to develop a really elegant design that will be easy to modify later on rather than use it to read the news (personal criticism!)
:)