I am developing my system with helper classes and I see on several sources that say "Helper classes" are not recommended in object orientated programming.
If so, why are they considered bad?
How do they play in with the MVC framework of Codeigniter?
Thanks
The strength and weakness of the helpers is that they don't neatly fit into the MVC framework; they're more like glue than wood or steel framing. They can be convenient to use in several contexts and are well-suited for common, light tasks. If your helpers become more complex and start needing to interact with models and controllers, odds are you've got a questionable design that needs to be more carefully considered. Glue and duct tape may be useful, but you'll be hard-pressed to find a skyscraper made of them.
Related
I roughly know how to make a mvc uml class diagram en can find enough info/ examples on the internet. The only thing i cant find info about is if it makes a difference when you have a jacascript controller/model and a c# controller/model.
In general: no.
UML is technology independent. Most models don't assume the technology. MVC can also be applied to different programming languages.
You only need to be aware that there are some concepts that are not handled by particular languages. The only thing that comes to my mind here is multiinheritance. Just use interfaces instead of (eventual) multiinheritance and there'll be no problem.
I can also imagine that some details can be designed in different ways to achieve better performance, but you'd need to know both languages perfectly to be able to make such decisions.
So don't bother about specific language and your diagram will be fine.
Is it at all practical to implement an object model in functional style?
One problem that OOP seems to excel at is describing object models.
For instance, an HTML DOM is a complicated, stateful beast which interfaces directly with the UI and requires programmability from dynamic languages. OOP features tend to come in useful in a lot of ways:
Member access constraints make interfacing with untrusted code (e.g. javascript) safe
Accessor functions and properties make binding to the UI much more convenient
Not having to pass around the object model all the time makes methods a lot simpler.
The UI side of the story might be a bit moot if you're projecting the model via MVVM, but you're still constantly wrestling with state internally.
I'm working in F# for this project so I could easily resort to OOP, but I'm curious as to how far I can push it before it becomes impractical. Are there maybe design patterns or anything?
This is a bit philosophical to have a "correct" answer but okay I'll bite.
In my opinion the problem comes because you consider FP and OO to be juxtapose, they are not. FP and imperative programming are juxtaposed, i.e. using expressions versus using statements.
Part of the problem is that OO lacks a clear definition, well in my opinion anyway. To support this I'd point to Alan Kay who said “Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.”, yet most language we consider OO i.e. java/C# take more after C++ than smalltalk.
What OO C++/java/C# style does give us is a nice way to organize our code into models, create data contains add properties to them etc. Non of this is practically un-functional and can be used nice with functional programming.
As you point out a lot of C++/java/C# tend to be stateful, but they don’t have to be, both java and C# have fundamental types such as their string classes that are immutable. It’s true java and C# don’t make it easy to create immutable class but with a bit of effort you can do it.
Which brings us to where is immutable appropriates? In my designs usually start of by making everything immutable, since this makes getting things correct easier, and if I see this causing performance problems I start adding some mutability on the critical paths. The one place immutability is never going to work is GUI controls, which generally contain far too much state to be immutable. Having said that you can get quite a long way building GUI using a immutable “combinator” approach then is then interpreted by mutable gui controls. This is more or less what the WebSharper guy’s do: http://www.intellifactory.com/products/wsp/Home.aspx
Another great resource for the FP/OO debate is Brain’s “How does functional programming affect the structure of your code?” (which greatly influenced my thinking about FP/OO): http://lorgonblog.wordpress.com/2008/09/22/how-does-functional-programming-affect-the-structure-of-your-code/
I just found the MVC was initially proposed in 88 [here is the pdf file] but unfortunately ASP.NET just recently implement it.
Do you know which is the most used MVC design pattern in the our days frameworks? I'm curious to know how MVC has evolved during the times and which is the best approach(what make it a good approach)? For example: a) in some versions, views doesn't interact with models. b) model has to be bigger than controller. On short, which are the gold rules for a good MVC implementation even if a certain framework doesn't require it?
As far as MVC design patterns it's been in use for more than 20 years in a wide variety of various languages and frameworks.
It's either being used in or is the basis of the design patterns being used in a wide variety of applications.
The core of MVC has to do with separating your code so that things have a logical progression through your code and gives you a simple way to separate your code. I'm not sure I understand your question about wanting to know which is the most used MVC design pattern since it is the design pattern.
According to Wikipedia, it was first described in 1979, not '88. The paper you link to even has a reference at the end titled "Model View Controller" from 1987, which is a good hint that 1988 was not the first proposal. :-)
I don't think it's "unfortunate" so much as "inevitable" that big companies didn't get around to implementing it for decades. Big companies tend to move slowly.
Sorry, was there a question here?
I'm trying to build a very light re-usable framework for my games, rather than starting from scratch each time I start a game. I have a component driven architecture - e.g. Entity composes a Position component and a Health component and Ai component etc.
My big question is whether my model composes view components to allow for more than one view of the model, or whether to use a truer MVC where the model does not know about its views, and they are managed externally.
I have tried both methods but if anyone knows the pros and cons of each approach and which is the industry standard, it would be great to know.
depends on your audience, game devs, myself included aren't very used to the MVC model, although most know it, it's not as easy to keep it clean cut, because of development casualties (not any serious technical reasons). So from experience, I've seen dozens of game frameworks start as MVC, but only a pair were able to maintain it until the end. My theory is MVC adds too much complexity and little benefits for small throwaway games (with normally a few devs), and it's to hard to keep really cleanly separate most game objects into these layers for large/complex games. And since games have a release date, they many times sacrifice code clarity and reusability for performance and quick adhoc solutions (that will get rewritten if necessarry in the sequel (if there is one)).
However, with the caveat above, it's better to aim high, because if you succeed it's better :) and if you fail, well to bad. So you should probably try the MVC, but don't worry if it fails, profesional game devs have all failed at the task many times :)
I’d certainly vote for the model to know nothing about its views. Loose coupling is good: Simpler model code, easier testing, more choices.
I know this question might be outdated, but I need to reply on it.
Actually, I started programming a game in Lua (with LÖVE) and I started programming a MVC - Framework for it.
At first, to use MVC really depends on what you want.
I know my problems with game programming, when the program becomes bigger, and mostly the structure becoms too complex to maintain.
Next thing is, I know that I will change all the graphics when I find an artist who is willing to work for it. But until then, I'm gonna use my own dummy graphics.
I want the artist to feel free to do what ever he wants, without beeing dependend on any resolution or color restriction.
That means, I might have to change the whole (!) presentation code. Maybe even the way objects interact (collision detection, f.e.).
The game logic is captured in the models, so I can concentrate on that. And I think game logic is the most important part of making a game. Isn't it?
Hope you see my point.
But, if you have everything together: all the graphics, sounds, the whole thing; then you can code straight forward.
My MVC is a configuration-over-convention-ass, that slows down prototyping a bit.
BUT(!) iterations of development can be made much more easily. Testing, especially Unit-Tests are done much more faster.
I would say MVC turns you development-speed-curve (which is normally an anti-exponential curve) into an exponential curve. Slow at the beginning, but more and more fast at the end.
MVC works really well for games, at least for my games which are designed for cross-platform.
It really depends on how you implement it in order to get the benefit.
I'm looking for patterns that concern coding parts of a GUI. Not as global as MVC, that I'm quite familiar with, but patterns and good ideas and best practices concerning single controls and inputs.
Let say I want to make a control that display some objects that may overlap. Now if I click on an object, I need to find out what to do (Just finding the object I can do in several ways, such as an quad-tree and Z-order, thats not the problem). And also I might hold down a modifier key, or some object is active from the beginning, making the selection or whatever a bit more complicated. Should I have an object instance representing a screen object, handle the user-action when clicked, or a master class. etc.. What kind of patterns or solutions are there for problems like this?
I think to be honest you a better just boning up on your standard design patterns and applying them to the individual problems that you face in developing your UI.
While there are common UI "themes" (such as dealing with modifier keys) the actual implementation may vary widely.
I have O'Reilly's Head First Design Patterns and The Poster, which I have found invaluable!
Shameless Plug : These links are using my associates ID.
Object-Oriented Design and Patterns by Cay Horstmann has a chapter entitled "Patterns and GUI Programming". In that chapter, Horstmann touches on the following patterns:
Observer Layout Managers and the
Strategy Pattern Components,
Containers, and the Composite Pattern
Scroll Bars and the Decorator Pattern
I don't think the that benefit of design patterns come from trying to find a design pattern to fit a problem. You can however use some heuristics to help clean up your design in this quite a bit, like keeping the UI as decoupled as possible from the rest of the objects in your system.
There is a pattern that might help out in this case, the Observer Pattern.
I know you said not as global as MVC, but there are some variations on MVC - specifically HMVC and PAC - which I think can answer questions such as the ones you pose.
Other than that, try to write new code "in the spirit" of existing patterns even if you don't apply them directly.
perhaps you're looking for something like the 'MouseTrap' which I saw in some articles on codeproject (search for UI Platform)?
I also found this series very useful http://codebetter.com/jeremymiller/2007/07/26/the-build-your-own-cab-series-table-of-contents/ where you might have a look at embedded controllers etc.
Micha.
You are looking at a professional application programming. I searched for tips and tricks a long time, without success. Unfortunately you will not find anything useful, it is a complicated topic and only with many years of experience you will be able to understand how to write efficiently an application. For example, almost every program opens a file, extracts information, shows it in different forms, allow processing, saving, ... but nobody explains exactly what the good strategy is and so on. Further, if you are writing a big application, you need to look at some strategies to reduce your compilation time (otherwise you will wait hours at every compilation). Impls idioms in C++ help you for example. And then there is a lot more. For this reason software developers are well paid and there are so many jobs :-)