Your definition of flexibility must be different from mine. My framework contains a series of pre-written page controllers which can be used with ANY table class. I can create a brand new database table and instantly use any of these page controllers without having to write any custom code. Each table class can be reused by any page controller. Is that flexible or what?
A feature of the 3 Tier Architecture is that you can replace any tier without having to rewrite any of the other tiers. Thus it is possible to create your own presentation layer which does not have the overhead of XML and XSLT. In order to access a different DBMS all you have to do is replace the data access object. Is that flexible or what?
You may think that my code is inflexible because it cannot be used outside of my framework, but then you would be missing the point of my framework. It was designed to build web-based database applications which require a Role Based Access Control (RBAC) system, which options for Audit logging and activity-based Workflow. The data dictionary and library of transaction patterns means that new transactions can be built very quickly without the need to write large amounts of code, or even any code at all. The only extra code that is necessary is that which is required to implement the business rules.
It does what it was designed to do very well. The fact that it doesn’t do what it was not designed to do is therefore irrelevant.
Our definitions of flexibility are the same, but I’m talking about the arghitecture, you’re talking about the functionality of your framework. Those are different things, as I stated earlier.
Right. So you can replace a class from one tier with another. Agreed, that is flexible. Now change behavior of one of your “core classes” just slightly and see what happens.
I actually do get that, and most of the classes I write are project specific just the same as yours. That’s not what I mean by being able to replace a class though.
I didn’t question that, but this is irrelevant to the discussion on whether or not to use design patterns. The outcome of an application that uses design patterns is not different than the outcome of an application that doesn’t. I’m not criticizing (and can’t criticize) the functionality of your framework, I’m questioning the overall design of it. Don’t mix those up, or this will be a very tiring discussion I think.
How can the fact that your design is weird be irrelevant to the debate on whether or not to design patterns? The fact that it does what it should do is irrelevant to the discussion, unless your software metrics are binary (it works). In your case, they seem to be, as I’ve previously stated. That’s okay, but don’t blame people for having other (higher?) software metrics or expectations of code quality.
“It works” is not the way that I like to judge software. “It works, I can understand it easily, I can change it easily if the client wants me to, I can reuse the code I’ve already written without automatically reusing that whole component and I can change components without rippling changes throughout”. That’s a way I like to judge software.
Haha, I suddenly remember why I didn’t want to reply to this topic. Procedural and object oriented are different things, as most people will tell you. Judging by your code, you don’t really get that objects are most useful when they incorporate behavior and that they are less useful if they are nothing more than bags of data and procedures to act on that data. They have state, they have behavior, and they are most certainly more than just a convenient way to organize your functions.
You probably don’t want to believe me, and that’s okay if your current way of working suits you, but I don’t think you’re someone who will listen to arguments or want to be convinced, so I kind of think talking about design patterns will be rather useless. I hope someone else can still get useful information from this topic though.
I’ve recently seen what happens when a programmer takes a method, keeps on typing, doesn’t improve his code on the way, repeats code all over the place and says that it’s not necessary to break it apart and create readable code, all because he wants do everything opposite of what others consider best practice, without thinking about the arguments made for that best practice.
It’s not wrong to question best practices, but do you really think it’s wise to kick them every chance you get without even considering the arguments made?
My framework is a particular implementation of that architecture, so how is that architecture inflexible?
If I change a controller which is shared by 100 tasks, then the behaviour of those 100 tasks will change. If I change the abstract table class which is inherited by 100 table classes, then the behaviour of those 100 table classes will change. So what? This is as expected - if I change the code in a central library then all references to that library will automatically have access to that change as well. That is what having shared code is all about.
So what did you mean? My classes aren’t project specfic, they are table specific. So if I have a page controller which does something to table A and want the same thing done to table B then I simply tell that page controller to operate on table B.
So if there is no dfference between using design patterns and NOT using design patterns, then there is no compelling reason to use them?
What parts of my design are questionable? Is it not a valid implementation of the 3 Tier Architecture and the Model-View-Controller, or even the Singleton?
You said that my code was tightly coupled, which therefore made it less flexible. I’m saying that it is NOT inflexible, and the degree of reusabilty points to low levels of coupling.
So do I, but I don’t need to follow design patterns with religious fervour in order to achieve that.
Then most people would be wrong. A method is nothing more than a procedural function wrapped in a class. There are no differences between the code that goes into a function and the code that goes into a method.
But I DO get it that objects are useful, which is the only reason tat I use them, and they ARE just a convenient way to organise functions. Just take all the functions and data concerned with a particular entity and you have a class, from which you can instantiate objects. That’s called “encapsulation”. Do not say that “state” and “behaviour” are different from “data” and “functions” because they are not.
I will listen to any arguments both FOR or AGAINST design patterns, but you have yet to convince me that they actually supply any discerable benefits.
My remark was against splitting a large method into smaller chunks just because someone has an arbitrary limit on the size of each chunk. I most certainly was not talking about sloppy code or repeated code.
The trouble is that different people have a totally different idea of what “best practices” actually means. What’s best for you may not be best for me, and vice versa. I work best when I don’t bog myself down in design patterns.
If you don’t read anything I write, why should I invest time in typing replies? Listen, if I write something, you don’t read it and come back stating that I have said something that goes completely against what I really wrote, there is no point in continuing this topic. So, sorry, I hereby rest my case.
No, design patterns are not supposed to provide reusable code. Design patterns are more abstract than code. If you want to reuse your specific implementation, by all means, but there are many ways to implement a single pattern. You may not like one pattern or another, but you’re probably implementing several of them already, whether you’re aware of them or not.
Any productivity gains would come from using common patterns instead of trying to discover them on your own. If you’ve got years of development experience you’ve probably discovered a good many already, but those of us who haven’t been developing that long can still stand to benefit from the common solutions others have come across in the past.
You may not like one pattern or another, but you’re probably implementing several of them already, whether you’re aware of them or not.
He’s very aware (look at Radicore docs, etc) which is why this conversation bewilders me. His code might be more tighly coupled than some OO purists would like, and it may not follow every OO best practice, but it definetely implements design patterns.
I`m confused as to why he would even ask this (other than to start something of a flame war) when he so clearly utilizes patterns knowledge, both existing and his own.
All design questions aside, Radicore is quite an impressive peice of software and if it meets his requirements and he doesnt mind bending fragile software into client solutions, does it really matter how its designed.
It does, and Tony knows that. Somehow he picked up on the idea that design patterns are bad, because “they are not reusable”, and now he’s arguing that he doesn’t use them. For what it’s worth; the reason I said I think his framework is not as reusable as it could be is that I think it might be hard to change, not out of purism.
You and I both, Alex. There’s no point in arguing design patterns if you see the gain they add and if you actually use them in your software. Unless of course you want to start a flam… ehr, discussion.
Agreed, the functionality of the software looks really good. It seems as if you can do stuff much faster than you normally would “by hand”. Like I said, there’s nothing wrong with that, even better, I think it looks really good. But if you start arguing design patterns, claiming your software is composed of reusable code and no design patterns, then the architecture does matter indeed.
When I say I don’t “use” design patterns it means that I don’t read about desgn patterns and then attempt to implement them. I simply design and implement solutions based on my decades of experience. I certainly don’t use the vocabulary of design patterns when I talk to other developers because that leads to unproductive arguments. The same pattern can have different names depending on which patten “bible” you read, so whch name is “correct”. The same problem can be solved with different patterns, so which combination is “correct”. A pattern can have different implementations, so which implementation is “correct”.
I do not see any obvious benefits with using design patterns, so I do not use them. I get much more mileage out of transaction patterns.
Arguing that my framework “might not” be reusable because it “might” be hard to change is a pretty flimsy argument.
My framework has a large collection of pre-built components - page controllers, XSL style sheets, data access objects - which can be accessed (and therefore re-used) by any new transaction that you care to build. The proof of the pudding is that you can import a database table schema, then generate the user transactions which maintain the contents of that table, in a matter of minutes (not hours or even DAYS that I have seen with other frameworks) without writing a single line of code. No HTML, no SQL, no PHP. Now THAT is re-usability.
Saying that it “may” be hard to change is also a pointless argument. Why should I need to change it if it works? Why should I need to change it to satisfy someone else’s idea of “purism”?
Your definition of coupling seems a bit iffy to me. Tight coupling leads to low reusability while loose coupling leads to high reusability. My framework contains a huge number of reusable components - high reusability - therefore it must veer towards the low end of the coupling scale, not the high end.
My framework was designed to build solutions for paying customers, not to satisfy OO purists, so in that respect it is a success.
…many of which are design patterns. “A rose by any other name…”
Both, probably. The only reason people try to name these patterns is to have a way to refer to them. It’s much easier to remember “Identity Map” than it is to remember “Fowler’s Pattern #195”, and it’s much easier to communicate which pattern you mean by using that name.
I can do the same thing even faster with PHPMyAdmin. I don’t have to import or generate a thing. I would never put that in front of my clients and say “here’s your site”, though.
It works for your purposes, it does not work for mine. I could not use RADICORE out of the box to create websites for my clients. I would have to make a lot of changes, both because RADICORE is not really a web application framework, and because my requirements are ever changing to keep up with client demands. You say your code is reusable, but what that really means is you can reuse it. However, I’m not impressed until you can show me how I can reuse your code to cut down on my development time.
But what happens if I don’t use Fowlers’s book as my pattern bible?
[quote=“allspiritseve,post:51,topic:46106”]
I can do the same thing even faster with PHPMyAdmin. I don’t have to import or generate a thing. I would never put that in front of my clients and say “here’s your site”, though.[/QUOTE]
But can you customise the screens? Add Role Based Access Control, Audit Logging and Workflow functionality? Can you add business rules? How about multi-lingual capabilities?
That is because Radicore is NOT for building common-or-garden web sites, it is for building back office applications which administer the contents of the database which is used by the front office web site. A web site may allow visitors to browse your product catalog and place orders, but it is the back office application which is used to process those orders - stuff like order approval, picking from inventory, shipping, invoicing, inventory management, etc.
Could you build an entire ERP application with your framework? I can (and have) with mine.
Then you will probably have a harder time communicating with your peers. I’m not saying Fowler is the single authority on patterns, but I have found PoEAA incredibly useful as a baseline of communication among others on this forum.
I didn’t meant to imply that your framework has the exact same feature set as PHPMyAdmin. My point was that rapid application development isn’t the only merit on which you can judge a framework.
I completely understand-- RADICORE is built with a specific purpose. However, you come in here and argue that it is unequivocally reusable and flexble, but that argument hinges on the context. Most of us are looking at your code from the context of a web application framework a la Rails or Zend Framework. So you shouldn’t be surprised when you get dissenting opinions about how reusable or flexible your code is.
Then design patterns are TOO abstract for me. They are too wishy-washy, too airy-fairy, too much vapour-ware and not enough substance.
Just because you may see a pattern in my code AFTER it has been written does not mean that I had that particular pattern in mind BEFORE I wrote that piece of code. I do not write code around your preferred library of patterns, I simply design and write code without having to refer to any pattern books.
Any productivity gains from using design patterns would be extremely difficult to measure if there is no pre-written code that you can reuse. It is the difference between a “good” design and a “bad” design. We all know that a “good” design is better, but how do you measure “better”? We all know that structured code is better than unstructured code, but how do you measure “better”? We all know that a normalised database is better than an un-normalised database, but how do you measure “better”?
People keep telling me that using design patterns is better than not using desgn patterns, but how do you measure “better”?
My framework is flexible because it can be used to build ANY back office administrative application which uses a relational database. Anything which does not fall within this description (such as a web site) is therefore ineligible.
I have built an entire ERP application using it. In the Radicore download there is a prototype application which deals with Classroom Scheduling, and another Survey application. I have heard other people argue that each type of application needs its own framework which has been tailored specifically for that application. I totally disagree. I use a general purpose framework which can be used with ANY application, and I have been writing such frameworks since 1985.
That doesn’t change the fact that the same design patterns often are referred to by several names. And a single design pattern quite often means different things to different people (especially if it’s something generic, like MVC). Of course you can claim that your naming and understanding is the correct one, but even if it’s true, it doesn’t change the value of the patterns in communication.
The amount of questions and back-and-forth discussions about patterns on this forum actually shows to me that they are not very useful in communication.
I also agree that in many cases design patterns are simply “smart” names for rather obvious things. A normal programmer should not need to read a book about them to use them. (E.g. registry.)
I also agree that in many cases design patterns are simply “smart” names for rather obvious things. A normal programmer should not need to read a book about them to use them. (E.g. registry.)
I think your definition of a normal programmer might be a bit high there. My observation of people in general is they are very keen on monkey see monkey do, developers are no different. I would like it if normal programmers were at the level you think without a few years experience, good reading, good peers and some degree of obsessive anal tendancies. Employers would like it as well so they could pay less to get quality.
This debate has not been about patterns for a long time. Just what defines reusable code, damage caused by architecture astronauts etc… The word pattern is just being used as a rag doll to be tossed around in different areas of topic to prove some point.
That’s fair. I find them to be the right amount of abstraction, as they give me some structure without forcing me into a specific implementation. Personal preference.
I don’t think that matters-- the fact that they show up in your code shows the value. I think there’s at least two ways of arriving at the best solution to a problem: trial and error though gradual refactoring (as you have done in your 25 years of development) or looking at the experts and learning from their mistakes. If I know 4 other developers who have been coding for 25 years, and all 5 of you have arrived at a common solution, I think it’s fair to say that common solution has value. However, what is debatable is whether it is more advantageous to “learn from the greats” or learn from trial and error.
I’m not sure how to measure better-- it’s probably different for every developer. I would argue that there is value in design patterns, but I have no way of proving that everyone can benefit from using them (and it’s probably not something everyone can benefit from).
Well, sure. However, I think if there were no Gang of Four, Fowler, etc. books, there would be even more names and it would be even more confusing. That is why I like PoEAA so much: it’s a baseline of communication and allows me to have discussions with other people that are grounded in a standard.