Archive for Other Paperswithout synopsis

The difference between Tight and Loose Coupling

While a lot has been written about the term "coupling" and its meaning in Object Oriented Programming, there is still a lot of confusion about the differences between tight and loose coupling and why one is supposed to be better than the other. In this paper I discuss the differences and explain the benefits which I have personally achieved by aiming for as much loose coupling as possible.

Published: 20 February 2025

OOP practices which save time

I am told that I did not follow the "best practices" which were created by OO "experts" when I developed my RADICORE framework. This is true for the simple reason that I did not know that they existed. Instead I created my own set of "better practices" based on decades of prior programming experience. This paper explains which of those "best practices" I avoided and explains the reasons why my own practices produce better results.

Published: 21 December 2024

The true purpose of Dependency Injection

All the artcles I read on the topic of Dependency Injection claim that its purpose is to separate the construction of objects from their use. This is not the end, it is just the means to an end. The true purpose is to provide a mechanism to take advantage of polymorphism and thus provide components which can be reused instead of duplicated.

Published: 28 November 2024

DTOs are Diabolical

I have recently seen some articles which claim that Data Transfer Oobjects (DTO) are a good idea. This article explains why I disagree.

Published: 24 November 2024

A challenge to see who's technique is best

Fellow programmers do not believe me when I say that my framework makes me more productive than them, so I challenge them to prove it. I can create a family of forms to maintain the contents of a new database table in a matter of minutes without writing any code - no PHP, no HTML and no SQL - so if they can't match that it proves that their methods are less productive and therefore inferior.

Published: 21 November 2024

RE: Back to Basics - Three or Four OOP Pillars?

Some people still think that there are four pillars of Object Oriented Programming - Encapsulation, Inheritance, Polymorphism and Abstraction - but I disallow Abstraction as it existed before OOP came into being, therefore it cannot be a distinguishing feature. Even worse is when someone limits abstraction to data abstraction instead of functional abstraction, and then claims that data abstraction should be implemented as a Data Transfer Object (DTO). This article identifies the mistakes in that erroneous assumption.

Published: 20 November 2024

The Fallacy Of ReUse

Everybody knows that to become a productive programmer on a large application with many repeating patterns you do not write a fresh copy of each pattern, instead you try to create a single central reusable version which you can reference many times over. The logic is simple - the less code you have to write to get the job done then the quicker you can get the job done and the more productive you will be. However, there are some programmers who lack the ability to either spot repeating patterns or to make reusable versions of those patterns without introducing fresh sets of bugs. Rather than blaming their lack of skill they claim that it is the quest for reusable software which is at fault. Here are my comments for one such claim.

Published: 20 August 2024

From Wireframe to Prototype to Live Product

When building a new application there are several different stages to go through which may require different tools, such a wireframe, storyboard, mockup and prototype, and evetually the live product.Wouldn't it be nice if, instead of having to use a different tool for each which may mean not being able to use the output from one tool as the input for the next tool, you could use the same tool for each. Such a tool does exist, and it is called RADICORE.

Published: 10 August 2024

Programmer Productivity takes Precedence over Paradigm Purity

There are far too many "best practices" which rely on the dogmatic and pedantic following of rules instead of the production of best resuls and the highest productivity. Here is a list of those practices which I ignore in favour of something better.

Published: 20 July 2024

Attributes are atrocious

Attributes offer the ability to add structured, machine-readable metadata information on declarations in code. However, the modern method of inserting them as comments into the source code is very primitive when compared with the much simpler method which I devised 20 years ago. The information is extracted from the application database, stored in disk files, then loaded directly into class properties without the need to amend any source code, and without the need to extract the comments via Relection.

Published: 24 June 2024

Autoloaders are abominations

Autoloaders are seen as a method of dealing with the need for multiple "include" statements before a class can be instantiated. I see this "need" as a mistake on the programmer's part as it should only be necessary to have a single class for each object, otherwise you would be violating the principles of encapsulation and high cohesion.

Published: 24 June 2024

Composition is a Procedural Technique for Code Reuse

It has been said that inheritance is a procedural technique for code reuse and that object composition should be used instead. I believe that the truth is the exact opposite, and this article explains why.

Published: 24 June 2024

Decoupling is delusional

The decoupling of dependencies is supposed be be a good idea, which shows a total lack of understanding of what the terms tight coupling and loose coupling actually mean. Decoupling is the total absense of any direct coupling, but the act of introducing an intermediate object to perform indirect coupling has the effect of replacing one method call with two, which doubles the amount of coupling and there doubles the problems that it causes instead of eliminating them.

Published: 24 June 2024

Value objects are worthless

According to OO afficionados "everything is an object" which means that using primitives (scalars) for values is frowned upon as "proper" OO programmers should be using value objects instead. As far as I am concerned there is nothing that can be done with value objects that cannot already be done with primitives, so as they have a high implementation cost and zero benefit I regard them as being totally worthless, without any value whatsoever.

Published: 24 June 2024

Strict typing is for stick-in-the-muds

While many of the early programming languages were strictly typed most of the modern languages, such as PHP, are not because it places fewer restrictions on programmers and makes them more productive. Yet some programmers who started off with a strictly typed language, or who were trained by old fogeys who used strictly typed languages, still hang on to the belief that such languages are "better" and refuse to change their mindset. Instead of using PHP and trying to embrace this different approach they instead expend far too much effort on converting the language from being dynamically typed to strictly typed without realising that this is a backward step. Will these neanderthals ever learn?

Published: 24 June 2024

KICK Principle - Keep It Complex, Knucklehead

This is the exact opposite of the KISS principle (Keep It Simple, Stupid)

Published: 24 June 2024

I fail to GRASP these principles

GRASP is a set of principles much like SOLID, but I have found that the descriptions given for each of the nine parts is so vague that they are easily mis-interpreted, which leads to faulty implementations. In this article I examine each of the nine points to give my own interpretation and explain my own implememtation.

Published: 27 March 2024

Namespaces are for numpties

Since namespaces were added to PHP programmers have rushed to add them to their code, and there are even calls to add them to the language itself. There are three places where namespaces could be used - in PHP core, in applications, and in 3rd-party libraries - but by following the principle of YAGNI there is only *ONE* place where their implementation could be said to be necessary.

Published: 27 March 2024

Inheritance is NOT evil

When I first encountered the rule "Prefer Composition over Inheritance" I asked myself "Why? What is wrong with inheritance? What's so great about Composition?" It turns out that the only problem with inheritance is caused by programmers not understanding how to use it properly. This article explains how the correct use of inheritance if far superior to anything offered by composition.

Published: 17 March 2024

Getters and Setters are EVIL

If data coming into an object from an HTML screen or an SQL database appears as an array containing multiple columns, what is the point of decomposing that array into its component parts so that that can be inserted or retrieved one column at a time? This produces the effect known as tight coupling which is supposed to be bad, but passing all data around in an array produces loose coupling which is supposed to be good.

Published: 02 December 2023

Object Associations are EVIL

Databases do not have "associations" which must be handled within each table object, thus requiring volumes of custom code, they have "relationships" which can be handled by reusable framework code.

Published: 02 December 2023

Object Interfaces are EVIL

Object interfaces were created to provide polymorphism without the need for inheritance in strictly types languages, so they have no place in PHP which is dynamically typed and which can provide polymorphism without inheritance AND without interfaces. Their use in PHP is therefore a complete waste of time and a violation of YAGNI.

Published: 02 December 2023

How to Produce a Rich Domain Model with Active Record

This is my response to yet another programmer complaining that his implementation of the Active Record pattern does not produce satisfactory results. As someone who has used this pattern for 20 years without encountering any of the issues which he complains about I can only conclude that he either chose the wrong pattern to start with, or completely botched the implementation. After all, every design pattern merely describes what needs to be done and does not dictate how it should be done. That is down to the skill (or lack thereof) of the individual programmer.

Published: 12 October 2023

The case against function overloading in PHP

Ever since type hinting was added to PHP in an attempt to make it behave more like a statically typed language there have been calls from a growing number of developers to add "proper" function overloading so that it works like it does in those other languages. This article argues that function overloading was the solution to a problem which exists in all statically typed languages, but as PHP is dynamically typed it does not have the same problem therefore does not need the same solution.

Published: 18 July 2023

RE: Why PHP is not suitable for enterprise grade web applications

I came across an article which claimed that PHP is not suitable for writing enterprise applications, but as I have been doing just that for the past 20 years I feel I have to challenge every one of his arguments.

Published: 11 July 2023

The case against static typing in PHP

PHP has always been dynamically typed, but over the years there has been a gradual movement to make it more statically typed. At first this was optional, but this is now becoming mandatory. This article explains why this is a bad move which will bring nothing but grief to the hordes of application developers due to the amount of code that will break and the huge amount of effort that will be required to fix it.

Published: 26 June 2023

Is there a case for adding namespaces to PHP core?

Ever since namespaces were added as an option to PHP there have been calls to force PHP to use namespaces for all internal functions and classes. This article describes why this idea is totally pointless and without merit.

Published: 08 April 2023

Active Record: Getting it Right

I came across an article which complained about the Active Record pattern, but in my view the problem exists with the author's implementation of that pattern and not the pattern itself. In this article I explain how my implementation does not produce the problems which he complains about.

Published: 31 March 2023

The PHP core developers are lazy, incompetent idiots

With the release of PHP version 8.1 the PHP core developers have chosen to break backwards-compatibility on an enormous scale for no good reason. This article identifies what they have done and explains why it is BAD!

Published: 13 February 2023

The database is NOT just an implementation detail

When working with databases a lot of OO programmers are told that "the database is just an implementation detail" which is why they build their software first and plug in the database as an afterthought. This, to me, is totally the wrong approach. I recently discovered where this erroneous idea originated, and this article presents a counter-argument.

Published: 04 February 2023

The meaning of "abstraction"

This article offers a better explanation of the term "abstraction" when used in OOP, breaking it down into data abstraction and functional abstraction.

Published: 01 November 2022

From Oop to Poop, from Excellent to Excrement

Many programmers think that by following all the rules, best practices and principles that they can find that their software will automatically be as good as what the experts can produce. This article attempts to demonstrate that some of these best practices are actually not the best at all, and by implementing some of the principles in inappropriate circumstances, or by implementing misinterpretations of these principles, that the results will turn out to be excrement instead of excellent.

Published: 01 February 2022

How to decouple business logic from UI logic

This article explains the difference between business logic and UI logic and how they can be decoupled in your code.

Published: 01 September 2021

Fat Model, Skinny Controller

In the Model-View-Controller design pattern there is still much confusion about what pieces of logic (program code) go where. Should it be in Fat Controllers or Fat Models? This article explains my implementation and justifies it by showing the results that it achieves.

Published: 25 July 2021

RE: The purpose of inheritance is code reuse

Some people have crazy ideas concerning the fundamentals of OOP, such as a post I recently read in which the author stated that the purpose of inheritance is NOT code reuse. This post is a rebuttal of that notion.

Published: 01 May 2021

Pop Quiz on OOP

There are many ways in which you can achieve your objectives in Object Oriented Programming, and there are many rules, principles or "best practices" which are supposed to point you in the right direction. This article poses a series of questions with multiple choice answers in order to identify if you are a dogmatist or a pragmatist, whether you know only what you have been taught or you have managed to learn something on your own.

Published: 09 May 2020

RE: Improving PHP's Object Ergonomics

This is my reply to an article which states that PHP is at fault because it doesn't support the author's choice of programming style, and this causes him, and others like him, to write more lines of code than they feel is necessary. It is my opinion that the language is perfectly adequate and that the actual fault lies with their choice of programming style.

Published: 02 April 2020

Changing Fundamental Language Behaviors

There has been a lot of arguments lately within the @internals group about things that some people regard as bad and which should be removed from the language. Some people agree with the removals as they would make the language more "pure" and therefore acceptable to "proper" programmers, while others say they do no harm, have been used without issue for over 20 years, and would cause major disruptions for large numbers of websites which would suddenly stop working. This is my personal view on this touchy subject, and it is a view shared by others.

Published: 16 August 2019

Are you achieving the aims of OOP?

If the aim of OOP is to produce more reusable code by implementing encapsulation, inheritance and polymorphism then I'm afraid that too many of today's programmers are failing. This article shows that my implementation of these three basic principles, while deemed to be heretical by a lot of clueless newbies, is actually a better implementation as it produces far more reusable components than I have ever seen in other implementations.

Published: 01 August 2019

Re: Exceptions and talking back to the user

This is in response to an article on someone else's blog which I think gives misleading information concerning the use of exceptions.

Published: 01 May 2019

To There and Back - but still in the wrong place

This is in response to an article on someone else's blog which I think gives misleading information.

Published: 08 April 2019

The Template Method Pattern as a Framework

This describes the Template Method pattern, and how I used it to build my framework.

Published: 02 March 2019

Anatomy of an Enterprise Application

This describes my view of an enterprise application, and how I followed that view to build my framework.

Published: 01 September 2018

Re: What's so great about OOP?

This is my response to someone's attempt to explain to a group of newbies the benefits of using OOP. His explanation was not basic enough for me, so my attempt may be more illuminating.

Published: 03 August 2018

Re: Objects should be constructed in one go

I replied to someone's blog post on this subject, but he did not like that I did not share his opinion and deleted my response, so I have reproduced it here.

Published: 19 July 2018

Blockchain for Blockheads

Blockchains are being hyped as "the next BIG thing", and as usual with hype there is a lot of confusion. Here I provide answers to some of the basic questions that are asked.

Published: 23 June 2018

BC break in 7.2 caused by undocumented and unauthorised change

BC breaks are annoying, but the worst are those which suddenly appear without any warning whatsoever. This is one such break which made me VERY annoyed!

Published: 15 June 2018

Your rules are RUBBISH!

Some programmers tell me that because I do not follow the same rules as them then what I do must surely be wrong. They fail to see that if I am able to achieve better results by not following their rules then it is THEIR rules which must be rubbish!

Published: 01 April 2018

The concept is OK but your implementation is not

Some programmers dislike certain concepts or ideas because of perceived problems without realising that those problems are caused by a faulty implementation. By changing the implementation you can eliminate those problems and thus continue to use that concept.

Published: 18 March 2018

Why I don't do Domain Driven Design

An enterprise application may have to deal with different business areas for that organisation, such as Order Processing, Invoicing, Inventory/Stock Control and Shipments. Although each of these areas handles totally different data and totally different business rules, these differences can all be handled in a similar fashion. All the data is spread across numerous database tables, and each table can be handled in exactly the same way. The business rules will be different, but they can all be handled in the same way. By building these similarities into a separate system with components that can be shared, each business area can then be regarded as a separate sub-domain or sub-system as part of a larger domain or system.

The RADICORE framework was built to develop database applications as it provides pre-written components to deal with all the similarities. Each subsystem is developed as an extension or add-in to the framework and then run under the control of the framework.

Published: 01 March 2018

Having a separate class for each database table IS good OO

While large numbers of programmers claim that having a separate class for each database table is not good OO I disagree most strongly. This article explains why.

Published: 01 December 2017

Singletons are NOT evil

Large numbers of programmers are told that singletons are evil, but they do not understand why, they only echo what they have been told. This article shows how a different implementation of this design pattern may eliminate all of these perceived problems, thus making it not evil in the slightest.

Published: 01 December 2017

The difference between an interface and an abstract class

This explains the differences between an interface and an abstract class, with an ordinary class thrown in for good measure.

Published: 16 September 2017

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

Your code is crap

My critics are fond of telling me that my approach to software development is different from theirs, and being different it must be wrong (aka "crap"). This is my response to some of their accusations.

Published: 28 January 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