SitePoint Sponsor

User Tag List

Results 1 to 25 of 274

Threaded View

  1. #13
    SitePoint Addict
    Join Date
    May 2003
    Location
    Calgary, Alberta, Canada
    Posts
    275
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Tony Marston
    Really? I've never seen anything written in the principles of OOP that says a class must not have more than 'n' methods or 'n' properties, so as far as I am concerned that rule does not exist and so I choose to ignore it. It is an artificial rule designed by someone who likes to add complexity to the problem.
    Its quite possible that Im wrong in everything Ive said in this thread however if you are interested in learning different ways or teaching your way you are going to need to come up with arguments to support your opinion that have more substance than "Ive never read anything that says that so as far as Im concrened youre wrong".

    Quote Originally Posted by Tony Marston
    The definition of encapsulation is quite clear - all the properties and methods for an object must go into a single class.
    Deciding what methods and properties belong to which object is where I think youve gone wrong.

    Quote Originally Posted by Tony Marston
    My presentation layer is not tied to my database, nor is my business layer. The only layer which has physical communication with any database - by using the database APIs - is my data access layer. I am therefore able to switch from one dbms engine to another simply by switching the component in my data access layer. This is what the 3-Tier architecture is all about, and I have implemented it correctly.

    If it comes to changing the structure of a table by adding or removing fields, then I agree that I have to make changes in my presentation and business layers, but such changes are extremely small being limited to adding or removing a field name from a simple list.

    This is NOT a weakness in my design, it is a fact of life. You cannot write a business object that does not have knowledge of the data it has to work with, nor can you write a presentation layer that does not have knowledge of which fields to place where, and with what HTML control. It is simply not possible to write software which does not have knowledge of which fields exist in the database, therefore changes in the physical structure of the database will require changes in the software's knowledge of the database.

    I have worked with several languages over the past 20 years that have used data dictionaries (aka application models) where the dictionary is a representation of the physical database. It is imperative that the dictionary and the database are kept synchronised - if you make changes to one without making corresponding changes to the other the software will fail.

    What I have done is to place a mini data dictionary within each business object which simply contains the database engine name, the database name, the table name, and a list of fields. So if I change the physical structure of the database I must also change the data dictionary.
    Can you change the name of a form element and not make any changes in the data access layer?

    Can you change the name of a column in the database and only change the 'data dictionary' in one place?

    Quote Originally Posted by Tony Marston
    Wrong! I have components of sql statements in my presentation layer, but these are not built into complete queries until they are processed within my DAO. If a different DAO needs to organise those components in a differet way, then that is handled within the DAO and is completely invisible to both the presentation and business layers.
    Its code like this im refering to (person_list.php):
    PHP Code:
    $table_id 'person';                   // table name
    $title    'List PERSON';              // form title
    $screen   'person.list.screen.inc';   // file identifying screen structure
    $button_text 'Person';

    // identify extra parameters for a JOIN
    $sql_select '*';
    $sql_from   'person '.
                  
    'LEFT JOIN pers_type ON (person.pers_type_id = pers_type.pers_type_id)';
    $sql_where  '';

    // set default sort sequence
    $sql_orderby ''
    This is not the data access layer.

    What happens if you change the name of the person table? Does this code need to be changed?

    What happens if you change the pers_type_id column name? Does this code need to be changed?

    What happens if you change the way a person is related to a person type in the database? Would this code need to be changed?

    Maybe I didnt see the code that would make these changes but if your answer to any of these questions is yes then your layers are mixed up.

    Quote Originally Posted by Tony Marston
    I never claimed that my entire infrastructure was OO, just my business and data access layers. I have a lot of procedural functions because there is absolutely no benefit in making them non-procedural. They work just fine as they are, and they would not work any better if I changed them, so why change them? 'If it ain't broke don't fix it' is an old, wise saying that comes to mind.
    Putting "class Default_Table {" before a list of procedural functions and "}" after the list does not make the code Object Oriented.

    Quote Originally Posted by Tony Marston
    Surely it will not reduce te amount of code, but simply move it from one large class to a series of smaller classes. But then I will have to have extra code to instantiate and communicate with these extra classes, so the end result will not be LESS code but MORE code, and more complex code at that. I think I shall ignore your advice and stick to the KISS principle.
    The end result will be less code, but not until you refactor.
    Last edited by Brenden Vickery; Nov 13, 2004 at 18:20.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •