Good evening everybody.
It's been a fairly busy week for me. I've been working on three projects simultaneously: one due tomorrow, one due Wednesday (this project), and one due next week for my Korean class. It's the home stretch for these next few weeks, and once these projects get finished up, the stress level will most definitely go down!
We had discussed quite a bit about some pretty important concepts in programming: dynamic binding, abstract classes, and singletons. I had known about singletons through the practice of programming in Objective-C (iOS). Many variables within an app are designed to be only allocated once, since their resources are shared throughout the program. Such variables include the instance of the application, the user default item list, and the delegate manager. These are allocated when the application starts up, so these would best fit the definition of eager singleton variables. Since their resources are necessary when the application boots up, they need to be allocated when the program loads. It was pretty interesting to witness this in both Java and Python. Python is just a weird and unusual language for things like singletons. It's as if you can virtually do anything to it. You can replace the definition of a class with its instance. I mean, that just seems incredibly inconceivable to me, to overwrite the class with an instance of the class. Yes, it doesn't allow anyone else to create another instance of the class, but just by looking at it, it is so confusing. It makes sense when the singleton function binds a value to the callable object (which is the instance), and then spits out the lambda expression for it. It's ridiculously clever.
Abstract classes now seems to be a favorite topic for me to boggle my mind with. It pertains to another application I am writing, and many classes that are involved require the same methods to be written. Abstract classes would guarantee that these methods must be defined, which is helpful in the case that I forget to create some. Also, if I ever need to change the definition, it would immediately alert me that all of my other class methods no longer conform/define the new method. It's an incredibly useful idea to implement, which I will this coming week! I think it's a little weird to have multiple layers of abstraction: that is, have an abstract class with a child whose class is abstract, and so forth. I can understand maybe one or two layers of indirection, but not many more than that. I guess when building a giant library, this would make more sense.
We had also talked a little about dynamic binding, which was a pretty interesting topic. If the class is final, or the method is either marked final, private, or static, then static binding takes place. Definitely something useful to know. I know we discuss things per an example basis, but I think it would be interesting to see this being applied in a real-world example. It makes me wonder how much of the concepts of dynamic/static binding is really used in applications. I'm sure it's fairly often.
Just two more class days, and then project presentations. Then shortly after that, the last exam. It's insane that we've come this far!
Until next time,
Corey
No comments:
Post a Comment