Archive for Other Paperswithout synopsis

What is the difference between Procedural and OO programming?

Although some people like to say that OO programming is totally different from Procedural programming and requires a totally different way of thinking, in my mind it is exactly the same except for the addition of encapsulation, inheritance and polymorphism. There is no change in the code that is written to "do stuff", only in the way that it is packaged. Procedural languages have plain old functions, whereas OO programs have classes and methods which encapsulate both data and behaviour. The use of classes then provides a new way of reusing code - inheritance and polymorphism.

Published: 20 April 2017

DB or not DB, that is the question

This is in response to an article written by Robert C. Martin in which he states that the database is not the center of the system the heart and soul of the design.

Published: 05 March 2017

On not using the "right" standards

While it is well known that writing code which meets a minimum set of standards is a good thing, there are some people who ignore the word "minimum" and insist on a more extreme (or even perverse) interpretation. They then insist that anyone who doesn't follow THEIR standards will always be writing sub-standard (ie. bad) code. This article explains why some standards are themselves bad, and the only way to produce not-bad code is to ignore them, or only apply them in limited circumstances.

Published: 13 December 2016

Object Oriented Database Programming

When writing a database application the software interacts with inert objects in a database and not physical objects in the real world. Each "object" in a database is a table, its properties are its columns, and its methods are limited to Insert, Select, Update and Delete. The software should therefore be designed to follow the database schema, which means that all the theories in Object Oriented Design are totally redundant. The proper application of Encapsulation, Inheritance and Polymorphism will then produce software with more reusability and less maintenance, which are supposed to be the objectives of using OOP.

Published: 01 November 2016

How NOT to Validate Data

When programmers try to write code which conforms to certain rules they assume that by following the rules their code must automatically be correct. But what if these rules are wrong? This article shows that by ignoring artificial rules, and the problems which they inadvertently create, it is possible to achieve better results with less code.

Published: 02 April 2016

OO Design is incompatible with Database Design

Writing code which communicates with a database is not the same as writing code which communicates with a "real world" object, so the software design process should be centered around the database. By designing software according to the rules of Object Oriented Design (OOD), then designing the database according to a different set of rules will produce nothing but a pair of incompatible designs. Instead of trying to deal with these inconsistencies with special code I can achieve better results by ignoring OOD altogether and designing my software around the database structure.

Published: 01 April 2016

Using object composition for "has-a" relationships is not such a good idea

Because of Object Oriented Design (OOD) most programmers consider that inheritance is for "is-a" relationships and composition is for "has-a" relationships. Where an object has properties which are represented by child tables in the database, object composition dictates that the child table be accessed through its parent table. This adds complexity to the parent class, and to those controllers which access these child tables. It also increases tight coupling, decreases cohesion and reduces the opportunity for polymorphism by introducing method names which cannot be shared. My preferred approach is to ignore OOD and treat each database table as a class in its own right, thus avoiding unnecessary complexity and offering better coupling, cohesion and polymorphism.

Published: 03 November 2015

Please do not break our language

This is my response to the idea that the next major release of PHP - version 7 - should contain as many Backwards Compatibility breaks as possible.

Published: 31 December 2014

A minimalist approach to Object Oriented Programming with PHP

This article explains why the current trend of making OOP more and more complicated with the excessive use of design patterns and not-so-solid principles and practices is defeating the original aim of Object Oriented programming which was: "to be easier to learn for those new to computer programming than previous approaches, and to be simpler to develop and to maintain, lending itself to more direct analysis, coding, and understanding of complex situations and procedures than other programming methods". Instead of writing more and more code with ever increasing levels of indirection the wise programmer should actually adopt a minimalist approach - do enough to get the job done and then stop.

Published: 14 September 2014

4+ Reasons Why All PHP Frameworks Suck - Except RADICORE

This is a response to an article written by Manuel Lemos called "4 Reasons Why All PHP Frameworks Suck?"

Published: 17 February 2014

Table Oriented Programming (TOP)

This article describes why it could be better, when using OOP to access a relational database, to work directly with database tables instead of indirectly through an ORM, thus unleashing the power and flexibility of SQL and making both development and maintenance easier.

Published: 02 July 2013

Not the three greatest paragraphs ever written on encapsulation

This article challenges the description of 'encapsulation' which I found on the internet. The concept of encapsulation is supposed to be simple, yet some people cannot help but redefine it in ways that hide the simplicity under layers of misinformation and misdirection.

Published: 19 May 2013

Database Design - are you Novice, Ninja or Nincompoop?

When you design your database for your PHP application are you aware that some of your design decisions can have a detrimental effect when it comes to writing the code to access that database? I have been designing databases, and building the applications which use them, for several decades, and I have learned over the years that there are some design decisions which help the developer while others do nothing more than hinder. This article lists 18 of these “hindrances”.

Published: 23 September 2012

Not-so-SOLID OO Principles

Some people say that you must follow the SOLID principles if you want to write "good" OO software, but I don't think that these principles are as "solid" as they are made out to be.

Published: 08 June 2011

Dependency Injection is EVIL

In my opinion the Dependency Injection design pattern creates more problems than it solves, and has little or no justification in the real world.

Published: 03 June 2011

Creating an SQL Server driver for RADICORE

This article shows how a database driver for the SQL Server database was developed for the RADICORE framework.

Published: 01 January 2011

Object Relational Mappers are EVIL

In my opinion an ORM causes more problems than it solves, so this article shows why they are unnecessary and how I managed to build a system without one.

Published: 20 August 2007

Creating an Oracle driver for RADICORE

This article shows how a database driver for the Oracle database was developed for the RADICORE framework.

Published: 15 January 2007

What is OOP?

There are many conflicting opinions on what OOP is or is not, so here are some of my own to add to the mix.

Published: 03 December 2006

Stored Procedures are EVIL

Here are some reasons why I choose not to use database stored procedures and triggers.

Published: 03 September 2006

Software Patents are EVIL

Are software patents a good thing or a bad thing? Here is my personal opinion.

Published: 31 August 2006

Is Radicore better than Ruby On Rails?

Ruby On Rails is the subject of an immense amount of hype, but are there parts of it which are less than perfect and open to improvement? Do these "improvements" already exist within Radicore?

Published: 28 May 2006

Design Patterns are dead! Long live Transaction Patterns!

There is a more powerful level of abstraction than that provided by design patterns. Read this for more details.

Published: 18 May 2006

Are you a Code Monkey?

In days gone by an organ grinder's monkey danced to his master's tune. A "code monkey" is someone who dances to someone else's tune, someone who is a follower, not a leader.

Published: 17 March 2006

Case Sensitive Software is EVIL

People who call for more case sensitivity in PHP just to be "consistent" with other languages do not understand that by perpetuating a bad idea they are simply being "consistently bad".

Published: 27 January 2006

Breaking Backwards Compatibility is EVIL

A small number of thoughtless programmers are changing the language in the name of "code purity", but instead of improving the language all they are doing is turning thousands of users off by causing existing scripts to break and thus slow down the migration to PHP 5.

Published: 18 December 2005

Creating a PostgreSQL driver for RADICORE

This article shows how a database driver for the PostgreSQL database was developed for the RADICORE framework.

Published: 10 September 2005

Development Standards - Limitation or Inspiration?

Standards are supposed to represent "best practice", to inspire others to produce great works, but some are so badly written that all they do is create artificial restrictions, limitations and obstructions and actually get in the way of making progress.

Published: 29 May 2005

Object-Oriented Programming for Heretics

There is a certain breed of programmer who believe that there is only one way to use OOP, and that is their way. Like religious fanatics they brand all those who stray from the "one true path" as heretics. Read this article and learn that writing like a heretic can actually make you more productive!

Published: 10 December 2004

In the world of OOP am I Hero or Heretic?

I don't follow other people's rules like a religious fanatic, so in their eyes that makes me a heretic. Yet other people like what I do, so in their eyes I am a hero. So what am I really?

Published: 25 November 2004

Design Patterns - a personal perspective

Some people think that design patterns are the best thing since sliced bread, but I do not share that view. When I am building user transactions I prefer to use transaction patterns instead.

Published: 13 October 2004

The Relational Data Model, Normalisation and effective Database Design

This discusses the workings of a relational databases, about keys, relationships, joins and dependencies. It explains what normalisation is and how to do it, as when denormalisation is OK. It explains what an Entity-Relationship Diagram (ERD) is, and gives a few personal guidelines.

Published: 30 September 2004

Technical Keys - Their Uses and Abuses

There are two ways of using technical keys - intelligently and indiscriminately. The indiscriminate use of technical keys shows a distinct lack of intelligence.

Published: 01 January 2004

What is/is not considered to be good OO programming

For every approach that can be taken in OO programming there is one bunch of people who will say that it is good while another bunch will have a totally opposite opinion. So who is right?

Published: 03 December 2003

Component Design - Large and Complex vs. Small and Simple

When designing application components there is a very important choice to be made up front - do you use a small number of large, complex components, or a large number of small, simple ones.

Published: 30 June 2001