objects and web scripting

scripting typically involves creating objects in order to execute certain tasks to achieve a desired outcome. and so … how do i create an object? it sounds silly, really. but, honest … its abstract … a tough concept around which to wrap one’s head. its the core of modern-day programming, though. so i had better start getting it.

object creation involves 2 steps.

(1). create an object definition ~ the code containing methods and properties of the object. methods ~ directions for making the object. properties ~ characteristics that typify the object.

create a constructor function ~ a named group of 1 or more programming statements that can create new objects. note – by convention, capitalize the first letter of a constructor function.

add properties ~ identified by object name “dot” property name. refer to the newly created, not yet instantiated objects as “this”

objectName.propertyName = value

add methods ~ (methods = functions called from within the method.) name the method, assign a function. use action words when naming methods.  identified using the syntax below. (argument = input to subroutine … used to assign a value to a property of the new object)

objectName.methodName(arguement)

(2) instantiation ~ create an  instance of the newly defined object. specify a unique name for the new object. assign the object to the recently created object definition using the “new” keyword.

steps in object instantion ~ variable assigned a value ~ variable value passed as a parameter (parameters act as local copies of the argument) to the new object ~ parameter used to assign variable value to an object property ~ object property used by the object’s show method ~ show calls the object’s display method, which writs to the browser.

the design stage never ends

not really. in a way. i mean, don’t we forge ahead with a view to how we could enhance or improve any little thing along the way? the art of design lies in working out for oneself the details that one requires in order to begin a project. i mean, some details, once worked out and implemented, we cannot change. and so, we should consider carefully.

its sort of an iterative process. its sort of a process that involves all phases engaged in the brain at once. it cannot distill itself into phase components. not in my brain, anyhow. it all just ferments in there all at once. iteratively.

whew. well, it looks like i have just about survived another quarter of this programming/web development course of study. now its onto the fun stuff. yeehaw! now i think i wanna slow down. and enjoy the ride. more about the project for my next post.

so, what about the design phase?

do we need it? i mean, does anyone seriously sit down and spend hours creating all those wacky scenario diagrams, flow charts, and shit? ok. i wonder. coz, on one hand, i think its a load of BS. and on the other hand, i think the genius of any program lies in its design. how many times have you gotten to the tail end of coding your programme, and arrived at some glitch. a glitch you could have caught earlier in the process, had you only just attended to, followed through with and contemplated your programme’s design more thoroughly?

and ask yourself. does a house builder go out and get all the construction equipment as soon as he decides he’s building a house? what about a blue print? some sort of building plan? electrical? plumbing? it would seem an expensive and wasteful activity to approach house building in such a way. yet … so many of us approach program design that way. i wonder why?

and i wonder. why do we think we have to fit our design ideas into some pre-fab diagram? what if my neural pathways don’t produce cognitive output that fits neatly into those uml charts and diagrams? what if … my brain conceives a programming situation differently? its still design right? even if its not some pretty, prefab chart, like they show in the textbooks?

object-oriented programming: a primer

a programming language model, object oriented programming focusses on “objects” rather than “actions” and data rather than logic. historically, programming has centred itself around a procedural focus: viewing a program as logical procedure that takes input data, processes it, and produces output data. and, then, viewing the programming challenge writing the logic, as opposed to defining the data.

object-oriented programming turns things on their side by turniing the emphasis of software and software programing from intense focus on logical procedures to intense focus on the programming objects we wish to manipulate with said logical procedures. so, programmers speak of attributes, methods and triggers, where previously they spoke of input/output and procedural logic.

for programmer, objects, their states, actions and the events (the word ‘trigger’ pops up here) that affects these states and actions become the focus of design and development. the notions of state and action seem intuitive enough that i will omit explaining them. however … what do we mean by “event” …. ?

the term “event(s)” specifically refers to events that affect system function, as opposed to those that describe a transaction that’s part of system function – i.e. ‘customer wanting to buy the merchandise’ describes the event, and not ‘customer provides his credit card’ — (its part of the purchase transaction, triggering by the initial purchase request). programmers work with temporal, state and external events.