SitePoint Sponsor |
|
User Tag List
Results 226 to 250 of 274
-
Nov 17, 2004, 06:45 #226
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
Last edited by Tony Marston; Nov 17, 2004 at 10:51.
-
Nov 17, 2004, 06:53 #227
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by seratonin
-
Nov 17, 2004, 07:10 #228
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Brenden Vickery
-
Nov 17, 2004, 07:18 #229
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
What is the definition of too many classes/variables/functions? More than you need.
What is the definition of too few classes/variables/functions? Less than you need.
Each class has enough variables to achieve its purpose. Anything more would be too much. Anything less would be too few.
Each class has enough functions to achieve its purpose. Anything more would be too much. Anything less would be too few.
Sounds reasonable to me.Last edited by Tony Marston; Nov 17, 2004 at 10:48.
-
Nov 17, 2004, 07:32 #230
- Join Date
- Jun 2003
- Location
- Iowa, USA
- Posts
- 3,749
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
), but I think most of the objectors to your code feel that your choice of a "business entity" is too coarse grained, and thus attracts too much functionality to it.
Again this appears to be a definitional issue, where you are happy with your choices (related to the scope of the class) and others are free to disagree with them.
-
Nov 17, 2004, 07:42 #231
- Join Date
- Jan 2004
- Location
- Oslo, Norway
- Posts
- 894
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
But if you do it sensibly, you're likely to be able to extract some logical subunits of the large class. That could make the code more readable even if there is a little bit more of it.
More importantly in my experience, very large classes are practically a guarantee that there is duplication present, and the very size of the class makes it hard to find out what's duplicated. Breaking it down into smaller, more logical units will make it easier to spot duplication.Dagfinn Reiersøl
PHP in Action / Blog / Twitter
"Making the impossible possible, the possible easy,
and the easy elegant" -- Moshe Feldenkrais
-
Nov 17, 2004, 07:44 #232
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by DougBTX
Originally Posted by DougBTX
Each presentation component is 'small and simple' as it only performs a limited function. However, the business component has to cope with the demands of any and all presentation components which may access it, therefore it is more complex. 'More complex' is not necessarily the same as 'too complex'. Each business component contains just enough complexity to satisfy the demands of the various presentation components. If the business object contained more complexity than was required to fulfill its purposes then that would be 'too much'.Last edited by Tony Marston; Nov 17, 2004 at 11:50.
-
Nov 17, 2004, 09:33 #233
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
Originally Posted by http://en.wikipedia.org/wiki/Internet_troll
Last edited by Tony Marston; Nov 17, 2004 at 11:51.
-
Nov 17, 2004, 09:37 #234
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
-
Nov 17, 2004, 09:50 #235
- Join Date
- Oct 2004
- Location
- downtown
- Posts
- 145
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Simple.
-
Nov 17, 2004, 10:15 #236
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
In the example that was posted here, you have a whole series of methods with the naming patterns _cm_* (23 methods) and _dml_* (10 methods) on your Default_Table class (86 methods!). Those naming patterns look to me like smaller classes screaming to get out of a big ball of mud.
-
Nov 17, 2004, 10:26 #237
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
The remark "He had giants, I have pygmies" is not meant to imply to everyone else in the programming universe is a pygmy, just those with whom I have come into personal contact over the last decade or so. Let me attempt to explain the situation from my point of view.....
While working for a software house in the mid-1980s I designed and built a development infrastructure in COBOL for a project for which I was the project leader. This infrastructure impressed by fellow workers and my bosses so much that they made it the company standard, and from then on it was used in every project that the company undertook.
That software house switched from COBOL (a 3rd generation language) to UNIFACE (a 4th generation language) in the 1990s, and so I redeveloped my infrastructure in that new language. With this new infrastructure I could build components at an average speed of one per hour, with the simplest taking no more than 20 minutes.
I was then headhunted to join a new project which (supposedly) had need of someone with proven expertise with development infrastructures. Despite my track record in this area the project architects ignored eveything I had to say and attempted to build an infrastructure using all the concepts and theories which are constantly occurring in this thread. To cut a long story short it was a total disaster. They spent a total of 3 man-years creating an infrastucture, and when they attempted to build the first simple 'live' components it took 2 (two) weeks. That is 70 (seventy) hours against my 1 (one)! The customer did not like the effect that this would have on his budget and timescales, so he (quite rightly, in my view) cancelled the project immediately in order to contain the damage.
I then joined another company who (supposedly) had need of my skills to assist them in upgrading their 2-tier system to 3-tier, but the project never materialised. As I had no desire to work as a maintenance programmer on their outdated infrastructure which took an average of 7 hours (1 day) to build each component I left.
I joined another company which had developed their own 3-tier infrastructure, but it was ful of so many deficiencies that their development times were 10 hours (1.5 days) per component.
I have worked briefly for a few other nondescript companies since then, but their development infrastructures have all been outdated, slow and cumbersome.
I have strived since 1985 to produce development infrastructures which allow developers to achieve a high rate of productivity. Anybody whose rate is lower than mine is a pygmy. Anybody whose rate is higher than mine is a giant. So far I have met only pygmies. Now do you understand where I am coming from?
I have created a development infrastructure for PHP that has enabled me to achieve a higher rate of productivity than I could with any of my previous infrastructures. I have documented it. I have made the source code available on my website. What do I get in response? Verbal abuse.
Your methods are all wrong!
You wouldn't catch a REAL oo pragrammer doing it that way!
Your classes are too big!
You are not supposed to write classes that way!
You are not using the right design patterns!
You don't know what 'separation of concerns' means!
et cetera, et cetera, et cetera
-
Nov 17, 2004, 10:37 #238
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
The disadvantage to this is that it leaves other patterns for separating domain and presentation largely nameless (there is Presentation Abstraction Control) and outside the circle of wagons.
-
Nov 17, 2004, 10:37 #239
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by McGruff
I just love the way you broadcast my opinions to such a wide audience.
-
Nov 17, 2004, 10:41 #240
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
-
Nov 17, 2004, 10:47 #241
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Version0-00e
-
Nov 17, 2004, 10:49 #242
- Join Date
- Mar 2004
- Location
- netherlands
- Posts
- 104
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Designing according to the 'real' design practises, will give you less headache when discovering new problems and requirements in the future, plus giving good names and good roles makes your project documented by nature. Revisiting your code will be less painfull, and showing the code to others will not stress them out. These positive points will only be notionable after a longer period of using and changing the project. So, arguably, this method will only be better for a larger project.
Your way, trying extremely hard to accomplish things the simplest way possible, is not bad. At least, for some projects. Coding this way will hurt you on the longer period. That is, if your project needs to be maintained and changed more then once.
The usefulness of your development infrastructure will be rated by the fact which project they/you will be using it on.
Finally, your higher productivity rate may be better at first, but will get worser as time goes by in the projects lifetime.
The type of project defines the requirements. Tony's way has positive sides, too. As does the 'correct' way.
Just my opinion.
-
Nov 17, 2004, 10:56 #243
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
There, that was painless wasn't it?
Originally Posted by dagfinn
Last edited by Tony Marston; Nov 17, 2004 at 12:17.
-
Nov 17, 2004, 11:20 #244
- Join Date
- Dec 2003
- Location
- Arizona
- Posts
- 411
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
http://code.box.sk/newsread.php?newsid=198
And here is a way to access a node set from a PHP function:
http://slides.bitflux.ch/phpug2004_1/slide_37.html
JT
-
Nov 17, 2004, 11:34 #245
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by sweatje
In the original version of UNIFACE the components that we developed contained both presentation and business logic, with all data access controlled by the database driver, so it had a 2-tier architecture. In a later version which provided support for the 3-tier architecture we developed 'form' components which handled the presentation logic, and 'service' components which handled the business logic. Basically the 'form' components had screens while the 'service' components did not, and the 'form' components had to talk to 'service' components in order to carry out user requests.
Each of these 'service' components in the middle or business layer was initially created around a single 'entity' (database table), although it was possible to access more 'entities' (database tables) within the 'service' component. This allowed the physical implementation of an entity's structure to be hidden from the form component. It did not need to know that the data it was accessing was actually spread over several different tables.
I use the term 'business entity' instead of 'business object' as 'object' may be taken to mean 'something instantiated from a class' instead of just a 'thing'. If I describe each 'business entity' as a database table then I'm afraid that would resurrect this old argument.
If I describe 'customer', 'product' and 'invoice' as entities I actually mean database tables. If the 'customer' information is actually spread over several tables, such as 'address' or 'contact' then each of these would be a separate entity which would require their own OO class. I certainly would not have a single 'customer' class that would deal with every possible database table that was required to hold a customer's details. Even though each class in my business layer starts off as being concerned with a single entity (database table) I have the option to change the internals of any class so that it can access as many tables as is necessary to get the job done. Thus I can hide the physical structure of the database from the components in the presentation layer.
Does this clear it up? Or have I added to the confusion?
-
Nov 17, 2004, 11:40 #246
- Join Date
- Oct 2004
- Location
- downtown
- Posts
- 145
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
As I am supposed to be arrogant then isn't that supposed to be the case?
87 class methods does not make good OO Programming. Anybody who has ever developed with OOP to any extent will tell you that. But you just keep going and totally disregard this, with an unjustifyable comment of it being too complex.
You say you have had 20 years in the business? If so then you would already have the experience to know that a class wouldn't have that many methods. So what that you have developed any number of infastructures over the years? That doesn't mean that you've implemented best practices, nor took any notice of design and analysis at any level.
But you continue to bang your drum on how cool and great your infastructure is. I personally fear that your approaches give bad advice to younger less experienced developers further down the road.
You have some good methodologies sure but by no means is your infastructure, nor your attitude the only approach.
As I had no desire to work as a maintenance programmer on their outdated infrastructure which took an average of 7 hours (1 day) to build each component I left.
This is the problem at the end of the day, it's your attitude and it sucks.
-
Nov 17, 2004, 11:44 #247
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Regarding encapsulation versus visibility, i'll quote from Meilir Page-Jones' book "Fundamentals of object oriented design in UML," which i think is the best book on the subject.
Jones introduces a term called Connascence, which you can also interpret as interdependency:
Originally Posted by FOODU
Jones goes on to discuss properties of connascence (explicit, implicit, directional, nondirectional, static, dynamic) and then enumerates several varieties:
Connascence of name
Connascence of type or class
Connascence of convention
Connascence of algorithm
Connascence of position
Connascence of execution
Connascence of timing
Connascence of value
Connascence of identity
Connascence of timing
Connascence of value
Connascence of identity
suffice it to say that there are many ways for two software elements to be interdependent. (here is another taxonomy of dependency along a different axis.)
Jones defines a particular type of Connascence, which he calls Contranascence, or "Connascence of difference."
Originally Posted by FOODU
Originally Posted by FOODU
- Minimize overall connascence by breaking the system into encapsulated elements. This includes minimizing contranascence. Minimizing contranascence what limiting visibility does, through encapsulation and scoping.
- Minimize any remaining connascence that crosses encapsulation boundaries. (Coupling)
- Maximize the connascence within encapsulation boundaries. This is another way of saying that a class should do one thing or represent one abstration. (Cohesion)
One last quote:
Originally Posted by FOODU
Originally Posted by seratonin
By the principle of contranascence, even being visible can introduce a dependency of difference. There are changes you can no longer freely make.
-
Nov 17, 2004, 11:47 #248
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by dagfinn
Originally Posted by dagfinn
-
Nov 17, 2004, 11:58 #249
- Join Date
- Oct 2004
- Location
- Sutton, Surrey
- Posts
- 259
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Selkirk
You keep telling me that I should split this class into smaller classes, but until you provide me with working samples to prove your hypothesis I shall continue to disbelieve you.
-
Nov 17, 2004, 12:01 #250
- Join Date
- Nov 2002
- Posts
- 841
- Mentioned
- 0 Post(s)
- Tagged
- 0 Thread(s)
Originally Posted by Tony Marston
Bookmarks