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.
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 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.
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 8 years ago.
Improve this question
I created a web service using vb.net in IIS that selects data from database and returns a List of objects with the results.
Is it possible to read that list of objects with a program made in MAC OS X that interacts with the method of the IIS web service?
Another option is use text files, but would be more effective using objects
It's possible, but there is no out-of-the-box solution.
Your options are:
Take a look at Mono project. It's cross-platform .NET framework implementation. You can write program for MAC OS X here and it seems to be the simplest way to go. However I'm unaware of the compatibility between Mono and Microsoft's CLR so you have to check yourself.
You could also possibly run your original service under Mono in which case it would be very simple. The problem is Mono does not cover 100% of the whole .NET framework.
Introduce serialization on service side and deserialization on MAC OS side. For example if you are be able to serialize your objects to strings, you can simply deserialize them on any platform.
Theoretically you could implement your own Object deserializer directly from your existing service. But in practice it would be almost impossible. You would have to handle so many cases, cross-platform issues and much, much, much worse things. I mention this only for completeness of the list. DO NOT go this way.
Appendix:
You must realize, what your service actually sends. It actually sends just some sequence of bits. Computer must correctly parse them to reconstruct original objects. This is tightly related to what Object is in memory. It's memory image depends on the CLR implementation. Without equivalent CLR you won't be able to simply read Object from source CLR.
So your task is to ensure you are able to reconstruct the objects
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
With all the key value data stores out there I have started to create an abstraction layer so that a developer does not have to be tied in to a particular store. I propose to make libraries for:
Erlang
Ruby
Java
.NET
Does anyone have any tips on how I should go about designing this API?
Thanks
First off, and as a general rule for anytime you build "pluggable" abstraction layer, build it to support at least two real implementations to start. Don't build it for just one datastore and try to make it abstracted, because you'd overlook a details that won't plug into another implementation very well. By forcing it to use two seperate implementations, you'll get closer to something that is actually flexible, but you'll have to make further changes to support a third and fourth data store.
Second, don't bother, these things already exist. Microsoft has provided a ton of these for their technologies (ODBC, ADO, ADO.NET, etc), and I'm sure Ruby/Java/etc has several as well. I understand the desire to encapsulate the already existing technology, but the more data stores you need to support, the more complexity you need to build in, and the closer you'll get to ADO.NET (or similar technologies). Companies like MS have spent a ton of money and research on solving this exact problem, and that is what they came up with.
I would strongly recommend checking out Twitter's Storehaus project - this is a key-value store abstraction layer for the JVM and written in Scala, supporting (to date) Memcache, Redis, DynamoDB, MySQL, HBase, Elasticsearch and Kafka.
Storehaus's core module defines three traits:
A read-only ReadableStore with get, getAll and close
A write-only WritableStore with put, putAll and close
A read-write Store combining both
In the Ruby ecosystem, you should check out moneta, which again provides a unified interface to key/value stores. It has a lot more features than Storehaus.
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 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.