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
Related
I'm just beginning to learn PHP. Sorry, if it's a newbie question but I'm wondering how methods work. For example, if I wanted to remove white spaces at the beginning of a string. In Ruby, I would call something like:
string.strip!
But in PHP, I would have to do something like:
trim(string);
Obviously, the Ruby version is more elegant(in terms of object-oriented design), but I'm wondering how it works for PHP and other languages such Java. Is there a name for designing functions/methods this way(in PHP)? And where are those methods defined and why can they be accessed anywhere? Thanks a lot in advance!
There are two different paradigms here: object-oriented programming (OOP) and procedural programming.
In OOP, functions are defined in the context of data, encapsulated by classes; such functions are usually called methods. When a method is called on an object (e.g. an instance of a class), it inherently has access to the state of that object. So, in your example, strip already knows what string it's being called on, and so doesn't require any additional arguments. Whenever your function naturally operates on a particular object or set of data (e.g. as strip acts on a string), it is sensible to define it as an instance method in this way.
In procedural programming, functions are defined independently data structures (classes), and must be explicitly passed the data they are to work with. Sometimes this approach is in fact more natural; for example, a print function that prints some input to stdout, or similar, isn't naturally associated with any particular object or data.
Most modern languages have OO features built into them, as it's a very versatile and powerful programming paradigm. Languages like Java and C# encourage all code to be written in an object-oriented style. In these languages, even the basic data-types like strings and floating points are in fact objects and have their own methods and state. This is particularly true in C#, where all types inherit ultimately from System.Object (even int and double) and inherit all the common methods defined thereby. This is called a unified type hierarchy.
PHP, on the other hand, has a curious mixture of OOP and procedural features; it started life as a procedural language, and OOP was only introduced in version 3 (and only in a very rudimentary sense). While, as of PHP5, it has relatively good OOP support, most of its standard library is still implemented procedurally as loose collections of functions that expect to have the relevant state/data passed to them as arguments. OOP libraries are becoming more common, however (e.g. with mysqli).
You're looking at, essentially, the different between instance methods and class/static methods. Instance methods are called on a specific instance of a class, and they have access to the internal state of that instance. Class/static methods are not, and do not.
I'm not sure what you're looking for in asking "how it works for PHP and ... Java." With regard to instance vs non-instance methods, Ruby, PHP, and Java all work roughly the same.
I am documenting a PHP4 system I'm building for a client. The system will be written following an object-oriented logic, using the MVC pattern. I have already sketched up a class diagram; however, I am now wondering if it makes sense to create object diagrams for such a system, since it follows the OOP model rather loosely.
The closest thing to object-oriented behavior in this system will probably be a handful of methods changing their behavior based on how they're being called, although this can't exactly be called instancing straight-up classes; would an object diagram capture anything useful from this scenario, or am I better off just skipping them altogether? Thanks in advance.
In my experience, UML Class diagrams are best used in an isolated context -- to describe a section of the system.
So my answer is that if you are describing a piece of your system in a document, and a UML class diagram would help a reader understand the relevant section of the system then you should do a diagram for that section and include it.
Doing one class diagram for the entire system is rarely, if ever, useful. And including various class diagrams without context is also rarely useful.
Be strategic in your use of UML; it's a communication tool, not a documentation tool. (Sort of like writing. Words on paper means nothing unless used and organized thoughtfully)
I think the flexibility of your situation conflicts with expectations of UML.
I would suggest abstracting the implementation level from your diagram (and lie) and represent the functionality of those methods as independent methods performing their own work.
I am about to start learning Objective-C and I was wondering whether or not the concepts are the same as with PHP. For example, are the concepts in Object Oriented PHP the same as Objective-C, such as "Class, Instance, Message, Method, Instance Variable, Inheritance, Superclass/Subclass, and Protocol"? If so, this will I am guessing it will be much easier for me to learn and grasp since I already know the basics and foundations of Object Oriented PHP. Or are they completely different from each other?
Any help and advice is greatly appreciated. Thanks!
They are basically the same idea, but not implementation, since most of those are CS theory concepts. Messages and protocols don't exist in PHP. PHP has what most languages call an interface which is akin to a protocol in Objective-C.
All "propper" OO language constructs should be essentially the same. They should always have all of, or a sub section of the the following (and probably more).
class / object (completely different)
method (vs function)
method visibility/access control (public, private, protected)
constructor
static/class variables & methods
destructor/finalizer
inheritance (and often, multiple inheritance)
interface/protocol
abstract class
overriding
overloading
there are plenty more terms to do with things that are more conceptual rather than language features, but that's a short (and reasonably incomplete) list of some things that you should know for programming in ANY OO language worth it's salt.
There's a nice little list of terms on Wikipedia to help if you'd like.
http://en.wikipedia.org/wiki/List_of_object-oriented_programming_terms
I'd suggest reading about the terms above, as well as
Instance variables
Polymorphism
Composition
Encapsulation
If you know your defenitions of OO, moving from one language to the next is far simpler, because you will have a very wide base to stand on and only have to learn subtle differences (as with learning any new language after knowing a few, but more so with OO concepts).
The short answer is "Yes." The medium-length answer has been written by Apple, and you can read it here:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/OOP_ObjC/Introduction/Introduction.html
I've been playing mostly with PHP and Python.
I've been reading about Interfaces in OO programming and can't see an advantage in using it.
Multiple objects can implement the same interface, but multiple inheritance doesn't provide this as well?
Why do I need to create an Interface "with no implementation" - mainly a "contract" - if I can just check if a method exists in an object in Python, that inherits from multiple classes?
Do Interfaces were created in another languages because they don't provide multiple inheritance? Or am I missing something more important here?
First, and foremost, try not to compare and contrast between Python and Java. They are different languages, with different semantics. Compare and contrast will only lead to confusing questions like this where you're trying to compare something Python doesn't use with something Java requires.
It's a lot like comparing the number 7 and the color green. They're both nouns. Beyond that, you're going to have trouble comparing the two.
Here's the bottom line.
Python does not need interfaces.
Java requires them.
Multiple objects can implement the same interface, but multiple inheritance doesn't provide this as well?
The two concepts have almost nothing to do with each other.
I can define a large number of classes which share a common interface. In Python, because of "duck typing", I don't have to carefully be sure they all have a common superclass.
An interface is a declaration of "intent" for disjoint class hierarchies. It provides a common specification (that can be checked by the compiler) that is not part of the simple class hierarchy. It allows multiple class hierarchies to implement some common features and be polymorphic with respect to those features.
In Python you can use multiple inheritance with our without interfaces. Multiple inheritance can include interface classes or not include interface classes.
Java doesn't even have multiple inheritance. Instead it uses a completely different technique called "mixins".
Why do I need to create an Interface "with no implementation" - mainly a "contract" - if I can just check if a method exists in an object in Python, that inherits from multiple classes?
If you create an interface in Python, it can be a kind of formal contract. A claim that all subclasses will absolutely do what the interface claims.
Of course, a numbskull is perfectly free to lie. They can inherit from an interface and mis-implement everything. Nothing prevents bad behavior from sociopaths.
You create an interface in Java to allow multiple classes of objects to have a common behavior. Since you don't tell the compiler much in Python, the concept doesn't even apply.
Do Interfaces were created in another languages because they don't provide multiple inheritance?
Since the concepts aren't related, it's hard to answer this.
In Java, they do use "mixin" instead of multiple inheritance. The "interface" allows some mixing-in of additional functionality. That's one use for an interface.
Another use of an Interface to separate "is" from "does". The class hierarchy defines what an objects IS. The interface hierarchy defines what a class DOES.
In most cases, IS and DOES are isomorphic, so there's no distinction.
In some cases, what an object IS and what an object DOES are different.
The usefulness of an interface is directly connected to the usefulness of static typing. If you're working in a dynamically-typed language like PHP or Python, interfaces truly don't add significantly to the expressiveness of the language. That is, any program that can be described as using interfaces can be expressed without significant difference without using interfaces.
As a result, Python has a fairly nebulous concept of a "protocol" (an implementation conforming to a certain pattern, like the iteration protocol) which amounts to essentially the same thing, but without the other benefits of compile-time checking its value is limited.
In a statically-typed language, on the other hand, an interface is essential to allow implementation to be decoupled from implementation. In a static language, the types of all expressions must be resolved at compile time, so normally bindings to implementation must be made at that time, limiting run-time flexibility. An interface defines how to access functionality without defining a specific implementation, which allows a static language to prove that expressions are correct without having access to the implementation.
Without interfaces (or an equivalent formulation like C++'s pure virtual functions), the expressiveness of a statically-typed language would be severely hampered. In fact, many implementations exist (Win32 and COM come immediately to mind) to essentially reproduce much of the functionality of interfaces and virtual dispatch in C by storing function pointers in structures (and thus re-implementing C++'s virtual functions and vtable invocation by hand). In this case there is a big difference in expressiveness, since many changes are required in the program to express the same concepts.
Interfaces are just one example of type polymorphism, and a fairly limited one at that. In languages that support parametric polymorphism (aka generics) you can accomplish much more. (For example, C#'s LINQ would not be possible without generic interfaces.) For a much more powerful form of the same kind of thing, look into Haskell's typeclasses.
Even in duck-typed languages like Python, an interface can be a clearer statement of your intent. If you have a number of implementations, and they share a set of methods, an interface can be a good way to document the external behavior of those methods, give the concept a name, and make the concept concrete.
Without the explicit interface, there's an important concept in your system that has no physical representation. This doesn't mean you have to use interfaces, but interfaces provide that concreteness.
In dynamically typed languages, like PHP and Python, interfaces are only of limited use. You can already attempt to call methods on any object whenever, and you get a run-time error if it doesn't exist.
It's in statically typed languages, like Java and .NET, that interfaces become important, because methods and their arguments are checked at compile-time.
Now, for interfaces:
Java has Lists in addition to arrays. As a general rule, arrays are for primitives (the number types mainly), while Lists are for objects.
I can have a List<String>, which is a list of strings. I know I can add strings to it, and get strings back from it.
I don't know which implementation it is. It could be an ArrayList (list backed by an array), a LinkedList (list backed by a doubly linked list), a CopyOnWriteArrayList (thread-safe version of ArrayList), etc...
Thanks to polymorphism and interfaces, I don't need to know which type of List it is to do List operations on it.
Because you want to program against an interface and not a concrete implementation (GoF 1995:18)
Because sometimes you don't want to provide an implementation.
Java Interface
Java class
Yes. As for PHP, interfaces are just a means to overcome the lack of multiple inheritance. There are minor semantic differences useful for IDEs, and fewer conflicts caused by interfaces clearly aid newbie programmers. But as said before, it's not strictly necessary in dynamic languages.
http://c2.com/cgi/wiki?MultipleInheritance
Please read Twisted Framework article about power of Zope Interfaces in python.
It's generally implemented to replace multiple inheritance (C#).
I think some languages/programmers use them as a way of enforcing requirements for object structure as well.
For our school project, we are tasked to define a design document describing the architecture of a PHP application.
We are free te decide what to include in the document.
Our professor suggested, lots of (UML) diagrams.
He also asked us to consider class diagrams, but with care, as PHP is not fully object oriented.
My question: Is a Domain Driven Object Oriented Design feasible for a PHP application? What to consider when doing OO in PHP? What are the pro's and con's? Any helpful resources on OO in PHP and PHP best-practices?
IMHO it's pretty difficult to describe the architecture of any application without knowing what the application is supposed to do. All applications (PHP or otherwise) of any complexity look different.
Secondly, PHP5 gives you classes/objects and the usual plethora of OO gubbings - so to describe it as 'not fully object orientated' is misleading I think. If you mean you can take a procedural approach with out being restricted to objects then yes, but if you wanted everything to be an object then that's your choice.
Is DDD feasible for PHP? Yes, of course. A particular approach to architecture is not usually dependent on technology. Best practices, pros/cons of OO design apply to most languages - PHP leaves you pretty free to decide how to structure your code.
You may find this Best Practices talk from the PHP site useful ;)
Most OO languages currently in use are not fully object-oriented. Every language has idiosyncrasies and gotchas.
So I'd say PHP is OO enough for most simple projects. I worked on the Zend Framework which is designed as an OO class library, with design patterns and such.
One suggestion for PHP is that you should pay attention to its SPL component, which gives you interfaces for many basic classes.
I think it's pretty weak if your teacher said, "put anything you want into the design document, UML diagrams are pretty." Design documentation is an important but woefully undervalued part of software engineering. Your teacher should be showing you examples or templates for good design doc.
PHP can nowadays be described as fully object oriented by choice. It offers everything you need but you are not forced to write OO code.
There are two books which helped me a lot in understanding the OO principles in relation to PHP:
PHP in Action (Manning)
Zend Study Guide for PHP5 (Zend)
OO is first and foremost a design methodoligy.
As such it is possable to come up with an OO design which can be implmented
in procedural langauges. I have seen this done for both C and COBOL projects.
And it has convinced me that nearly all the advantages of OO are to do with design and NOT language implmentation.
So yes you can come up with an OO design with lots of UML (Class diagrams, use cases, swim lanes etc.) and you can implement it in php (using classes or not).
Anyway php is effectively a superset of OO so if you restrict youself to classes
and functions inside classes ( == methods) you have an OO implementation.
The only thing lacking will be interface definitions but it makes very little
sense to define interfaces in a language with such (un)limited type checking.