This question could apply to all languages and frameworks but I'm looking for something a bit more 'cocoa specific'. I come from a Java background and I've noticed that learning objective-c is a lot more than just syntax, it's almost a completely different way of thinking.
What I've been having the most trouble with, must be the way one has to organise your classes. Sure all basic OOP(Object Oriented Programming) rules apply, and using MVC patterns where you can is recommended. But with me being used to Java I just need to set a few things straight and make sure I've got the right idea:
So for the sake of simplicity let just focus on one part of an app - Logging a user in. You'd have your .xib file for the UI (called Login.xib), you'd have your class that handles your data (connecting to a web service, called LoginModel.m) and you'd have your controller that acts as the middle man between your front-end and data (Called LoginController.m).
Is this is a pretty good example of applying MVC to a Cocoa app? And if it is, does that mean that you'd have 6 files created for this (since you have header files and implementation files). 6 files just to handle something simple as logging a user in. You can imagine how many you'd end up with for an entire app, even the most simplest of ones...
So my question is - Am I doing something wrong? Do I have the wrong idea? Or is the idea of too many files and too long method names just something I need to get used to since my brain is still working in 'Java Mode'?
Your ideas on how to handle that outlined above are fully correct. There is nothing bad about having a lot of files in the project. It does help a lot when you want to reuse code or if for example login details change and you don't want to edit multiple code locations.
Nevertheless, you may combine in such simple cases model class and controller class, especially if your model data can for example be stored in an NSDictionary and such. Only if you have complex model objects, that will run a lot of their own code, it will be better to separate them out.
Variable and method names can't be too long ;) always use a good name that especially describes the functionality or task. You usually don't have to type them often, but Xcode autocomplete will deal with that easily.
Related
I'm quite new to Prism. I'm studying QuickStarts shipped with it as well as other examples on the net. Almost all of them make modules aware of what region their view(s) get dropped into. Typically, the method Initalize of a module has a line like the the following.
RegionManager.Regions["LeftRegion"].Add(fundView);
I feel quite uncomfortable with that. There's a similar discussion but I think that it should be the responsibility of the shell component to define such mapping. However, I cannot find any example of such approach and I'm not sure whether the bootstrapper is the right place to put such mapping in.
Is this approach completely wrong?
Nothing is completely wrong. But it makes no sense to have the shell/bootstrapper (that by design doesn't know anything about the application it will host) knows what view goes into which region.
Consider an application that can be extended by simply adding modules into a given folder. When you follow the approach that the module knows where it's views want to reside (the mapping is done in Initialize()), this is no problem. I designed my first Prism application that way.
But if your mapping is done in your shell you always have to update your shell (which is part of the base application, not any module) when you want to add another module. This runs contrary to the loosely coupling paradigm. Besides that you have to create one base application for every module constellation. And there are (2^number of modules) permutations you have to cover. That results in loosing your flexibility you gained by using Prism.
I'm working on a joomla component that includes building a schedule. On any given day it needs to look at a set of rules (day of the week, date of the year, type of event) and return all of the possible start times. It would make sense to have a class that calculates these things, but I'm not sure it fits in the model or controller (and certainly not view) categories. Am I supposed to create a com_myproject/lib (or similar name) and have joomla auto-load the classes?
I'm new to joomla and started with the framework/project provided at http://docs.joomla.org/Building_Joomla_Extensions_with_Apache_Ant.
You should create a helper class. Have a look here for an example, albeit it is for a module, but the same concept applies.
You might want to start off with Developing a Model-View-Controller Component - Part 1 tutorial and work your way through that by hand. Using Apache Ant to learn how write an extension is like taking a canon to shoot fish in the barrel. It can be done but probably not the best way of doing it.
The Joomla! MVC pattern is very peculiar and difficult to understand. I don't quite understand it myself. I was advised on the developer email list to look at how other components are put together. Guess what? All the other developers do it differently, with some of the bigger components looking like spaghetti code in their organization.
The bulk of your component code should be in the controller, either as part of the controller class or a separate class file that's imported in. You don't need a separate library directory unless you're working on a big component with multiple class files. This Joomla! thread might be applicable.
I have another programmer who I'm trying to explain why it is that a UI component should not also be a data-structure.
For instance say that you get a data-structure that contains a record-set from the "database", and you wish to display that record-set in a UI component within your application.
According to this programmer (who will remain nameless, he's young and I'm teaching him...), we should subclass the data-structure into a class that will draw the UI component within our application!!!!!!
And thus according to this logic, the record-set should manage the drawing of the UI.
******Head Desk*****
I know that asking a record-set to draw itself is wrong, because, if you wish to render the same data-structure on more than one type of component on your UI, you are going to have a real mess on your hands; you'll need to extend yet another class for each and every UI component that you render from the base-class of your record-set;
I am well aware of the "cleanliness" of the of the MVC pattern (and by that what I really mean is you don't confuse your data (the Model) with your UI (the view) or the actions that take place on the data (the Controller more or less...okay not really the API should really handle that...and the Controller should just make as few calls to it as it can, telling it which view to render)) But it's certainly alot cleaner than using data-structures to render UI components!
Is there any other advice I could send his way other than the example above? I understand that when you first learn OOP you go through "a stage" where you where just want to extend everything.
Followed by a stage when you think that Design Patterns are the solution every single problem...which isn't entirely correct either...thanks Jeff.
Is there a way that I can gently nudge this kid in the right direction? Do you have any more examples that might help explain my point to him?
Have you heard of Martin Fowler?
Separating User Interface
Code
Anyway, if he wants to go further in that direction of adding render methods to his data controls, have him look at "loose coupling". It's okay to create some generic type of interface that gets him halfway there, but the UI component should take it the rest of the way.
This boils down to functional vs. non-functional responsibilities. What the data structure does and how it's visualized are two completely separate things -- essentially the root of the MVC pattern.
There's also a notion of circular dependencies here. Since the UI must know about the data structures, if you allow the data structures to then depend on the UI, you've got yourself a nice little ball of mud.
Generally on the point of decoupling:
Not only can there be different components of the UI rendering the same data structure. You may even have completely different UIs (Web, Desktop Application, ...) Now of course, you could subclass Person with WebPerson and DesktopPerson (this already sounds wrong, doesn't it? The naming is simply not about the kind of Person - it's about something else).
Each UI could work on different kinds of Persons, e.g. Teacher and Student. So we get WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher and DesktopStudent.
Now let's say, WebPerson defines the method "drawAddressFields()" to draw a web version of the address fields. But since WebTeacher has to derive from Teacher to use the additional data field "salary" (and let's assume single inheritance), it must implement "drawAddressFields()" once again!
So maybe the argument of "this will cause much more work" will help to create some motivation :-)
BTW, it will automatically lead to creating some delegate that implements the code of drawAddressField(), which will then evolve to creating a component that does the drawing separately from the data structure.
I am writing a GUI based application where I read a string of values from serial port every few seconds and I need to display most of the values in some type graphical indicator(I was thinking of QprogressBar maybe) that displays the range and the value. Some of the other data that I am parsing from the string are the date and fault codes. Also, the data is hierarchical.
I wanted to use the model/view architecture of Qt because I have been interested in MVC stuff for a while but have never quite wrapped my brain around how to implement it very well.
As of now, I have subclassed QAbstractItemModel and in the model I read the serial port and wrap the items parsed from the string in a Tree data structure. I can view all of the data in a QtreeView with no issues.
I have also began to subclass QAbstractItemView to build my custom view with all of the Graphical Indicators and such. This is where I am getting stuck. It seems to me that in order for me to design a view that knows how to display my custom model the view needs to know exactly how all of the data in the model is organized. Doesn't that defeat the purpose of Model/View? The QTreeView I tested the model with is basically just displaying the model as it is setup in the Tree structure but I don't want to do that because the data is not all of the same type. Is the type of data or the way you would like to present it to the user a determining factor in whether or not you should use this architecture? I always assumed it was just always better to design in an MVC style.
It seems to me like it might have been better to just subclass QWidget and then read in from the serial port and update all of subwidgets(graphical indicators, labels, etc...) from the subclass. Essentially, do everything in one class.
Does anybody understand this issue that can explain to me either what I am missing or why I shouldn't be doing it this way. As of now I am a little confused.
Thanks so much for any help!
** ** - Is this a situation where Qt Model/View architecture is not useful?
I"m going to say not necessarily - end edit
I'm not sure I fully understand your question, but let me try.
First, let's talk about MVC display pattern. This pattern is all about breaking the program into separate (and hopefully testable) sections that have their own areas of concerns.
The model is data structures that describe your data. I'm sure that there is some statistical data is also present. It is important that the model not know anything about how the data is going to be displayed to the user.
The View is how information is presented to user. It is not suppose to care about how the data is presented for displaying. It is important for this layer to be unaware of how the model gets the data for display.
The control logic is the "glue" to connects the first two items together. This is the layer that holds all the "messy" stuff to make to good user experience. EDIT - Most of what QT calls a "view item" I would probably put in the controller layer.
But if you do this, then the model and controller layers become very testable.
With that being said, many of your points are not really related to MVC pattern. You seem to be discussing what is the optimum way to display the data. This is always a problem. And without seeing your app, I'm not really going to try to tell you what is going to look good.
But by following good MVC pattern design, you can make pretty significant revision to the display without effecting the underling code.
This being said, I'm dealing with this exact issue right now and this pattern is working well form me. If you go to codeplex.com and search for mvvm (model-view-viewmodel, term used in WPF), you will see a number of projects that use it that you can use to get more information.
If this is not enough, let me know and I may be able to give you a better answer.
I just read a blog post that explains MVC with a banking analogy. I have a few months of experience with web application development with an MVC framework (CakePHP), so I get the basics, but I began to see a theme that made me think I'm taking a flawed approach to where I put my logic:
Fat models, skinny controllers
Keep as much business logic in the models as possible
In my app, models are anorexic and controllers are obese. I have all business logic in the controllers and nothing besides associations and validation rules in the models.
Scanning through my controllers, I can now identify a lot of logic that should probably go in a model:
The app has lists, which contain items, and the items can be ranked. The sorting logic which puts the list in ranked order is in a controller.
Similarly, items (Item model) also have images (Image model). Each item may have a default image (designated by image_id in the items table). When an item is displayed with its images, the default image should appear first. I have the logic that does this in a controller.
When a list is displayed, related lists are displayed in the sidebar. The logic to determine which lists are related is in a controller.
Now to my questions:
With the examples I gave above, am I on the right track in thinking that those are instances of logic presently in a controller that belongs in a model?
What are some other areas of logic, common to web apps, that should go into models?
I'm sure identifying this problem and changing my design pattern is half the battle, but even if I decide to take those examples I gave above and try to move that logic to a model, I wouldn't know where to begin. Can anyone point me in the right direction by posting some code here, or linking to some good learning resources? CakePHP specific help would be great, but I'm sure anything MVC will suffice.
It's a bit tough to give you the "right" answers, since some of them deal with the specifics of the framework (regardless of the ones you are working with).
At least in terms of CakePHP:
Yes
Anything that deals with data or data manipulation should be in a model. In terms of CakePHP what about a simple find() method? ... If there is a chance that it will do something "special" (i.e. recall a specific set of 'condition'), which you might need elsewhere, that's a good excuse to wrap inside a model's method.
Unfortunately there is never an easy answer, and refactoring of the code is a natural process. Sometimes you just wake up an go: "holy macaroni... that should be in the model!" (well maybe you don't do that, but I have :))
I'm using at least these two 'tests' to check if my logic is in the right place:
1) If I write a unittest, is is easy to only create the one 'real' object to do the test on (= the object that you are using in production) and not include lots of others, except for maybe some value objects. Needing both an actual model object and an actual controller object to do a test could be a signal you need to move functionality.
2) Ask myself the question: what if I added another way to use these classes, would I need to duplicate functionality in a way that is nearly copy-paste? ... That's also probably a good reason to move that functionality.
also interesting: http://www.martinfowler.com/bliki/AnemicDomainModel.html