SitePoint Sponsor |
|
User Tag List
Results 126 to 150 of 274
-
Nov 14, 2004, 17:45 #126
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
If you put pure procedural code into an object, it is still procedural code. It can't be orientated around objects if it is just procedural code modularized using classes.
Originally Posted by Tony Marston
Code that works in better than code that doesn't work. This is as true for all code, procedural and OO.
You may implement the 3-tier architecture in a different way, but as long as it fulfills its purpose it would be a perfectly valid implementation, just as mine is a perfectly valid implemenation.
My motto is "innovate, don't immitate", so I will always look for a different way, a better way.
For example, putting procedural code in a class and saying that it is suddenly not procedural will get negative comments.
DouglasLast edited by DougBTX; Nov 14, 2004 at 19:03.
Hello World
-
Nov 14, 2004, 19:30 #127
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Methods surround and hide the object's nucleus ["the object's variables" fig. 1] from other objects in the program. Packaging an object's variables within the protective custody of its methods is called encapsulation.
And a list of other ones: http://www.google.com/search?q=define%3Aencapsulation
Note that the definition above does not mention how objects should be defined, nor how many objects there should be, nor how much code should go in an object's implementation.
It is simply a statement that objects have data and methods.
Encapsulation, along with the other three "principles of OOP" are language level principles. They say nothing about the overal design of a OO system, so you cannot use them to back up your design choices. As one of the articles you linked to earlier states, "encapsulation doesn't even ensure basic object-oriented objects." If it can't ensure OO objects, you obviously can't use it to demonstrate that your objects are OO.
DouglasLast edited by DougBTX; Nov 14, 2004 at 20:24.
Hello World
-
Nov 14, 2004, 21:04 #128
- Join Date
- Jul 2004
- Location
- Canada, Qc
- Posts
- 42
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Doug: Well Tony maybe talked a lot about OO, but he somehow admitted it was not OO code 100% as in OO Design ;-)
I think however it will be nice to know what other people trying to do the same as him if it is really more productive or what. If it is really faster than how he claims it, etc.
-
Nov 14, 2004, 21:10 #129
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by MickoZ
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 14, 2004, 21:24 #130
- Join Date
- Jul 2004
- Location
- Canada, Qc
- Posts
- 42
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
lastcraft:
is Active record like:
Code:Class Something { function save() { if ($this->id is null) { // insert } else { // update } } function load($id) { } }
Is the book from Fowled explain the pattern clearly, etc. (I guess so) and is there any "good tutorial" on the same pattern over the net. I guess I should buy the book and read it slowly, it mights show what I thought and what is the "best way" to do the thing I though (see think about the thing I have not anticipated I guess)
-
Nov 14, 2004, 21:35 #131
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 14, 2004, 21:55 #132
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Tony Marston
? I've answered this about three times now. Please reread the earlier comments by myself and others.
Originally Posted by Tony Marston
The shortcuts I am describing are in restricting the OOness of the domain objects in favour of less infrastructure code. An isomorphic mapping is the lowest common denominator (it seems you don't quite have even this). PEAR DB_DataObject is of this type. Adding one to many relationships, etc, as with Propel is the usual compromise. Java has the JDO spec (and Hibernate) which support various forms of aggregation and inheritance and have object query langauges on top. That would be a very complete separation, but one we can only currently achieve in PHP with hand coded mappers.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 14, 2004, 22:25 #133
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Tony Marston
) that enters emails and another that enters it as an instant messenger service, how will your system cope. You have exposed the implementation by which you send messages. You have broken encapsulation yet again.
Several times you have claimed that you open to new ideas. I have just presented an alternate scheme that is superior on just about every senario and you still don't listen. Amazing.
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 14, 2004, 22:44 #134
- Join Date
- Apr 2003
- Location
- London
- Posts
- 2,423
- Mentioned
- 2 Post(s)
- Tagged
- 0 Thread(s)
Hi...
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Originally Posted by Tony Marston
Because you have never looked beyond your favourite two pattern books (whatever they are) everything looks innovative to you. There is nothing innovative in your system except where you have committed some kind of random design error. The data gateway patterns are the most primitive of all, but somehow you still managed to mix them into a confusing mess. You have used a TransformView over a TemplateView in the one and only set up where it's complete overkill. TransformView is way more infrastructure than templating and poses restrictions on the skills of the developers and designers. Hardly KISS.
This is not heretical any more than any beginner's mistakes are heretical. Getting beyond this requires nothing more than letting people point you in the right direction. You don't even have to listen to what we suggest and I wouldn't want anyone to take my word as gospel. It does require you to take the trouble to read at least the Fowler books, however. Then you can go and make up your own mind.
Ignorance certainly isn't bliss for the people who have to put up with it.
yours, MarcusMarcus Baker
Testing: SimpleTest, Cgreen, Fakemail
Other: Phemto dependency injector
Books: PHP in Action, 97 things
-
Nov 15, 2004, 05:48 #135
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
If not there are plenty of OO tutorials on the web which are also wrong. I have seen several which show how to take some procedural code and do it 'the OO way', and guess what? The code looks more or less the same, but simply enclosed in "class whatever{}".
Originally Posted by DougBTX
-
Nov 15, 2004, 05:48 #136
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Layers encapsulate some, but not all, things well. As a result you sometimes get cascading changes. The classic example of this in a layered enterprise application is adding a field that needs to display on the UI, must be in the database, and thus must be added to every layer in between.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Nov 15, 2004, 06:04 #137
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Why extends is evil may be more relevant.
An interface is the same thing as an abstract class with no implementation, except for the fact that you can do multiple inheritance with them. Thinking about them in a single inheritance context is the most interesting aspect.
Originally Posted by lastcraft
Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Nov 15, 2004, 06:23 #138
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Originally Posted by lastcraft
There are two major objectives to this architecture:
- In order to switch from one database engine to another you simply change the component in the data access layer. This should not need any changes in any of the other layers.
- Should you wish to change the user interface, such as from client-server to the web, you simply need to change the components in the presentation layer. You may instead create new ones so that you can have the client-server interface and the web interface running at the same time. This should not need any changes in any of the other layers.
In other words all the code you write for the business layer (which is where the bulk of the code goes) is independent of the other two layers and does not need to be changed should either the DBMS engine or the UI be changed. This therefore protects the investment made in constructing a separate business layer.
There are no other rules. There are no implementation details, there are no rules governing what information needs to be passed between the different layers, or how they should be passed. There is just a simple list of objectives. If you write code which meets those objectives (as I have, in two different languages) then what you have is 3-tier. The fact that my implemenation is different from yours is totally irrelevant.
If you have found authors who have created additional rules for the 3-tier architecture, and you choose to follow those rules, then that is your choice. Personally I do not recognise any additional rules, so I do not waste my time implementing them. That is my choice.Last edited by Tony Marston; Nov 15, 2004 at 09:15.
-
Nov 15, 2004, 06:38 #139
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Originally Posted by Martin Fowler, PoEAA
-
Nov 15, 2004, 06:41 #140
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Encapsulation is a language construct that facilitates the bundling of data with the methods operating on that data. Information hiding is a design principle that strives to shield client classes from the internal workings of a class. Encapsulation facilitates, but does not guarantee, information hiding. Smearing the two into one concept prevents a clear understanding of either.
The Java language manifestation of encapsulation doesn't even ensure basic object-oriented objects. The argument is not necessarily that it should, just that it doesn't. Java developers can blithely create bags of data in one class and place utility functions operating on that data in a separate class. So as a first rule:
Encapsulation rule 1: Place data and the operations that perform on that data in the same class.
This standard practice creates classes that adhere to the principles of abstract data types.
-
Nov 15, 2004, 07:11 #141
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Originally Posted by lastcraft
I must thank dagfinn for providing this valuable quote:Originally Posted by dagfinn
Originally Posted by lastcraft
Last edited by Tony Marston; Nov 15, 2004 at 09:18.
-
Nov 15, 2004, 07:13 #142
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
-
Nov 15, 2004, 07:20 #143
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
That is exactly how my infrastructure works.
-
Nov 15, 2004, 08:07 #144
- Join Date
- Nov 2001
- Location
- Bath, UK
- Posts
- 2,498
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
you want more of your objects; you want them to represent cohesive, workable entities. A second rule concerns the manner of choosing the data and operations to encapsulate:
Encapsulation rule 2: Use responsibility-driven design to determine the grouping of data and operations into classes
DouglasHello World
-
Nov 15, 2004, 08:47 #145
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Originally Posted by lastcraft
Originally Posted by lastcraft
Originally Posted by lastcraft
-
Nov 15, 2004, 08:47 #146
- Join Date
- Oct 2001
- Posts
- 656
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Secondly, give me a definition of object oriented programming which requires more the code to be more than just consisting of classes. Not your definition, but the definition (rethorical question: is there any book, internet site, or whatever that gives such a good definition of what OOP is, instead of just some person's interpretation of what it should be?).
Thirdly (nitpicking), "orientated" means we're talking about Asia here. The correct term is "oriented".
If you put pure procedural code into an object, it is still procedural code.
Originally Posted by DougBTX
Precision of concepts is important, people! Please try to realise this! The very reason we are having this heated discussion is because 'our' whole foundation is imprecise, vague and ambiguous!! OOP has no clearly defined concepts and therefore anybody can and is free to interpret the interpretations of other people in a way that most suits their needs. Is that a bad thing, freedom of interpretation? Yes! In an exact science like computer science, which is what PHP and OOP are founded on (right?), precision is important!
Also, consider this (note that I said 'consider', which means 'think about it' and is not the same as 'I want you to accept this'): if OOP leaves open so many questions and has so many subjective sides to it, perhaps the model is just a bad model? It may have good sides (believe me, it does) but there are bad sides to it - which I hope I have shed some light on in this post..
End.
Originally Posted by lastcraft
Originally Posted by Tony Marston
If not there are plenty of OO tutorials on the web which are also wrong.
Originally Posted by Post #140
But of course if you view 'language construct' as a more broader concept, you can see just exactly what you want in this definition of encapsulation: ambiguity -> vagueness -> confusion!
-
Nov 15, 2004, 09:10 #147
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by lastcraft
Originally Posted by lastcraft
All your arguments seem to be based on the fact that my methods are different to yours, not that my results are any better (or worse) than yours. I am a pragmatist in that my primary concern is the result, and I will use or discard any methodology as I see fit in order to achieve that result. I will use or discard any set of arbitrary rules as I see fit in order to achieve that result. Where a definition is open to interpretation I will use whatver interpretation I see fit in order to achieve that result.
You, on the other hand, fit the classic description of a dogmatist - you think that following an arbitrary set of rules to the letter and without question is more important than obtaining the best result.
-
Nov 15, 2004, 09:27 #148
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Encapsulation rule 1: Place data and the operations that perform on that data in the same class.
Originally Posted by DougBTX
-
Nov 15, 2004, 09:36 #149
- Join Date
- Oct 2001
- Posts
- 2,686
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
People, there have been some comments here that are close to (or maybe over) the line. Negative comments and characteristics about other members are not tolerated at SitePoint Forums.
Here is quote from the guidelines that should be well known to all of youDON'T ATTACK EACH OTHER
Don't attack others. Personal attacks on others will not be tolerated. Challenge others' points of view and opinions, but do so respectfully and thoughtfully ... without insult and personal attack.
-
Nov 15, 2004, 09:41 #150
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Helge
Bookmarks