Author Topic: OOP Principles  (Read 8744 times)

0 Members and 1 Guest are viewing this topic.

JRS

  • Guest
OOP Principles
« on: May 11, 2013, 02:14:40 PM »
I would like to have an open discussion about the concepts of object-oriented programming and what it means. (to you) This thread isn't specific to any language. Any reference to language or code should only be used as an example, not how it should be done. I'm battling with the concept of inheritance and when it should be done. Should a class inherit another class just with only a reference to its name? Would this be considered embedded classes? Does it make more sense to create an object of a base class and do the inheritance at the object level rather than an application class that is per-constructed from base classes?

Object
In pure OOP terms an object is an instance of a class.

Inheritance
Ability of a new class to be created, from an existing class by extending it, is called inheritance.

I view OOP the same way I view a play. A play casts actors (objects) and is driven by a script and it's director. My goal with the ScriptBasic OOP implemtation is have dual interface to objects. A GUI based application would make callbacks to methods not requiring any interaction from the programmer other than instantiating them. There will be methods a class may contain that would only be called under programmer control. (utility, customization, ...) I'm defining the property of a method to be the function address. The programmer can also call the method as a function from the script.
« Last Edit: May 11, 2013, 02:46:45 PM by JRS »

Charles Pegge

  • Guest
Re: OOP Principles
« Reply #1 on: May 14, 2013, 01:59:41 AM »
Hi John,

OOP implementations come with a lot of conceptual baggage and cumbersome syntax, which has spoilt its reputation as a useful programming paradigm.

If OOP does not greatly simplify a programming task then, in my view, it should not be applied to it.

The most important feature of OOP is to remove hunks of variables and functions out of global space and put them onto their own independent islands, (commonly known as encapsulation).

This makes program merging much simpler, minimising name conflicts.

It also allows  different classes of objects to have the same verb schema. For instance create, build, destroy, get, put, render, move, adjust, act, show, locate. This is an important aspect of  so-called polymorphism.

For example a game may need to combine 2d controls, 3d objects, database, audio, and AI. Without OOP, combining these aspects into one project poses serious congestion of global name space and serious name bloat problems.

Inheritance turns out to be of lesser importance. And forcing classes into a false taxonomy, can spoil a program's architecture.

Charles




Peter

  • Guest
Re: OOP Principles
« Reply #2 on: May 14, 2013, 03:05:40 AM »
Quote
taxonomy

For the common people:   nothing but CLASSIFICATION SCHEME.

JRS

  • Guest
Re: OOP Principles
« Reply #3 on: May 14, 2013, 08:00:36 AM »
Quote
Inheritance turns out to be of lesser importance. And forcing classes into a false taxonomy, can spoil a program's architecture.

What I'm having a hard time with is the inheritance tree. If you call a method  of an object and that object has inherited methods with the same name, my understanding is the base class method is executed first and then the inherited methods in the order they were inherited. Same goes for properties.

Is this how you understand how inheritance works?

Charles Pegge

  • Guest
Re: OOP Principles
« Reply #4 on: May 14, 2013, 08:57:12 AM »
My understanding is that the new method overrides the inherited method, and that is how I have implemented it in Oxygen. Similarly if a variable is redefined, for instance: integer V becomes float V. Then the new V will be used.

Oxygen resolves inherited class members  into a flat list (a single UDT), then scans this list in reverse order, when a class member is invoked. (This is not necessarily the best method to use in a scripted language.)

If these override are commonplace, that would indicate that the program design is flawed by trying to implement phoney inheritance.
« Last Edit: May 14, 2013, 09:13:07 AM by Charles Pegge »

Peter

  • Guest
Re: OOP Principles
« Reply #5 on: May 14, 2013, 09:32:54 AM »
This is a particulate inheritance and is nothing worth,  it can inherit or it can not.  :D
« Last Edit: May 14, 2013, 10:09:31 AM by peter »

JRS

  • Guest
Re: OOP Principles
« Reply #6 on: May 14, 2013, 09:49:58 AM »
I think I confused myself with the internal (emulation) of inheritance and the bottom line is that the last inherited method/property has precedence. I then have to assume that once you inherit a method/property with the same name, dropping the child object doesn't restore it to it's previous state and would invalidate the base object. (inheritance is a one-way street) Correct?

Charles Pegge

  • Guest
Re: OOP Principles
« Reply #7 on: May 14, 2013, 10:52:04 AM »
Yes it is a one way system, like a family tree.

A derived class does not have any effect on its parent classes, but it would pass its overrides to any child classes derived from itself.

Thinking about a real application would help: for instance an accounts system supporting different kinds of ledger for small clients, corporate clients, suppliers, cash, hedge funds, off balance-sheet, bribes etc. They would all have common elements which could be aggregated to form useful base classes.

JRS

  • Guest
Re: OOP Principles
« Reply #8 on: May 14, 2013, 11:19:35 AM »
I'm trying to build a set of agreed upon rules. This is what I have so far. Please either approve or explain the errors of my ways.

  • Objects are disposable code libraries created dynamically from class definitions.
  • Inherited objects should only extend and not reduce/break existing functionality.
  • Only base objects can be dropped/destroyed and classes have a shelf life as long as the application exists.
  • Properties should only be modified by methods and never directly. (properties are known data repositories set/read with methods)

Charles Pegge

  • Guest
Re: OOP Principles
« Reply #9 on: May 14, 2013, 03:09:53 PM »
Hi John, I've hacked your list rather ruthlessly, I think it was strongly influenced by COM, which is a highly specific form of OOP.

Here is my take:

  • Objects are created using class definitions, and generally take the form of compound-variables.
  • Classes can specify references to procedures known as methods, and variables known as properties.
  • Classes can inherit other classes and extend or modify the inherited functionality.
  • Objects and classes may have restricted scope and duration.
  • Generally, object properties are accessed by method call, not directly, so that their internal code can be altered without breaking programs that already use them.

Charles Pegge

  • Guest
Re: OOP Principles
« Reply #10 on: May 14, 2013, 03:32:23 PM »
Structural relationships:


types--->compound-types----------------
                                                                             \
                                                                              Classes
                                                                             /
variables--->expressions--->functions---

Charles Pegge

  • Guest
Re: OOP Principles
« Reply #11 on: May 15, 2013, 07:28:21 AM »
Some Possible classes:

no properties or methods

class zen
end class


properties only

class point
float x,y,z
end class


methods only

class ops
method add(sys a,b) as sys
return a+b
end method
method sub(sys a,b) as sys
return a-b
end method
end class

« Last Edit: May 15, 2013, 07:05:11 PM by Charles Pegge »

JRS

  • Guest
Re: OOP Principles
« Reply #12 on: May 15, 2013, 08:46:39 AM »
With my POOP conversion I running into what I guess is called Method Overloading. This is where a method based on it's argument count and type(s) call multiple (sub-classed) functions. SB has no problems with overloaded functions but this overloaded method idea is hard to swallow. I ran into a helpful OOP reference I thought I would share.

Introduction to Object Oriented Programming Concepts (OOP) and More


@Charles: Is your e-mail not working? I have sent you numerous e-mails and not one reply. I'm thinking your e-mail server is rejecting them when that spam e-mail was sent from my account.
« Last Edit: May 15, 2013, 10:42:05 AM by JRS »

Charles Pegge

  • Guest
Re: OOP Principles
« Reply #13 on: May 15, 2013, 06:11:42 PM »
Hi John,

Thanks. That was a very detailed and very useful article. I liked much of it, with the exception of the C code examples, the general appearance and notation of which, is always a turn off. Nonetheless the article covers a very wide field, and is a good reference just to get the OOP concepts and lingo.

One of my reasons for concentrating on graphics at this time is that it demands modularisation OOP in a very concrete way, and is a rich test model to work with.

Sorry about the email. I'm on an email abstinence course for a few days to clear my head space.  :)

Charles.
« Last Edit: May 15, 2013, 07:04:10 PM by Charles Pegge »

JRS

  • Guest
Re: OOP Principles
« Reply #14 on: May 15, 2013, 07:26:30 PM »
Quote
I'm on an email abstinence course for a few days to clear my head space.

I'm just happy you got them and there isn't some technical reason. Please have a look at them when you have some free time. I'm buried in trying to create the framework for a POOP alternative. POOP is an emulation that is very resource intensive and pushing the interpreter to limits it was never intended to support. It takes 50 MB (2 copies of the interpreter) just to bring up a customer maintenance screen with the POOP version of SAGE MAS accounting software. I'm guessing ScriptBasic will be able to do the same in under a MB.