Quote Originally Posted by selkirk
Robert Martin has a principle of OO design called the Interface Segregation Principle: Clients should not be forced to depend on stuff that they do not use.

The PHP 5 Interface structure is one method of exposing a smaller, more limited view of oneself to different clients, one interface for each role.

Another way to accomplish interface segregation is through delegation. A class can offer a different delegate object to each of its clients, depending on the role it is performing. With both methods, the size of the interface exposed to a client object is reduced and thus the potential for dependencies.
One way to interpret this is if I have an object with 4 methods - such as read(), insert(), update() and delete() - and I have 4 presentation layer components - such as 'read a record', 'insert a record', 'update a record' and 'delete a record' - then I should create a series of delegate objects which expose to each presentation component only those methods which that particular component needs to use. This would lead to an enormous proliferation of classes within the system and would lead to a maintenace nightmare. As it offers no functional benefit it is an idea that I would avoid like the plague.

Why would people take this perverted view? Someone has taken the word 'depend' in Martin Fowler's principle and changed it to 'visible', thereby corrupting the meaning. Unfortunately this is a tendency which I have noticed time and time again in the OO world. It starts off with a perfectly valid statement, and over time various people add a bit to it, or change a word here or there, until eventually the end result is a total corruption of the original which newcomers then treat as the gospel truth! It is a bit like the game of Chinese Whispers - the message starts off as "Send reinforcements, we are going to advance", but by the time it reaches its destination it has become "Send three and fourpence, we are going to a dance".

As an example of what I am talking about take a look at Abstraction, Encapsulation, and Information Hiding by Edward V. Berard of The Object Agency who demonstrates how the definitions of 'abstraction' and 'information hiding' have come to mean different things to different people.

If different people can define different principles in so many different ways, then how on earth are us mere mortals supposed to put those principles into practice? If an individual's implementation depends upon his interpretation of those principles, then as sure as day follows night people with different interpretations will produce different implementations. Then those who used the definition containing 'visible' will accuse those who used the definition containing the word 'depend' of not obeying the rules and therefore not producing a 'proper' and therefore invalid implementation.

The major point of this particular thread is that I have created a development infrastructure which is based on a combination of the 3-tier architecture and the MVC design pattern, and I have been attacked most vociferously for producing an impure and invalid implementation because there is not a proper 'separation of concerns' between the various layers. It is the statement 'separation of concerns' which is the root of this argument. What is a 'concern'? Is it data? Is it information? Is it code? is it logic? Is it a method? Is it a property?

In my humble opion the statement 'separation of concerns' is open to far too many different interpretations and therefore far too many different implementations. Because it has far too many meanings it is virtually meaningless, therefore invalid. Software does not have 'concerns', it has 'data' (information) and 'code' (logic). A valid statement would be either 'separation of data/information' or 'separation of code/logic' as neither of these statements is open to vast amounts of (mis)interpretation.

With my own implementation I have clear 'separation of logic', not 'separation of concerns'. This means that I may have information which is defined in one component but which is not actually processed until it is passed to another component. This is (in my humble opinion) perfectly valid as it is where the information is processed which is important, not where it came from.

Here is an example of a typical criticism of my design:-
Your domain layer contains information on the structure of the database, and as this belongs in the data layer you have not demonstrated proper 'separation of concerns' therefore your design is unclean/impure/invalid/unacceptable.
My design principle was the 'separation of logic' defined by the 3-tier architecture, and as I have achieved that level of separation my design is (in my humble opinion) perfectly valid. Each object within my business layer contains information on the structure of the database table with which it is associated, and this information is passed to my data access object whenever any communication with the database is required. As I have a single DAO for my entire application and not a separate DAO for each database table the structure of individual database tables is not defined within the DAO. This means that the information must be passed to the DAO from an external source whenever any database access is required. And what exactly do I use as my external source? Why, the object that initiates the request to process some data. This means that both the data and the table structure come from the same source, which is why the table structure is defined within the class that deals with that data. I do not hold the table structure in a separate class as that (in my humble opinion) would 'break encapsulation', but that is a different argument altogether.