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.
Related
For the life of me, I can't seem to wrap my head around "classes" in PHP.
I have managed to write large, scalable, and popular websites without them.
What am I missing? (And how do I learn?)
Classes will help with code re-use and potentially a very structured application.
Procedural programming can be a lot faster in both development time and execution speed.
OO programming is the more mainstream way but not always the best way. Theres a book called PHP Objects, Patterns and Practice which is a very good read, it covers the basics of classes, why and how to use, abstraction and common design patterns such as MVC. It also covers unit testing and other very good practices for php developers
The point of classes (object oriented programming) is that it bundles data together with the code that operates on it. If done well, this leads to less tightly coupled and thus more maintainable code.
In practice it means fewer global variables (whether used directly or accessed through static factory methods) and lesss passing around of data (i.e. smaller method signatures).
For a concrete example, look at the Mysqli extension: each function has a procedural and an OOP version, and the procedural version nearly always needs to have an extra "link" parameter to give it context, wheras the OOP version gets that context from the current object.
Everybody answered was right you are missing a lot because let's say you have a photo gallery website
instead of writing functions and in the end you end with a lot of them
OOP would be useful in:
Code organization and maintainability
Adds clarity, and reduce complexity
Emphasizes data over procedures
Code modularity
Code re-usability (Believe me you will need that a lot)
Well-suited for databases
I wasn't using OOP before but i started and to be honest not very long time ago, and found it very useful in those points specially in the re-usability of the code
Let's say i have a photo gallery website
i will create a class for users and this class will do CRUD on all of the users table
and a class for the photos to do the CRUD on all of the photographs table
I could also make a class to do all the CRUD for me without specifying on what table
and then use the inheritance to extend all the CRUD in my users class and my photograph class
the point in that is i could only write the CRUD methods once
and then re-use it in all of my other classes
I hope i would have answered your question
IMO, If you do not wish to seperate your htmls & php code; you better not use classes.
You'll need them in a framework environment (not necessarily), and you'll need them if you want to objectify your datas, handle them like that.
but if you're fine without it, then you're just fine :)
When it comes to handle a very complex system, with a lot of different data structures, more than one team members, etc. You and your code need to be organized very well, and you'll need classes.
Good question! You got my upvote!
Straight to the point:
You're missing a whole world!
There are many metaphors to describe it but there's nothing better than practice - you obviously know it after "years" of programming!
Decide on a small project and write it OOP style. Then you'll get the idea.
Take this tip as well: Name your classes as their file names (ex. "MyClass" -> "MyClass.php"). Easy to maintain.
You are probably missing testability: I guess your functions call other functions, which in turn might call another function, right? So you will have trouble testing an isolated function. With OOP you assemble "heaps" of objects and can interchange each object with a "fake" one (called mock or stub) for a test. This way, you can test each functionality in isolation. Think of being able to test you output code without needing a database. Think of testing your controller code (the code which processes the request parameters and decides what action to take) without needing a web server.
I'm currently developing a framework which uses an object of a Core class (this class has huge functionality & makes the framework working). The framework follows MVC architecture & has loosely coupled Model, Control, View classes. Theses classes need a reference to the Core class heavily. What I've done so far is: creating single object of the Core class & referencing to it by PHP keyword global in Model, Control, View classes.
I don't like using this approach mainly because:
This way is not true object oriented way in my sense
The IDE (netbeans) can't provide documentation to the object of the Core class - a pain for developers who will be using this framework.
I'm really worried about performance issues - have no idea whether global is slower or whatever.
I've searched & did not find any information regarding performance issue. I've also searched stackoverflow & found Does using global create any overhead? & The advantage / disadvantage between global variables and function parameters in PHP? etc links but they don't contain much information. Right now my main concern is performance, so please help.
I must agree with NevilleK, that you Core` class sounds line an God Object antipattern.
And for anyone dumb enough to suggest use of singletons/registries i would suggest to do a little research on the subject. They create the same global state as your classical global variables.
Global state is not so much matter of performance ( though in php it has some minor impact ), but it created untestable and tightly coupled code.
You really should look into the Dependency Injection. That might show you another way , which does not require to have such a Core class in your code.
Some additional videos for you:
Global State and Singletons
Don't Look For Things!
Advanced OO Patterns
Cake is a Lie
Clean Code: Arguments
I've solved a similar problem in Agile Toolkit by creating a different pattern for adding object and using it system-wide. This passes a property to a newly created objects called "api" which always references Application class.
Application class is not really a God class but it delegates all sorts of functionality to system controllers, pages etc. This screencast explains how the very basic objects are structured, it might be something you are also looking for:
http://www.youtube.com/watch?v=bUNEHqYVOYs
Firstly, whilst you are concerned with performance, you may want to read http://en.wikipedia.org/wiki/God_object first - your "core" class sounds like a "God object", which is a fairly well-established anti pattern.
In terms of performance - the best way to find out is to test it. If you're writing a framework, I'm assuming you're writing unit tests to validate it's behaviour; it's not hard to extend that unit testing to include simple performance metrics. You might also invest in test scripts using JMeter or similar to exercise a "reference implementation" of a few pages built using the framework. You'll get far better information on your specific situation from doing this than by trying to optimize the design based on Stack Overflow's collective knowledge of the general way things work.
In general, I'd say that having a global class shouldn't impact performance too much, as long as it isn't doing much work. Simply loading the class into memory, parsing it, etc. does have a performance impact - but it's not likely to be measurably slower than any other routes you might take.
If, however, your "core" class does lots of initialization logic when it's accessed by the page, it's obviously going to impact performance.
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 have PHP application that is completely procedural (No PHP Classes). In my case, is there any formal diagrams I can draw to show how my web application that is equivalent to a UML class diagram for OOP based applications.
Thanks all
doxygen can generate call- and caller graphs automatically - if that suits your needs.
You could make some Hatley-Pirbhai models:
http://en.wikipedia.org/wiki/Hatley-Pirbhai_modeling
It's not because the implementation (or even the design) is procedural, that the business model is.
Though you may not find explicit reference to classes in your code, they may still be there, hidden, scattered through global variables etc, functions manipulating some globals, ...
So in order to describe your app, you may still be able to use a (conceptual) class diagram.
I have returned to php development from Moose and I really miss CLOS like object model for php. Is there some kind of syntaxtic sugar which would allow me to write less code in php when dealing with objects?
Just to stress this requirement a bit more. I don't want to write one thing in several places. I can live with part of code being generated automatically, but in the code that I have to see to develop I don't want to see redundant information which is just clutter (think: LISP macro if you really need more analogy). So this part can be also called DSL if that makes more sense.
I would love to have at least roles (mixins), and some kind of introspection without re-inventing the weel. Code generators and auto-loaders might be one way to solve at least part of this problem.
p.s. For JavaScript there is Joose, so similar API would be very useful.
There are no mixins in php yet but there is an RFC for traits which will work roughly the same. http://wiki.php.net/rfc/traits
Using overloading for __call can allow you to dispatch methods to other classes and have it look like a mixin.
The Symfony project has a mechanism for mixins, allowing aspect oriented programming like in CLOS. Personally, I don't like this kind of hacking in userland spacee (At least not with PHP). I think you would be better off using the features that the language provides, and perhaps wait for something like traits to (maybe) make its way into the language.
There is also new project http://github.com/huberry/phuby which implements roles in php!