4 ms·
Somewhat pedantic, but just throwing this out there: cars, bikes, and boats are all forms of transportation which can turn. They should probably inherit the co
by drone 14y ago
Somewhat pedantic, but just throwing this out there: cars, bikes, and boats are all forms of transportation which can turn. They should probably inherit the concept of turning left, and then specify the exact meaning in their context.
Obviously, I don't say "turn your handlebars such that the left side is closer to your chest," or "rotate your steering wheel counter-clockwise," when I mean to tell someone to turn left at the next intersection. I might, however, tell a sailor to steer to port at the next buoy. =)
EDIT: forgot to say, fwiw, that I agree that such actions do not belong in the model. The things go in the model, and the only actions the model should support are those relative managing the data in the model, not interacting with the data... That is, after all, what the controller is for.
- alttab 14y agoIm having a time parsing what you mean. Are you saying a car should not turn left, and that a controller should turn the wheel left? Please clarify
- drone 14y ago... it was a roundabout way of explaining how right you were, or at least in my initial reading of it. I see thing which is called a Car, an instance of which is stored in the Model, which may contain other things, including other types of Transports. The user interacts with the View, instructing a left turn - the controller grabs the Car (why it grabs the Car, and not the Bike is undefined =), and tells it to turn left. None of the M, V, or C understand what a left turn is - but the controller knows that the Car can perform such a thing if instructed. The Controller knows it can tell the Car to turn, because the Car is descended from a Transport, and all Transports have a virtual method for turning. That last sentence was in my head and unfortunately took over my comment.
- alttab 14y agoAh I understand. Yes polymorphism in this case would hide the details, and the implementation for turning the car belongs inside of that object.
- einhverfr 14y agoI dunno about the last part. I think any logic inherently tied to the data should be in the model. The controller shouldn't have to worry about internals of the model any more than necessary. Here's an example. Suppose I create an i18n framework for handling numbers. I certainly am going to include in it a function for converting the number into the current user's localized format, and another one for converting the number from the current user's localized format. I will probably also have functions to convert to/from db formats and to/from arbitrary formats. Not all of these will be called by the controller (in most cases, just the ones to/from the user's localized format and maybe an arbitrary format on rare occasions). This way the controller script can just call something like $number->to_output; and get the localized string back. Other model objects can call $number->to_db and get a string suitable for entry into the db. Interestingly in LedgerSMB 1.4 where we have done this, the number of cases where the model calls number i18n functions are remarkably small. These are usually called in the model or in the view simply because the controller probably shouldn't have to worry about this, and the view gets to worry about display logic.
- drone 14y agoConverting the display format of data when requested by a view is exactly what a model is supposed to do. However, instructing a contained object to take some action at the user's request that is unrelated to display or management of contained objects is neither the responsibility of the view or the model, but specifically the task of the controller.
- einhverfr 14y agoOk, so let's go further. I want an email to be sent to me when the quantity on hand of a part gets below the re-order point. So now, I build a program that listens for notifications, and when it gets one, loads the data, erases the queue, and sends me an email. I build this so the app itself doesn't know this is required or is going on. Database triggers, queue tables listening scripts, and templates all are triggered when the db write takes place. Now, what we have here are arguably two MVC environments where the model behavior of one triggers a model change in another, which triggers a controller to run, calls some other model stuff, creates an email (via a view) and sends it. But this is the sort of action you are talking about, right? You think this violates separation of concerns?