Page 2 of 3
Re: A single core class throughout a framework
Posted: Sat Jun 06, 2009 8:19 am
by Weirdan
arborint wrote:Had the project you were working on properly put the session data behind a clear interface then you could have perhaps coded a replacement to make it work (without needing changing their code).
Session data is behind clear interface, as clear as it may get. That is, however, is not my point. The mere availability of global point of access led to that interface being used where it should not have been.
arborint wrote:
That would also have forced them to abstract where the data was coming from.
No need to abstract it here, just pass the data in method's arguments =). This is how it was intended to be done and this is how it will be done when we finish rewriting those methods.
Re: A single core class throughout a framework
Posted: Sat Jun 06, 2009 12:02 pm
by Christopher
Weirdan wrote:Session data is behind clear interface, as clear as it may get. That is, however, is not my point. The mere availability of global point of access led to that interface being used where it should not have been.
No need to abstract it here, just pass the data in method's arguments =). This is how it was intended to be done and this is how it will be done when we finish rewriting those methods.
True, true, true.
Re: A single core class throughout a framework
Posted: Sat Jun 06, 2009 1:45 pm
by Benjamin
I see where you guys are coming from. My mindset is that the framework itself is a separate entity from the applications code base, so it wouldn't need to adhere to the same design constraints.
Re: A single core class throughout a framework
Posted: Sat Jun 06, 2009 2:37 pm
by Weirdan
astions wrote:My mindset is that the framework itself is a separate entity from the applications code base
But do you think it's atomic, indivisible and should always be used as a whole? If it's so, obviously any dependencies are permitted as long as they do not cross framework boundaries.
Arborint, I think both of our examples illustrate the same principle: dependency reduction. In your case there were two options: either your model could require the application to pass configured http client into it or it could require a certain file present in the filesystem and instantiate required http client itself. Second way obviously makes fewer assumptions about component environment, so it's less dependent on it. In my case data access methods could take data from session or require client code to pass the required data in method's arguments. Now, again, second way makes fewer assumptions about component environment so it's betterâ„¢.
Re: A single core class throughout a framework
Posted: Sat Jun 06, 2009 2:43 pm
by Christopher
I think your summary is one of the most practical paragraphs on good design I have read in a while.

Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 2:55 pm
by inghamn
Weirdan wrote:
Now, again, second way makes fewer assumptions about component environment so it's betterâ„¢
Just got back from vactaion, and can't resist kicking the bee's nest....but here goes...
Better is very subjective, and if you're shooting for quick development time, making those assumptions will save the developer tons of time if their idea matches your assumptions. This is the big benefit from opinionated software. Opinionated software will make those assumptions at the expense of some extra work down the road if the developer wants to start deviating from the assumptions.
If you're building a framework to make websites, you might assume one single database, instead of multiple ones. You might assume the output's going to be HTML. You might even assume the framework to expect a few core tables to exist in the database.
"Better" means more in line with the goals you set out for your framework project. Quick development time, simplicity, and flexibility are usually at odds with each other. To me, it seems the skeleton folks are shooting for 1. Flexibility
2. Simplicity
3. Development Time
I tend to shoot for those in the opposite order of importance, and tend to recommend things accordingly.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 3:59 pm
by inghamn
Be mindful of what you make globally available - globals are looked down upon for very good reasons. However, for some things having them globally available might save you a lot of extra code everywhere. Things like that fall into this category are cross-cutting concerns, like the database, user verification and permissions, and logging.
Not to say that Registries are not a sound design - they are! As are dependency injection, and other solutions to the cursed, evil globals. But try to always bear in mind the tradeoffs involved.
Strict vigilance may be an option. You *may* be able to avoid the nasty problems that globals bring through sheer self-control, or some very strict coding standards, or - if you're on a team - strict code reviews.
Just know that, as the size of the application goes up, the damage (to maintainability) that globals have the potential to cause increases very significantly.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 4:18 pm
by Christopher
inghamn wrote:"Better" means more in line with the goals you set out for your framework project. Quick development time, simplicity, and flexibility are usually at odds with each other. To me, it seems the skeleton folks are shooting for 1. Flexibility
2. Simplicity
3. Development Time
It is interesting to hear about what people thing are goals, since none formally exist. I think you may be right, but that is only the goal for the core. But there is additional goal to then provide wrappers around the core that are focused on development speed. The problems is that different "stacks" provide speed for different solutions (and using different styles) -- so there is core functionality and then there are packaged solutions to solve specific problems better/faster. What most single-programmer frameworks do is to jettison the flexibility stuff they don't currently think they need and provide packaged solutions for the areas that speed development of the problems that they actually work on.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 5:04 pm
by Eran
I was wondering whether to pitch in or not, as these kind of conversations usually leave no one convinced as it's up to personal preference. But here goes nothing:
First of all, static methods and singletons are not globals. Even globals are not globals, at least not what they are made out to be. The saying "Globals are evil" is too generalistic - yes, misuse of globals can be dangerous and counter-productive, however proper use of globals might be the only solution available to some design issues in procedural progamming.
Luckily, OOP has a better alternative - static methods and singletons. A singleton registry is not a global, though it can be accessed globally. A singleton registry usually has methods to return and store values - and those methods provide a buffer against accidental changes to registry values, as values are returned by value and are not the actual instance (unless you are storing objects in the registry).
The singleton registry purpose is to solve the common problem of having to share configuration settings and resources that are needed throughout the application. Often, those settings / resources have just one occurrence (for example, a database connection) so it's preferable to have exactly one registry to handle those settings / resources.
The passed registry instance has several problems in my opinion -
1. There could exist more than one of those registries.
2. Access to the registry is done through class methods and not globally. This means the interface of classes has to adapt to the existence of registries. If later in the development process a class doesn't need information from the registry anymore, its interface has to change (or leave a useless parameter in). This change will then have to propagate to classes instancing said class.
3. Similar to 2, if a class later has to have access to registry data, it's interface has to change (leading to similar propagation through class hierarchy).
4. The passed registry instance often carries specific component (configuration) data, leading to it dealing with too much responsibility. This is because it's already a part of the interface for many classes, developers tend to chunk other options to pass along with it in order to reduce method signature (less parameters).
Now, I'm not dismissing the passed registry instance completely, just saying it's my cup of tea. Also, a framework definitely has inner dependencies, otherwise it could not share code between components. The point is to have those dependencies loosely-coupled, as arborint showed in his example, so they can easily be replaced.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 5:29 pm
by allspiritseve
pytrin wrote:Luckily, OOP has a better alternative - static methods and singletons.
And registries, and dependency injection.
pytrin wrote:Also, a framework definitely has inner dependencies, otherwise it could not share code between components. The point is to have those dependencies loosely-coupled, as arborint showed in his example, so they can easily be replaced.
How do you replace a singleton registry? Let's say, for testing purposes.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 6:06 pm
by Eran
In my tests I change the configuration options stored in the registry via a test helper that most of my test cases extend. This way I can easily setup a test environment that simulates the production environment or differs from it (for example, different database settings). Why would you want to replace the registry? show my an instance where this is useful
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 6:21 pm
by Christopher
pytrin wrote:Now, I'm not dismissing the passed registry instance completely, just saying it's my cup of tea. Also, a framework definitely has inner dependencies, otherwise it could not share code between components. The point is to have those dependencies loosely-coupled, as arborint showed in his example, so they can easily be replaced.
I agree with your comments and about the suitability of both passed and static registries.
One thing not mentioned is that using static registries is a general solution. However, the general case is usually not what is being discussed when discussing Registries. Usually, this thread included, the subject is Action Controllers. One of the main goals of an Action Controller is to provide quick access to a bunch of useful functionality in one place. Action Controllers provide a very specific context within which your code runs. They allow your code to not have to know the details of the world outside the Action Controller. The question then turns to the design question of how much the class that dispatches the Action Controller knows about the Action Controller. If you allow it to be more tightly coupled then it can inject a lot of specific functionality; if you don't want that coupling the it needs a less coupled way to supply that functionality like a passed Registry.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 6:22 pm
by Christopher
pytrin wrote:Why would you want to replace the registry? show my an instance where this is useful
Sometimes I use a plain Registry, other times I use a Registry+Loader that has DI functionality.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 6:36 pm
by Eran
If you allow it to be more tightly coupled then it can inject a lot of specific functionality; if you don't want that coupling the it needs a less coupled way to supply that functionality like a passed Registry.
The only place that would be useful is that if you don't know which action controller you would be using (ie, the skeleton framework). Personally, I use only one type of action controller so that's never been a problem (as I said, this is much to personal preference). Still, to me the passed registries is too much of a compromise in this case and doesn't provide enough to make it worth it.
Sometimes I use a plain Registry, other times I use a Registry+Loader that has DI functionality.
Not sure how that answers my question - do you use both in the same application? don't you choose one and use it exclusively in each application? changing between those two types is a major design decision. It will never be just about replacing one with the other.
Re: A single core class throughout a framework
Posted: Tue Jun 09, 2009 6:46 pm
by Weirdan
inghamn wrote:If you're building a framework to make websites, you might assume one single database, instead of multiple ones. You might assume the output's going to be HTML.
We must be building very special website then, as none of the quoted assumptions holds true for us (we have multiple databases and quite often output json instead of html (sometimes pdf and xls)).