When simple is not sexy

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

When simple is not sexy

Post by alex.barylski »

Title get your attention? :P

I've been following a debate over at Sitepoint about Zend and it's bloat. While I agree Zend is over-engineered I would also suggest that CodeIgnitor is not any better, being to simplistic.

I am trying to think of examples where 'simple' is a bad idea:

1. Adding that last SQL query to a template just to get the project finished, as opposed to taking the time to add an additional model method or refactoring an existing one.

2. Using globals! sure they make development a little faster during initial implementation but they make maintenance a potential nightmare.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: When simple is not sexy

Post by josh »

When someone releases a plugin architecture that is inherently doomed for failure http://joshribakoff.com/?p=81
Using singletons 'in the wrong context'
hard coding multiple SQL queries that only vary with eachother by a parameter or two
duplicating code to avoid any indirection
having blocks of code in loops & conditionals instead of using polymorphism or extracting methods
business logic in in the view files ( I should be able to do $product->getPrice() without 1,000 extra lines of code doing extra calculations )
Creating "sub-modules" or subpackages when the code is not specific to any specific module (trying to avoid creating too many packages, but at the cost of each package being harder to understand)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Re: When simple is not sexy

Post by Jenk »

Over-developed visitor pattern is my pain at the moment.

Other idioms are things like:

Code: Select all

if ( ($x > 3 && $x < 9) || ($x == 0)) {
instead of:

Code: Select all

if ($this->isValid($x)) {
or:

Code: Select all

$found = false;
foreach ($foo in $bar) {
  if ($foo == "foo") { $found = true; }
}
 
if ($found) { echo "foo found!"; }
instead of:

Code: Select all

if ($this->containsFoo($bar)) { echo "foo found!"; }
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: When simple is not sexy

Post by alex.barylski »

josh: Good points - thanks :)

jenk: I like that first example, excellent case of 'easy to write, hard to read and therefore modify'.

I wish more took both 'reading' and 'writing' of code into consideration when implementing anything. If they did, I am sure all those easy 'hacks' you find in code would not exist. At least to the extent they do now.

As much as I favor Zend over code ignitor, I do find it's controller implementation way way over engineered. Perhaps my own are missing some crucial functionality but I would be surprise if my front and base controllers counted more than 100 lines.

So while Zend is at least geared towards good design, I fail to see how simplicity in design escaped them. ugh.

My intention is not to turn this into another Zend VS XXX framework I am not even venting at the moment, just sharing. :) Please don't get offended if your form either CI of ZF camps :)

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: When simple is not sexy

Post by josh »

Well keep in mind they have routes, a plugin architecture, etc..
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: When simple is not sexy

Post by alex.barylski »

Not sure I follow, what was routes and a plugin architecture? Zend controllers?

You can acocmplish the same extensibility with my own framework, only routing is something done outside the context of a front controller. I'm not sure what you mean by plugin architecture in this conversation though, can you exaplin a little better maybe i'll learn something about Zend controllers :)

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: When simple is not sexy

Post by josh »

If you have utility methods on different controllers you need to use.

Like if you have a regular user & premium user controller. Later you decide to write an admin controller that needs methods on both, but due to their inheritance hierarchies its impossible. The plugin broker is basically like a system that sits inside of your __call method and allows you to use "helper" classes.

There's a lot that can go into the plugin system. I have heard developers give speeches on why using a plugin system is so foolish, yet the huge community of developers taking advantage of it don't care about leaving these people behind.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: When simple is not sexy

Post by alex.barylski »

Hmmm...interesting...although I don't think I would encounter any issues like that, as my controllers are not typically reusable like that.

I started following that extreme chain of thought "thin controllers-fat models" zealously and it's resulted in very dumb controllers, anything I needed in controller A might possibly inherited from controller B, but it would be something trivial, like providing a base controller to initialize a complex view, which all derived controllers would then tweak according to their context (such as setting title, etc).

Anything authentication or anything else for that matter would be stored in a model, which would be equally accessible from any controller.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: When simple is not sexy

Post by josh »

An example of useful plugin is one that inflects the name of the module/controller/action and checks an ACL table, and redirects the user to a login page
or one that maps request parameters to arguments of the action method.
etc...
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: When simple is not sexy

Post by alex.barylski »

By controller plugins you mean, like a front controller and intercepting filters - or do you mean each controller has additional pre and post action execution plugins.

I have use a pre-filter plugin to achieve basic authentication before, thus avoiding using a base controller to perform the checks and possible security hole introduced by failing to derive a controller from the proper superclass.
or one that maps request parameters to arguments of the action method.
My framework only supports system wide intercepting filters (pre and post). They are executed before and after each action invocation. So parsing a URI and initialing the request object with NVP, at this point, wouldn`t make much sense, at least it could be done more effectively in other places, in my setup anyways.

In any case, I think I understand what you mean by plugin architecture now, fairly standard with most MVC frameworks. :)

Just slightly different implementations.

Now I am actually curious though, how does a controller support pre and post plugins, in addition to the system wide intercepting filters -- do you derive from a base controller which provides this additional functionality. I have though about doing something like that in times past but could never think of a scenario where the problems are not better solved else where.

Cheers,
Alex
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: When simple is not sexy

Post by josh »

Usually there is a plugin interface you implement with your plugin, or an abstract plugin base class that provides blank implementation for each method ( so you implement only the method you are interested in)

The plugins just need to be observers of the events, whatever object has an instance of an event broker should be able to notify all the plugins at events regardless of where they are called. But when you say system wide events I think that could be a bad term, events are like variables in the sense that you probably want to scope /type them. Like a domain specific event like a user adding an item to his cart, should be an entirely different subsystem then a front controller plugin. Supposedly there are some really involved event patterns, some people use the concept of event "channels" which would work similar to exception bubbling
Post Reply