So you're basically saying that if it can't be re-used it should never be in an object
Readme: If your going to comment, make sure you read the *whole*
Well...yes...to a degree, it should be your number one goal during object analsys and discovery...as objects are intended to promote code reuse to a level greater than functions alone.
OOP was designed to assist or make more clear, software development problems/solutions...and problem solving is all about taking a problem and breaking it into smaller more manageable problems and solving each of those in a recursive/iterative manner until problems cannot be broken down any more...ie: your problem becomes atomic.
As you break problems into smaller problems, you can begin to discover some form of heirarchy where one monolithic problem broken into 2 logical sub-problems are combined to solve the previous problem, this is where multiple inheritence comes in handy. Usually however you can solve one monolithic problem by incrementally breaking it into single solutions and use linear inheritence to solve the problem.
This is what is often refered to object discovery and analsys...something many articles and books ignore to explain - depending on the language!!!
Take a problem, break it into a smaller problem which solves a more primitive subset of it's child.
Object discovery usually works top-down, not visa versa...which most OOP articles let you believe, which is a clear indication of a newbie at OOP writting the article - thus the reason I don't read articles when I want to *learn* something but instead I read a book, I use articles to familiarize myself with a topic and if interested I find a high quality book.
Most articles on the subject right away begin disscussing the syntax, and go into inheritence without disscussing how and why object discovery is important first!!!
They detail the basics of OOP, explain encapsulation, etc but don't really explain it's purpose, just that it's handy and immediately developers see some advantages (depending on your experience level of course) and begin using it all over the place - too much of a good thing can be bad.
For obvious reasons, OOP cannot be properly explained in an article, you can exemplify the general idea, but you will likely skip out on alot of details, ie: object discovery and what OOP is *really* about.
I have read at least 10 books on OOP and have spent years(almost 10) considering how and why OOP does what it does and how it is fundametally better at solving problems than procedural programming.
the fact that so many people are ignorant to the idea of object discovery, demonstartes how a little bit of knowledge can actually be a bad thing. I shouldn't say a bad thing, cuz if you use classes over procedural, despite not understanding it, who cares, it's not *really* going to negatively effect your program, except for failing to following OOP principles properly...but we all seem to be advocates of good design and strict confirmance to rules, so perhaps it's important...
The point I am trying to make, is that you are correct in saying OOP goes waaaaay beyond reuse...
it's not just for pragmatic use, but fundametally for solving problems...
If OOP is indeed intended to solve problems more effectively and in a more natural way than procedural programming, then reuse should be prioritized -
as that solves the problem of solving problems...
I agree that reuse should not be your only requirement when using OOP, but let me make one thing clear - which many OOP
enthusiasts fail to realize...
The title
Object Oriented Programming...suggests the idea of object is of upmost concern when following it's principles...
An object is a person, place or thing, each of which are composed of communication channels (methods) and properties.
Consider a real world object: You and your friend are holding hands or having a conversation (interfacing with each other) if your heart stops and you die, the interface or communication channel stops, but it doesn't *really* affect your friends life (outside of emotions). This is because you are not bound by implementation, but rather by contract or interface.
In practice, it's best to keep your objects as objects...which are separate entities capable of existing without support from the outside world...(ie: database, etc) any bindings or dependancies should be left to interface not implementation. Thus reuse is born!!!
A database class (NOT an DB abstraction class) is poor use of OOP and indicates naivety...
The object, regardless of the abstraction layer used, is now forever bound to that medium and is therefore not reusable.
Code: Select all
class CxUser{
function list()
{
$adodb->Execute('SELECT * FROM table_users');
}
}
That is not OOP, as it is not an object in the purest sense of the word. It is a wrapper around traditional procedures...if the database chokes, the object is no good...if you want to change from database to remote storage, you can't without touching the imlementation...and so on.
If your after a library and simply want to prevent namespace collisions, calling these functions statically...cool...thats a good idea (PHP doesn't yet support namespaces, so we can use this as an adhoc solution), but if you instantiate it as an object and pass it around as an object...
Thats your choice...waste of clock cycles if you ask me...but your choice (as in anyone, not yours alone)
However if you (as in anyone) write code like this and tout it as an OOP solution, then I have problems...because then you disambiguate the term *object oriented programming* and confuse newbies and assist in the proliferation of poorly written OO code.
Lastly I will define what an *object* is because people seem to fail to realize this, judging by the number of times I've been in this disscussion on various forums
An object, is a separate entity capable of existing entirely on it's own, with no internal dependancy on the outside world (re-use) other than that of interface communication...
Look at real world objects, which OOP is emulating...
A caliper is designed to work with rotors, etc...
if a caliper breaks internally, it's replaced easily and everything is cool. But the caliper DOES NOT rely internally (implementation) on the rotor, only through contract or interface...
So to recap, yes, I am saying if an object doesn't allow reuse, then you might as well write it as a procedure or at least as a static method, making clear it's NOT an object your dealing with.
However, at the same time, to use the above
CxUser as an example...
It might make sense to have such an object, despite the loss of reusability, but this isn't so much as object as it is an abstract data type (ADT). As CxUser would be a new intelligent "type" much like Integer, Double, String, etc...
Here's the kicker, for PHP developers...
ADT's are not likely ever derived from, how many things can you make from an Integer? You couldn't exactly make a super integer, because the "type" that object is bound to is fixed - it's an integer!!! I suppose you could make a double integer or even an array (string) of 4 byte integers for some new language which has that many characters...but still...
It's medium is fixed as well, it's 4 bytes(arch. depending) of RAM, much like a CxUser ADT is likely bound to to a SQL database - it's medium is slightly more flexible than that of an plain Integer, but the idea is the same.
A single Integer:
00 00 00 AA
A single CxUser:
fname lname age income addres phone1 phone2
Heres where I have problems with ADT's in web development:
An ADT represents a single "unit" but how often do people have listing functions in there as well?
Code: Select all
class CxUser{
function create(){}
function update(){}
function delete(){}
function list(){} // Listing function
}
The other caveat of ADT's is they are not normally used as an 'object' is...
You don't typically initialize an ADT, play with modifiers/accessors, etc...
And unlike Integer types which can be used millions of times in any given section of code, an ADT is likely only going to have it's
create() called once during any given session, etc...
So PHP has parsed an object to execute
one function???
In a compiled environment this wouldn't be bad, but on a web platform, it's wasteful...
You'd be better off forgoing the pleasure of working with OOP in favour of a function library, optimally chopped into individual modules, so only functions needed get parsed.
So again, to recap (for the second time I know

)
When you can't reuse an object, it's likely a good idea to not bother using OOP as it's NOT an object...cuz object implies reusability...
Although technically an ADT is implemented as a class object, fundametally an object and ADT are quite different. One is an
object and another a
type.
An object and ADT support reuse, but depending on the ambiguous nature of your ADT in question, a ADT may only be usable from with your application.
STL is an example of an ADT library...those are generic container classes or ADT's and although reusable, they don't apply to every applications needs.
The above CxUser example as an ADT also makes me choke, because the nature of database schemas are quite dynamic, your ADT will likely loose it's reusability quickly.
O/RM frameworks seem to really solve this problem nicely - at least the one I'm working on does.
This topic really gets me fired up and I could go on forever, but for the sake of brevity (just kidding) I think I'll stop here...
If anyone argues, I'll continue further...
p.s-I am saying object reuse is important and objects shouldn't be used unless their is the possibility of reuse, but also note my exceptions to the rule, in the case of an ADT and your specific circumstances...and why when using PHP it's sometimes better to modularize your code instead of componentize.
Cheers
