Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
About six months ago I put on a full-stack developer hat at my job and started working on a tool comprised of a GUI and a database. The client has requested that the tool be written in Python, so I've been working with the company PyQt license to create the interface.
This is the first tool of this kind I've ever created and it's going quite well, but a question that keeps nagging at me as I subclass PyQt's various GUI elements is: "Where should I implement this?"
For example, one of the tool's functions involves giving a user a form to fill out (which is a subclassed GUI element) and then submitting the completed form to be stored in one of the database's tables -- pretty standard stuff. The user fills out the form and upon pressing the "submit" button, the form's fields are validated to ensure they adhere to certain constraints and then a stored procedure is called in the database to submit the form's data. Let's call that function submit().
Obviously there are a myriad of ways to structure the code but the 3 big ones I've been toying with are:
Implement submit() directly in the form's class body as one of its methods
Create functions outside the class and have the class itself call them
Create a "handler" class that receives the form's fields in a signal emitted upon clicking the "submit" button
My question is this: which of them, if any, is the "best" way to do this? When I say "best" I mean which is the most "OOP-ish" in terms of accepted conventions, as well as which of them would be easiest for the programmer who comes after me to read and maintain.
Thanks in advance :)
Think of the different parts of your application as systems, each with their own responsibility. For example, the UI system, the database system, and the system(s) in between that implement the business rules. In each system, have a different version of your business objects that matches the abstraction of the system; for example, a user entry form in the UI system, a user table in the database system, a user model in the business system.
Then, as per your option 3, establish communication between the different systems via messages and signals. You would have to decide on some sort of protocol for the data payload being passed around so that you do not leak abstraction between systems. Data transfer objects are a good way to do that, but you could also send bytes or some textual representation such as JSON.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
One question that I have long asked myself is in object oriented programming,how should data such as settings and properties be passed around in an object oriented manner?
For example, most programs have options, say you have an option to set the undo level. This must be obtained and then set to a new value. If these settings are saved in an xml file, that section of the application (the option dialog) still needs some kind of xml parser to load the data. In another scenario where you would instead have an object that represents getting and setting settings, each area that needs this would have global access to all settings and a pointer to it would need to be passed around.
In a scenario like Maya or 3DS Max where these use huge gui systems to set object properties, how is this done in a clean and OO manner? The widget, needs to be given the data from the 3D object, and needs to send information to this object. Should a dialog know anything about 3D objects? Probably not. So how is this usually done?
In another scenario, I might need to update a status bar when my frame gets a mousemove. Does that mean my frame should have a pointer to my status bar?
Any abstract examples or readings about this would be appreciated.
Thanks
In a previous job, we had several XML files for our various apps, and much of the configuration was similar, but varied depending on the environment and execution context. Much of this configuration was usernames and password for third party services. When a password would change, we'd have to scour through dozens of XML files and make the changes, then, re-deploy dozens of apps.
I migrated all of the XML configurations to objects using interfaces and a type hierarchy. The interfaces allowed me to code against a common configuration structure, and get compile time support as well as use dependency injection to resolve the run-time instances. The type hierarchy allowed me to define the non-changing configurations once, in a base class, and only override the actual values that differed.
This would be overkill, I think, for a small app, but was imperative in our case.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I want to build a solitaire game in C++ for my project.
Here's what I have come up with: Card class Properties/members: Suit,Rank,Color(All of these can be enums) Actions/Functions: Flip card, compare card, print card Rules Class: Would contain the rules of the game and also validate each user action/command to check if it is allowed. Commands Class: I am thinking this need not necessarily be a class. Could be an enum as well. A base class CardPile. Have more classes derived from CardPile such as DealPile, Temporary Pile, DestinationPile, TablePile. What I am not clear about is the relationships between classes.
Thanks!
You need a representation of a card which will hold the card's value and suit.
You will also need a data structure to represent a "stack" of cards.
From there, building the GUI shouldn't be that challenging. This is a very easy project, and you seem to have the right idea.
Consider, instead of doing a bunch of up-front design, focusing on creating things that work. What will your program need to do?
It'll need to shuffle, so design a way to represent 52 cards and shuffle them. It's pretty easy to implement, but it's a good starting point.
Then you'll need to lay out the cards. So come up with a way to lay out the cards and put the rest in the draw pile.
And so forth. Instead of analyzing objects, focus on behaviors. Create objects only as needed in order to support the behaviors of your program. That will help you avoid getting lost in the analysis and excess code and ensure that you have a program that actually does some useful things.
(What if you need to turn in your design before doing anything? Not a problem; do your thinking the way I've described above. The implementation will be left for later, but even just thinking out how routines like the above will work will be more valuable than designing a bunch of objects without knowing what you'll do with them.)
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
So if a user story is a something nebulous like:
As a sales rep, I would like to capture the contact information so that I can follow up later on.
I'm not even sure if that's a valid user story but I'm sure it's close enough.
Then there are details/tasks for implementing that user story.
And I'm sure "The sales rep should be able to tab from one textbox to another." is one of the requirements. How do we capture/track this? Is this part of the user story or is it something that's to be considered separately?
A user story captures the essence of a feature, not the details, a story is a support for the discussion.
So, to answer your question, details are transmitted orally during a discussion, because face to face discussion is the most effective communication media. If you feel the need, details can be captured as notes on the back of the card (if you are using cards) or... in a "notes" field if you are using an electronic tool. Actually, I usually use a "how to demo" field too to capture a high-level description of how this story will be demonstrated at the sprint demo and use very brief "notes" for any other info, clarifications, references to other sources of info, etc (credits to Henrik Kniberg's famous Index card generator). If find this very handy, especially when using executable specifications.
PS: your story is perfectly valid and its a good practice to include the benefits in your template ("As a role, I want action so that benefits").
User stories should be short statements in 1 to 3 sentences.
http://en.wikipedia.org/wiki/User_story
I want to be able to tab from one textbox to another is another user story.
You can track these things in a tool like www.rallydev.com, or just any type of task tracking tool (SharePoint, Excel even ... etc.).
Next thing you do is prioritize.
Just taking a rough stab...
As a sales rep,
I want all data entry and navigation to be accomplished using the keyboard
so that I don't have to take my hands off the keyboard
(and so that we comply with accessibility guidelines).
Or
As a business,
We want all our products to be fully usable using only keyboard input
So that we can sell to customers who require accessible software.
The first part belongs to a "business requirements" document (usually written by a business analyst). The first generations of this document are quite high level, but the final versions (several iterations later) are pretty detailed.
http://www.tdan.com/view-articles/6089
The second part (about tabbing) is part of another document - "UX spec" (shows all screens and describes user interaction). This one is usually written by a different person/team (Product or UX team).
http://uxdesign.com/ux-defined-2
http://www.uxmatters.com/mt/archives/2007/05/sharing-ownership-of-ux.php
Yes, that is problem we also have a lot. On the one hand, user stories need to be conscise, on the other hand all the nitty gritty details must be put somewhere.
We use XPlanner, and we solve this by putting the short description into the text body of the user story. Then we use XPlanners "notes" feature (arbitrary text or files that can be attached to a user story) for the details.
That way we can add as much information as necessary to a user story, without cluttering up the user story text itself. You can also refer to external documentation, if you don't want to have everything in XPlanner.
This approach works quite well for us.
Agree with others, that this is viable story, but capture the (derived) requirements may be better captured elsewhere.
Software Developers and Business types are familiar with different terminology some what may simple to understand by one (data structures) may mean nothing to another. The User Stories is a tool or a means by which business user can convey a message as a starting point which is expanded on (with tests, details, etc).
Oral Communication can be effective, but the effectiveness is dependent on the receivers ability to hear and comprehend the meaning of the message. This is where oral communication can fail. Different types of communication offerring more or less formal forms of communication. Vocal communication is an "informal form of communication" which risks the message being misheard, misinterpretted, and misunderstanding. Just like the game played as a child, where one child whispers a message to another child, who tells another, until all have heard it...When the last child tells the message to the group it usually has been misinterpreted then misinterpretted again, causing a degraded message.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In subsystem design, I sometimes see software designs that have one high-level class that has only one feature: It routes a call from a client using the class to another a certain class the client would like to use. However, it alone does not have any functionality. Take this scenario:
Say there are five classes in the bowling alley subsystem: An alley, a lane, a bowler, control desk, and a score. Anytime a client outside the subsystem wants any data to display to a user, it would communicate only to the control desk (the router) that would call any of the classes it holds to get the client's requested data (a score for example: Client calls control desk with getScore(), which calls a Lane's getScore(), which calls a Bowler's getScore()).
I understand this is a bad design decision, but I'd like to hear real-world examples with consequences you discovered of having this router class (Can also be known as a "middleman"). What issues did you run into as the system you were working on evolved? What arguments would you make to persuade software designers to avoid router classes?
I'd argue that in some designs a router is the preferred design pattern, such as in MVC frameworks to delegate handlers for URLs. In that situation it's really helpful because it provides a very clean separation between what the client "sees" and the actual logic behind it.
Anytime a client outside the subsystem wants any data to display to a user, it would communicate only to the control desk (the router) that would call any of the classes it holds to get the client's requested data
this sounds like the Facade pattern
As for the middleman, in the following example, wouldnt the Lane be the culprit?
a score for example: Client calls control desk with getScore(), which calls a Lane's getScore(), which calls a Bowler's getScore())
simplifying the interface to a subsystem for the benefit of clients outside the subsystem could be considered good design.
The Facade pattern, and the Mediator pattern perform similar tasks to what you are describing. Your use of the Middleman moniker implies the Mediator pattern over the Facade pattern, as a Middleman is responsible for negotiating between two entities with neither entity needing to know the specifics of how to communicate with the other.
You can use either of these patterns to reduce coupling for the client class, which needs to use the system the Mediator or Facade is masking. In the case of the Facade pattern, the intention is to provide a convenient way to interface a system of classes. For the Mediator pattern, the purpose is to abstract the steps required to perform a complex task from the client.
I don't know that routing method calls is always such a bad idea.
It seems that you'd just have the problem associated with any additional layer of abstraction - that the abstraction can break, or that it's one more thing that can potentially misbehave if there's a change made to something underlying.
I've never seen anything that called more than a few layers deep, but I just imagine that adding extra calls would make it more difficult to trace the path information takes, and make troubleshooting more difficult.
One potential problem, though, is if each layer implements its own error handling or retry process, making something that's insignificant at each level overwhelming as a whole. For example, if the Lane makes two attempts to check the bowler's score, and the desk makes 3 attempts to check the score, then a failure of the bowler to return a score will result in 6 queries being made. Add a 30 second timeout at the bowler, and you're suddenly waiting for 3 minutes for what should take 30 seconds.
OldNewThing had an article about an example of this in the Windows OS, and the problems it caused, but now I can't seem to find it.
I think that both ASP.NET MVC and MVP patterns utilize this type of concept where you end up with something simply handling the logic that is executed from one end to the other or on behalf of a lower layer to a higher layer. This certainly makes testing more easy to perform so that in and of itself is a MAJOR benefit. This type of pattern does create some manual or tedeious work in that you could click a button and have it do a task rather than click the button, have something intercept that click, then call into some service managing class that does some work. But on the front of keeping your code clean and readable the more separation there is often times the better.
If you are not a tester or could care less about patterns directly then think of it in another format. You have a link that takes a user to a page. This link is scattered across your site all over the place as the destination is very important or used a lot. The destination changes. This could be a find and replace operation...or you could insert a RedirectService (call it what you will) that when someone clicks a link takes change and directs the clicker to the right location. This allows the location to be defined once in one location and therefore changed once. Find and replace often times changes things that weren't meant too be changed!
No matter how you look at this...separation of concerns is a good think. The UI is one concern. The controller of activities is another concern. The activity itself is yet another concern!
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am trying to learn some programming related terms, and I often come over the word "handler". Can anyone please explain what it means and when to use it?
A handler is a routine/function/method which is specialized in a certain type of data or focused on certain special tasks.
Examples:
Event handler - Receives and digests events and signals from the
surrounding system (e.g. OS or GUI).
Memory handler - Performs certain special tasks on memory.
File input handler - A function receiving file input and performing
special tasks on the data, all depending on context of course.
Code that's associated with and triggered by the occurrence of a specific event, like an incoming message, a thrown exception, a signal sent to a process, a network I/O request completing, or a mouse click on a user interface element. It's a very generic term.
I think it's a very general term, without a 'hard' definition. The meaning is highly contextual, varies depending on the general code design.
For me, it usually means some code that is called from an inner core and is supposed to do some things and return. That 'inner' part can have several 'handlers' available, and chooses which one to call.
In some cases, you define some API to make those handlers mostly interchangeable, so the caller can pick one from a table and use the same code to call any of them. OOP helps a lot here.