What is the name of having code structured with methods attached to objects?
For example:
" ... ".trim
or
obj.method()
At first many would argue this is Object oriented, but php is Object Oriented(well partially), yet it syntax is completely different trim(" ... ").
TL;DR "Object Oriented" and "Everything is an Object" aren't valid answers unlesss......
People constantly suggest PHP is "Object Oriented" and libraries are "Object Oriented", yet PHP library's code is often structured with tons of static classes.
For example RedBean:
R::dispense($bean)
R::store($bean)
R::trash($bean)
That doesn't follow the obj.method syntax, yet is supposedly Object Oriented. Is PHP's object orientation misleading, or is there a better name for obj.method() coding style.
PHP can do both. You can write object oriented code, and you can write procedural code.
Procedural code is much easier to understand and write, and most PHP programmers don't really understand OOP, so they write, what I call, procedural code disguised as OOP.
This includes things like static methods, and singletons.
Much of the core functions of PHP is C heritage, so don't get surprised if it doesn't follow OOP conventions.
The important thing is that calling methods on objects does follow OOP conventions.
Strings in PHP are not considered to be objects but scalar values. Therefore the syntax "..."->trim() cannot work unless the scalar string literal is converted to object first.
There is an open proposal for auto-boxing (auto-converting of a scalar value to object). This would allow the usual object oriented syntax. Auto-boxing, however does have a little performance penalty. See more here:
https://wiki.php.net/rfc/autoboxing
In the case of RedBeanPHP I use static methods for the facade. This is more user friendly than purist OO code. You don't have to know about all the internals of RedBeanPHP in order to use it (there is also an OO way to use the lib). In my opinion RedBeanPHP is really object oriented; behind the facade it uses inheritance, interfaces, polymorphism and patterns like adapters, factories, observers.
Also, I believe OOP is more like a way of thinking than just a syntax thing. For instance you can just as well craft object oriented systems using structs and function pointers or like GTK does. OOP features in languages are just to facilitate. Also, because PHP is a dynamic language (in contrast to static typed) it does not have to rely on types, it can just scan objects for desired behaviours. In my opinion this is a good thing because it is more flexible and more maintainable the deep class hierarchies like in Java. I used to be an OO purist but I have recently embraced OOP-pragmatism; just use the best of both worlds.
I have been reading around the definition of OOP and couldn't get why PHP is considered object oriented.
Can this have anything to do that the "basic level" of PHP isn't and more advanced features are?
OO features were added to PHP in stages through versions 3-5, after much of the standard library had already been created and the language was already established. Background
For this reason the standard library is not object-oriented and so everyday PHP scripts need not use any OO-style features at all. Although PHP by now has most of the standard features of an object-oriented language, many authors don't use them.
Library functions added to the language later continued to use functional style for consistency, though many extension modules do use objects.
Almost any language that allows you to create and instantiate classes can be considered object oriented.
PHP has these capabilities, but doesn't really stretch them. You can use OOP to help your code, but it isn't required. Java and C# barely allow you to write non-OO code, as everything must be in a class.
Can this have anything to do that the "basic level" of PHP isn´t and more advanced features are?
You could say that about just about any OO language. The general definition of OO code is where you create classes and instantiate them in your code, calling methods on them from other classes. Nothing stops you from using only static methods or one super class with a 'run' method that only calls other methods inside the class, both of which would definitely NOT be object oriented. As far as I know, there aren't any languages that say "You must create classes and instantiate them or you will be banished!" (I haven't looked into Smalltalk though).
Beginners often learn the basics while putting all their code in just one method that gets called at the stat of the program. Once they get to more 'advanced' features like methods and classes, they are offered other options.
There is already a sufficient (and accepted) answer here, but I thought I'd throw another log on the fire for clarity's sake.
The "class" keyword (and the enforcement of its ubiquity, as in Java) does not Object-Oriented Programming make. As CrazyJungleDrummer pointed out, it is perfectly feasible (and all too common) to write entirely procedural code in something like Java; the fact that the code lies between curly braces in a class called HelloWorld doesn't change that fact. And just hiding a bunch of functions in a class and calling them static methods isn't OOP either -- it's namespacing.
Think of a proper object as a struct (or "custom type", depending on your previous language exposure) that knows what to do. Objects are data that you don't (or shouldn't) act upon directly; you ask them to do things to themselves, and you ask them to tell you about themselves. You create entities and pass messages. OOP is about treating your data like it's all grown up and can handle itself. It's not about where the main line of code lives, but how data are treated.
Oh, and one more thing -- even in a language that is more obviously canted toward OOP, real OOP is not always the right approach. It's all about the data.
You can write classes with PHP, but most of the core features are not object-oriented.
It's been a long time since this question but I came upon this article and wanted to shre the author's point of view.
PHP is not object oriented!
This answer is inspired by this Man and his answer.
Object-Oriented technology is often described in
terms of encapsulation, polymorphism, and inheritance. But
these are only identity.
If object-oriented technology is to be successfully
it must emphasis on the object.
When we say Object-oriented or Object-orientation it can refer to several things:
Object-oriented analysis and design[OOAD]
Object-oriented design[OAD]
Object-oriented database
Object-oriented modeling
Object-oriented operating system
Object-oriented programming[OOP]-->topic of concern
Object-oriented software engineering
Object-oriented user interface
What Pure Object Oriented Programming Language[OOP] is?
Alan Kays["Considered by some to be the father of object-oriented programming"] [Defination]5 link by Gordon:
EverythingIsAnObject.
Objects communicate by sending and receiving messages (in terms of objects).
Objects have their own memory (in terms of objects).
Every object is an instance of a class (which must be an object).
The class holds the shared behavior for its instances (in the form of objects in a program list)
Now clearly it can be seen Java,C++ and PHP violates rule 1?Why bcoz int, float etc. (there are a total of eight primitive types). so it cannot be Object oriented in strict sense but some folk's considered it as OOP.
The general approach of OOP is to view a software system as a collection of interacting entities called "objects" each of which is defined by an identity, a state described in terms of member variables, and a behavior described in terms of methods that can be invoked
What OOP is not?
Object-Oriented technology is often described in
terms of encapsulation, polymorphism, and inheritance. But
these are only identity.
An Object Oriented system, language, or environment should include at least Encapsulation, Polymorphism, and Inheritance.
Polymorphism and Inheritance are certainly patterns that facilitate
OO programming, but not only bound to it
The object-oriented paradigm isn't completely the domain of
high-level programming languages -->may topic of debate but i came
across this OOP in Assembly
Uncle Bob aka Bob Martin in his lecture shows How C implements Encapsulation,Inheritance,and Polymorphism LINK
OO is based on modeling real-world objects // For Marketing purpose
Difference Between OOP and Functional?
This may be not be perfect answer but i gave a try,Thnks to knowledge of valley.
Note:
Images are randomly found on google
I'm hoping to get some tips to kinda help me break out of what i consider after all these years a bad habit of procedural programming. Every time i attempt to do a project in OOP i end up eventually reverting to procedural. I guess i'm not completely convinced with OOP (even though i think i've heard everything good about it!).
So i guess any good practical examples of common programming tasks that i often carry out such as user authentication/management, data parsing, CMS/Blogging/eComs are the kinda of things i do often, yet i haven't been able to get my head around how to do them in OOP and away from procedural, especially as the systems i build tend to work and work well.
One thing i can see as a downfall to my development, is that i do reuse my code often, and it often needs more rewrites and improvement, but i sometimes consider this as a natural evolution of my software development.
Yet i want to change! to my fellow programmers, help :) any tips on how i can break out of this nasty habbit?
What is the point in using object-oriented programming when you cannot find good reasons or motivation to do so?
You must be motivated by the need to conceive and manipulate ideas as objects. There are people who feel the need to be perceptive of concepts, flow or functions rather than objects and they are then motivated towards programming oriented towards concepts, ideas, or functional flow.
Some 13 years ago, I switched to c++ from c simply because there were ideas I needed but c would not easily perform. In short, my need motivated my programming oriented towards objects.
The object-oriented mind-set
First, you have bytes, chars, integers and floats.
Then your programme starts being cluttered with all kinds of variables, local and static.
Then you decide to group them into structs because you figured that all the variables which are commonly passed around.
Conglomeration of data
So like printer's info should have all its variables enclosed into the Printer struct:
{id, name, location,
impactType(laser|inkjet|ribbon),
manufacturer, networkAddr},
etc.
So that now, when you call function after function over printer info, you don't have functions with a long list of arguments or a large collection of static variables with huge possibilities of cross-talk.
Incorporation of information
But data conglomeration is not good enough. I still have to depend on a bunch of functions to process the data. Therefore, I had a smart idea or incorporating function pointers into the Printer struct.
{id, name, location,
impactType(laser|inkjet|ribbon),
manufacturer, networkAddr,
*print(struct printer),
*clean(struct printer)
}
Data graduates into information when data contains the processes on how to treat/perceive the data.
Quantization of information
Now laser, ribbon and inkjet printers do not all have the same set of information but they all have a most common set of denominators (LCD) in information:
Info common to any printer: id, name, location, etc
Info found only in ribbon printers: usedCycles, ribbon(fabric|cellophane), colourBands, etc
Info found only in inkjet: ink cartridges, etc
Info found only in lasers: ...
For me and many object-oriented cohorts, we prefer to quantize all the common info into one common information encapsulation, rather than define a separate struct/encapsulation for each printer type.
Then, we prefer to use a framework which would manage all the function referencing for each type of printer because not all printers print or are cleaned the same way.
So your preference/motivation oriented away from objects is telling you that your programming life is easier if you do not use objects? That you prefer to manage all those structural complexities yourself. You must not have written enough software to feel that way.
The necessity of laziness
Some people say - necessity is the mother of creativity. (as well as, Love of money is the root of evil).
But to me and my cohorts - laziness in the face of necessity are the parents of creativity. (as well as the lack of money is the other parent of evil).
Therefore, I urge you to adopt a lazy attitude towards programming so that the principle of the shortest path would kick into your life and you'll find but have no other choice than to graduate towards orienting yourself towards programming with objects.
Step 1. Read a good Design Patterns book. http://www.oodesign.com/
Step 2. Pick something you already know and rework it from an OO perspective. This is the Code Dojo approach. Take a problem that you already understand, and define the object classes.
I did this -- and wrote down what I did.
See http://homepage.mac.com/s_lott/books/oodesign.html#book-oodesign
You can do the same series of exercises to get the hang of OO design and code.
The OO mindset is based on principles that lie at a much more basic level than design patterns. Design patterns are somehow fashionable these days (and have been for a while), and they are useful, but they are just one more layer that you can put upon more basic stuff that you absolutely must learn and master if you want to do OO properly. In other words: you can do OO perfectly without design patterns. In fact, many of us did OO well before the phrase "design patterns" was even coined.
Now, there is stuff you can't do without. I suggest you start at the basics. Read and understand "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer. It's probably the best book on OO programming around, both in width and depth. That is if you're interested in programming.
First, congrats on taking steps to learn something new! I hate it when developers decide to NOT evolve with technology.
As far as moving from procedural programming to OOP, I would say that one thing that you can do is take an existing app (as others have mentioned) and, before you even open a text editor, sit down and think about how each aspect of the application would be converted. I have found that more than half of OO programming is defining the conceptual objects in your mind first.
Again, I will agree with everyone's recommendations on design patterns. Specifically, I would look into the MVC (Model-View-Controller) pattern as this one might be the easiest one to grasp. You have already written code, so you should be able to look at your existing applications and begin putting each part into the M,V or C categories.
Best of luck and have fun!
There are already quite a few answers about where to find information on programming in an object-oriented fashion. Indeed, there are many great books out there that will define the basic concepts however I think the question was more on how to "stick with it" through development for someone new to the method.
Of the many concepts in object-oriented programming, the main one that will keep you on track as a newcomer is encapsulation. Does my class know how to take care of itself? Does my class have behaviour? If it doesn't, then you don't have a class, you have a structure and you'll likely be writing a lot of procedures to change its state (as it's said, "you are back to writing C in Java"). Does my class only expose methods publicly that are required for its use? Those questions may not be terribly elaborated upon but perhaps consider this thought experiment when designing your classes: What if each one of your application's classes were to be developed and maintained by a different developer on the internet and the classes also had to interact with eachother over the internet. Would each developer agree that the class they are writing and maintaining adheres to the single responsibility principle and therefore be happy that they aren't maintaining what should be someone elses code?
Regarding the design of class interfaces, consider writing all of the code that uses your classes first. Don't worry about what has to happen at the metal yet. You should be able to stub out the entire program in terms of the class relationships before you write your first bit-twiddling implementation detail. If you can't do this without twiddling bits or making a variable public, then it is time to go back to your class relationship diagram and see if you are missing an abstraction. Phrased another way, use your code before you write your code. Do this first, and you might be suprised how clean your code and interfaces turn out if you've never done it before.
While design patterns are certainly good to learn, and some are extremely powerful, they aren't generally intrinsically object-oriented and as some argue (and I tend to agree) design patterns are often just exposed weaknesses in the language. One language's design patterns is another's basic founding principles. So when starting, don't get hung up on whether or not some relationship is a good candidate for a bridge or a facade; this is not specific to object-oriented thought, this is related to what a specific language's constructs afford.
Don't.
First, learn writing. Second, learn user experience and interaction design. Third, learn business analysis. Fourth, learn role modeling.
Now that you know what objects are, you will come to see that objects are not found in code. They are found at runtime; in the space between the machine and the user's mind. This is what object orientation really means. Unfortunately recent academia has twisted it into an engineering concept. Nothing could be further off the mark. And try as they might to emulate, the end result is crap. Why? Because the "OOP" paradigm as the industry knows it today is built on a fundamentally flawed idea: decompositional analysis of identity. How is this flawed? Because identity in and of itself is meaningless. It is void. In a mathematical sense, in a philosophical sense. This is not how a human being perceives and interacts with the world.
Canon: Alan Kay, Trygve Reenskaug, James (Jim) Coplien
How I wish I was in your position. :)
I think it helps to first skim over some existing, decent, proven object-oriented code (e.g. Qt source code) so you can get a feel for "how it's done". After that, learning from a book or creating your own framework will be much more effective.
In general, it really helps to see things in context before reading about and practicing them, as it gives you moments to say to yourself, "Oh, that's why they did that!" At least that's how it works for me.
The hard part of OO is which stuff should be put together into one object. As you already mentioned the evolution of your source code, here you have a simple guideline on how to evolve your source code towards an OO design:
"Put stuff together that changes together."
When two pieces of code have similar change velocities, that's a hint that they should be placed in the same object. When the change velocities are different, consider placing them in different objects.
This is also known as "Change Velocity".
If you follow that guideline your code will naturally evolve towards a good OO design. Why?
Fragments of code often have similar
change velocities if they access a
common representation. Every time the
representation changes, all the pieces
of code that use it must change at
once. This is part of the reason we
use objects as modules to encapsulate
representation. Separating interface
from implementation makes sense under
this guideline too - the
implementation changing more often and
thus having a higher change velocity.
If a class has a stable part and an
unstable part, that's a difference in
change velocity that suggests moving
the stable part to a (possibly
abstract) base class.
Similarly, if a class has two parts
which change equally often but at
different times or in different
directions (that is to say, for
different reasons), then that again
suggests refactoring the class.
Sometimes replace "class" with
"method". For example, if one line of
a method is likely to change more
often than the rest - perhaps it is
the line which creates a new object
instance and contains the name of its
class - consider moving it to its own
routine. Then subclasses can easily
effect their change by overriding it.
I came across this concept on C2 wiki many years ago, but I've rarely seen it used since. I find it very useful. It expresses some crucial underlying motivation of object oriented design. Of course, it's therefore blindingly obvious.
These are changes of the program.
There is another sense of change
velocity - you don't want instance
variables changing at different rate,
or rather that is a sign of potential
problems. For example, in a graphics
editor you shouldn't keep the figures
and the handles in the same
collection, because the figures change
once a minute or once an hour and the
handles change once a second or once a
minute.
In a somewhat larger view, you want a
system to be able to change fast
enough to keep up with the changes in
the business.
PS: the other principle that you should follow is "Law of Demeter", that is, an object should only talk to its friends. Friends are: yourself, instance variables, parameters, locals, and members of friendly collections - but not globals and static variables.
You might consider using the CRC (Class/Responsibility/Collaboration) card approach to OO design. This is nothing too scary - just a way to sort out what your objects should be, and which object should be responsible for which tasks by writing stuff down on a bunch of file cards to help clarify your thoughts.
It was originally designed as a teaching tool for OO thought, and might work for you. The original paper is at: http://c2.com/doc/oopsla89/paper.html
A poster above suggested programming in Smalltalk to force you into OO habits, and to an extent that's a good suggestion - Smalltalk certainly did me a lot of good, but
a) you may not have the spare time to learn a new language. If you do, great.
b) I used to tutor a university course in OO programming, using Smalltalk, and the students did an excellent job of proving that old joke about how "You can write FORTRAN in any language".
Finally: when I was learning about OO (from books) I got the impression that you subclassed a lot, creating complicated class hierarchies. When I started working with OO programmers I realised it didn't happen as often as I thought. I think everyone makes this mistake when they're learning.
The only way to write better code is to write more code. Take a project you've implemented procedurally and convert it to OOP (assuming you're working in a language that supports both). You'll probably end up with a fragile, tightly coupled solution the first time around, but that's ok. Take the bad OOP implementation and start refactoring it into something better. Eventually, you'll figure out what works, and what doesn't.
When you're ready to take the next step, pick up a Design Patterns book and learn some of the OOP design terminology. This isn't strictly necessary, but it will give you a better grasp of some of the common problems and solutions.
I think you should convince yourself by researching all of the downsides with procedural programming, for example (some buzzwords following, watch out): scope, state ... practically you'd be able to extract many terms just by reading examples of design patterns (read: common examples of using objects together.)
Stressing yourself into learning something you don't believe in won't get you anywhere. Start being really critical on your earlier work and refactor it to avoid copied code and using the global scope, and you'll find yourself wanting more.
For me the ah-ha moment of OOP was the first time I looked at code and realised I could refactor common stuff into a base class. You clearly know your way around code and re-use, but you need to think around classes not procedures. With user authentication it's clear you're going to have a username and password, now they go into the base class, but what if you need a tokenId as well, re-use your existing login base class, and create a new subclass from that with the new behaviour, all your existing code works without change.
See how that works for you.
Well, first off design patterns are about the worst thing to pattern your programming to.
It's just a big set of things. It's nothing to do with OOP, and most of them such as singleton are constantly used for all the wrong reasons (ie initialization). Some of these things you have to use so telling you about them is pointless, others are counterproductive, and the rest are just special case things. If you try to learn anything this way everything will start to look like some bizarre doodad someone came up with for a very special problem or because they needed infinite genericity (which is seldom true). Don't let people con you into using a million iterators and templates for no reason and make things ten times more complicated.
Really OOP is a simple subject that gets massively overcomplicated. Unfortunately in C++ it has a lot of issues but really simple virtual methods are what matters. Pure virtual base classes used much like a java interface object are the most useful but also just plain virtual methods here and there will come in handy.
It's mostly been overblown. It also doesn't lend itself well to every problem. If you make database and gui stuff it lends itself well to that. If you make system tools it is usually not as helpful.
I found that one of the things which has really helped solidify the benefits of OOP for me has been writing unit tests with a mock object framework (such as EasyMock). Once you start to develop that way, you can see how classes help you isolate modules behind interfaces and also allow for easier testing.
One thing to keep in mind is that when people are first learning OOP, often there is an overemphasis on inheritance. Inheritance has its place, but it's a tool that can easily be overused. Composition or simple interface implementation are often better ways of doing things. Don't go so far in attempting to reuse code via inheritance that you make inheritance trees which make little sense from a polymorphism standpoint. The substitution principle is what makes inheritance/interface implementation powerful, not the fact that you can reuse code by subclassing.
A great step would be to start of with a OOP framework, you can still write procedural code in the framework but over time you can refine your coding habits & start converting functionality into objects.
Also reading about patterns & data modeling will give you more ideas about to code your logic in a OOP style.
I have found that a very intense way learning to train abstraction in programming is to build a OOP library with a defined functionality, and then to implement two projects with similar but still different requirements that are building on that library, at the same time.
This is very time-consuming and you need to have learned the basics of OOP first (S.Lott has some great links in the other answer). Constant refactoring and lots of "Doh!" moments are the rule; but I found this a great way to learn modular programming because everything I did was immediately noticeable in the implementation of one of the projects.
Simply practice. If you've read everything about OOP and you know something about OOP and you know the OOP principals implemented in your language PHP... then just practice, practice and practice some more.
Now, don't go viewing OOP as the hammer and everything else as the nail, but do try to incorporate at least one class in a project. Then see if you can reuse it in another project etc..
Learn a new language, one that helps to move you gently to OOP. Java is nice, but a bit bloated, though. But its system library is mainly OO, so you are force to use objects.
Moving to another language also helps you not to reuse your old code :-)
I think it´s important to learn the theory first. So reading a book would be a good start.
I believe that the mechanics of OOP seem completely arbitrary and make no sense until you read a book on design patterns and understand the "why" of it. I recommend Head First Design Patterns. I thought OOP was ridiculous and completely useless until I picked up this book and saw what it was actually good for.
OO makes a lot more sense when you understand function pointers and how it relates to indirect function calls and late binding. Play around with function pointers in C, C++, or D for a little while and get a feel for what they're for and how they work. The polymorphism/virtual function part of OO is just another layer of abstraction on top of this.
Procedural is the right tool for some jobs. Don't act like it's wrong. IMHO all three major paradigms (procedural, OO, functional) are valuable even at a fine-grained level, within a single module. I tend to prefer:
Procedural is good when my problem is simple (or I've already factored it enough with functional and OO that I now have a subproblem that I consider simple) and I want the most straightforward solution without a lot of abstraction getting in the way.
Object-oriented is good when my problem is more complex and has lots of state that makes sense in the context of the problem domain. In these cases the existence of state is not an implementation detail, but the exact representation is one that I prefer to abstract away.
Functional is good when my problem is complex but has no state that makes sense at the level of the problem domain. From the perspective of the problem domain, the existence of state is an implementation detail.
I'm basically wondering if Python has any OOP shortcomings like PHP does. PHP has been developing their OOP practices for the last few versions. It's getting better in PHP but it's still not perfect. I'm new to Python and I'm just wondering if Python's OOP support is better or just comparable.
If there are some issues in Python OOP which don't follow proper OOP practices I would definitely like to know those. PHP for instance, doesn't allow for multiple inheritance as far as I'm aware.
Thanks Everyone!
Edit:
How about support for Public and Private? or support of variable types. I think these are important regarding building OOP software.
I would say that Python's OOP support is much better given the fact that it was introduced into the language in its infancy as opposed to PHP which bolted OOP onto an existing procedural model.
Python's OOP support is very strong; it does allow multiple inheritance, and everything is manipulable as a first-class object (including classes, methods, etc).
Polymorphism is expressed through duck typing. For example, you can iterate over a list, a tuple, a dictionary, a file, a web resource, and more all in the same way.
There are a lot of little pedantic things that are debatably not OO, like getting the length of a sequence with len(list) rather than list.len(), but it's best not to worry about them.
One aspect of Python's OOP model that is unusual is its encapsulation mechanism. Basically, Python assumes that programmers don't do bad things, and so it doesn't go out of its way to any extent to protect private member variables or methods.
It works by mangling names of members that begin with a two underscores and ending with fewer than two. Such identifiers are everywhere changed so that they have the class name prepended, with an additional underscore before that. thus:
class foo:
def public(self):
return self.__private()
def __private(self):
return 5
print foo().public()
print foo()._foo__private()
names beginning and ending with two (or more) underscores are not mangled, so __init__ the method python uses for constructing new instances, is left alone.
Here's a link explaining it in more detail.
I think they're comparable at this point. As a simple test, I doubt there's any pattern in Design Patterns or Patterns of Enterprise Application Architecture, arguably the two most influential books in OOP, that is impossible to implement in either language.
Both languages have come along by leaps and bounds since their infancies.
As far as multiple inheritance, it often creates more problems than it solves, and is, these days, commonly left out of languages as an intentional design decision.
Also: Python has native operator overloading, unlike PHP (although it does exist an extension). Love it or hate it, it's there.
If you are looking for "more pure" OOP, you should be looking at SmallTalk and/or Ruby.
PHP has grown considerably with it's support for OOP, but because of the way it works (reloads everything every time), things can get really slow if OOP best practices are followed. Which is one of the reasons you don't hear about PHP on Rails much.