Is the way of grouping classes different with PHP? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly r开发者_如何学Pythoneopened, visit the help center for guidance. Closed 11 years ago.

As the title states; the way one groups classes in PHP compared to for example Java, is it supposed to be different? I am currently reading O'Reilly's book OOA&D and in the chapters I've learned to use one class for each specific task and not one class for a grouped thing. Recently, I looked upon some code for a calendar, and the class was thousands of lines and had everything inside it that was to be used. However, this feels to me like it's violating the point of having many objects doing one task, but seeing as PHP is web development, is it supposed to be different? E.g. monster-classes.

---

Answer: use good design principles, even in PHP.

In addition to not creating Monster classes (also known as God-classes or objects) the following patterns are worth mentioning specifically:

• Object naming:
  • Class names should be nouns because they are objects.
  • Method names should be verbs, because they are actions.
• Cohesion. The short-version is basically: methods do one thing and do it well.
• Property Visibility: Variables should private unless you've got a dang good reason not to, and in such case, use protected. Almost always you should avoid public.
• Use interfaces and abstractions. Almost no one uses interfaces in PHP, but they should. It means that I can write my own implementation details but still hook in with some service that uses the class.

A somewhat outdated article on PHP design patterns that's still worth reading but is hard on the eyes.

Short-version:

If you are ever relying on an array to hold a particular structure it should probably be in a class.

---

An example from my life: ActiveRecord

What if I want to build a website that does not need any particular Active Record implemenation? At the moment, I'm quite stuck once I choose an implementation because they are all so unique. If they actually implemented an ActiveRecordInterface, I would be able to swap out my actual ActiveRecordEngine if I wanted to change.

---

I've learned object-oriented programming over 15 years ago and have been using it with C++, Java, Pascal. The PHP at that time was much less powerful than it is now. It took PHP about 10 years to implement Objects properly. They finally work fast, references are passed properly.

Unfortunately, many developers who started with PHP haven't got a grasp on a proper object-oriented design of software. The class is often used like a "library" and everyone speaks about de-coupling and having everything independent, so in many cases classes won't have parent.

There are no solid foundation what everyone could agree on and use. When you turn to the frameworks, some are better and other are worst in terms of the proper OOP. For instance, the proper Code Igniter framework is fast, secure, simple to use, but has very bad OOP design. The main reason is compatibility with PHP4.

For a better-structured frameworks, simply look at the source code of some of their components:

Tabs in Yii: http://code.google.com/p/yii/source/browse/tags/1.1.8/framework/web/widgets/CTabView.php

Tabs in Agile Toolkit: https://github.com/atk4/atk4/blob/master/lib/View/Tabs/jUItabs.php

Tabs in CakePHP: http://bakery.cakephp.org/%20articles/view/4caea0e3-ac74-409b-8693-435282f0cb67

My conclusion is that the language in itself is OK, but a lot of badly written code is out there.

---

It is not supposed to be so. Monser-classes are always "bad" because it is hard to fix bugs / implement new features or maintain your code.

---

Just because people have written the code and made the source available doesn't mean that it's always going to be good code.

The principles you're used to (small classes that do their one thing well) is a good one. But not every developer follows those principles.

In the PHP world, a lot of people have worked their way up through it from the early days, when everything was in a single procedural monolithic block of code -- and I've seen some horrendous examples of that still in everyday use. Converting one's mindset from that to an OOP structure at all can be a big leap for some people, and even for people who haven't come from that background, a lot of the code examples they would be learning from are, so it's not a surprise to see monster classes.

The short answer is to write code the way you're comfortable with and the way you've been taught. It sounds like you've got better coding practices ingrained into you than most PHP developers out there, so don't feel you have to change just because other people are doing things differently.

---

Don't know if this answers your question but my experience is that it's quite common for PHP scripts and plugins like the calendar you mention to be constructed in the monster-class kind of way because of PHP's poor support of namespaces and encapsulation. The same goes for Javascript which also tends to have superbig classes in some cases (jQuery for example).