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 5 years ago.
Improve this question
I have known enough about programming to get me in trouble for about 10 years now. I have no formal education, though I've read many books on the subject for various languages. The language I am primarily focused on now would be PHP, at least for the scale of things I am doing now.
I have used some OOP classes for a while, but never took the dive into understanding the principles behind the scenes. I am still not at the level I would like to be expression-wise, but my recent reading of the book The OOP Thought Process has left me wanting to advance my programming skills.
With motivation from the new concepts, I've started a new project. I've coded some re-usable classes that deal with user auth, user profiles, database interfacing, and some other stuff I use regularly on most projects.
Now having split my typical garbled spaghetti-bowl mess of code into somewhat organized files, I've been having some problems when it comes to making sure files are all included when they need to be, how to logically divide the scripts up into classes, and how segmented I should be making each class.
What I'm really asking for is advice or suggested reading that focuses not on specific functions and formats of code, but on the logical layout of projects that are larger than just a hobby project.
I want to learn how to do things properly, and while I am still learning in some areas, this is something that I have no clue about other than just being creative, and trial/error. Mostly error.
Thanks for any replies. This place is great.
I will try to express my experience from previous projects here, maybe they help you.
If you try to segment your project, try to find components that might be useful as themselves. If you write e.g. a database layer, think about what to do to make the database layer independent from the rest of your application (except utility classes and configuration). If you write a RichClient that accesses the database layer, try to put exactly the stuff you need in it which you would also need when accessing it from a Web layer. Now you have a component that would maybe even useful in a command line client.
Or if you want to see this from a lower level, split your application into small units, and don't let these units have circular dependencies!!! If two components have circular dependencies, they cannot be splitted and should really be a single component. I know, I broke this rule some times because you cannot hold it up always, but it is a good rule to get understanding of the building blocks of your app.
Another popular dividing rule of an application is the Model-View-Control Pattern (MVC), which states that the Model (the data classes), the Control (the logic of your program) and the View (The graphical user interface) should be splittet into distinct packages. While I adhere to this, I would divide my code like this. Within each package I have distinct model, view and control classes, but the model classes don't know anything about the control layer, and the control layer does not know anything about the GUI.
Since GUI development is always tedious, and therefore often the least tested part (at least in unit tests) of an application, splitting it from the control make writing the buisiness logic a lot easier. In fact, it lets you concentrate on what you have to do, which is getting work done, which you code in buisiness logic. If this part works, you can spend time writing a nice GUI for it. Of course will the GUI and ease of use often bring their own requirements to the control, but at least its loosely coupled.
In my current large project we have some bit components, which we now see as independent products, which get used by the really product. This makes testing and writing the independent component easier for the person in charge, and gives everyone a more stable component.
Just my 2¢.
Related
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 have a conceptual question and believe Stack Overflow may be a great place to ask it. Often in my reading and learning I hear conversation of "layers" - and loosely defined layers, at that, it seems. Too, a lot of software jargon is used in describing these layers (so, for an entry-level guy or gal (like me), they each become difficult to get a grasp of).
So far, I have heard tell of three (3) layers that interact with each other and that make a program "run":
Business Logic Layer (BLL) - Wikipedia's got a great introductory article to this/
Application Logic Layer - that which is responsible for enabling the business logic layer to interact with boundary technologies
Presentation Layer (the layer I just learned of, today).
Here's my question (and it may not be possible to answer): how many of these layer "types" exist and - briefly - what are they?
I also encourage posting resources via hyperlink that people can consult, particularly as these layers do seem to be so loosely defined.
In this particular case, the layers are essentially a generalization of the Model View Controller system architecture. Briefly, they are:
BLL: The 'guts' of the application, if you will. This is the logic that works on your own internal data types and does, as the name suggests, the 'business logic' that makes your application actually work. It should be as independent as possible from any particular implementation of how the user might interact with the business logic. For example, if you were building a Tic Tac Toe game, the BLL would be the rules engine that does the actual work of tracking people's moves, determining who wins, etc.
ALL: The 'interface' between the BLL and all of the stuff that feeds data into the BLL. This is going to be much more specific to a particular application of the BLL. For example, if your Tic Tac Toe engine had the ability to save out the results of games, the ALL might provide an interface to a database engine that stores the results. It would also be responsable for interfacing the BLL with whatever PL you chose to use (text based, a GUI, etc).
PL: This is the 'front end' of your application that the user interacts with. This could be built from a complicated framework like Qt, or something simple like a text interface. Either way, it's generally completely independent in terms of implementation from the application it's trying to expose. To continue the Tic Tac Toe analogy, you could build a relatively generic 3x3 grid with shapes and a message output that just happens, via the ALL, to wind up displaying a Tic Tac Toe game. Now in practice they're rarely that decoupled, but the point is that you should try and keep any actual logic out of the PL, such that you can change the implementation of the BLL or ALL without having to touch your PL code as long as the interfaces stay the same.
These layers are loosely defined because they're just generalizations used to make visualizing the design of complex systems easier to reason about and to naturally guide development towards proper compartmentalization of functionality for maximum code reuse and component swappability, as well as allowing for more easily performing formal Verification and Validation and other QA tasks. There are many, many ways you can split up software design into 'layers', but these three are the ones that are typically formally described in Soft Eng course material. So there isn't really any specific 'number of layers' that you can talk about. How segmented a particular design is really depends on that specific domain and the 'buzzwords' in the industry at the time. You will however almost always find something akin to these three layers, sometimes broken into a few smaller chunks.
It is strange to me that the three concepts you list should be called "layers". They may be three components of a software system but they don't appear to lie on top of each other except in a crude PowerPoint block diagram.
The idea of layering relates to levels of abstraction in code development where lower layers provide the components used to build higher layers. The OSI model is a paradigm example.
There can be any number of layers in a particular software system depending on how many levels of dependency exist. Perhaps there are only one or two layers within the immediate application being developed, though that application is likely to be dependent on a larger stack of assumed sub-structure.
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
I am new in web development, and read some wiki and discussions about MVC. However, the more I read, the more confusion I have about its design purpose.
I just want to know why is this design pattern invented? And what problem is it used to solve?
Thanks in advance.
The goal of the MVC paradigm is in essence to ensure a form of separation of code. The problem that often arise when developing code is that the code is written in a succession, where each part follows another and where each part is directly dependent upon what the other parts are doing.
When working with a large project, maintaining and further developing the code can quickly become an issue. You could therefore argue, in a simplified manner, that what the MVC paradigm tries to do is to ensure that you separate business logic (e.g. the code that performs) from the presentation logic (the code that shows the results). But those two parts need to communicate with each other, which is what the controller is responsible for.
This allows for a clear structure of code where the different parts are more decoupled, meaning less dependent upon each other.
The separation also means that you work in a much more modular way, where each part interacts with the others through an interface (some defined functions and variables that are used to call upon other parts) so that you can change the underlying functionality without having the change other parts of your code, as long as your interface remains the same.
So the problem it tries to solve is to avoid having a code base that is so entangled that you can't change or add anything without breaking the code, meaning you have to modify the code in all sorts of places beyond where you made your original changes.
To some degree it's a solution in search of a problem.
As a rather ancient programmer I'm well aware of the benefits of "separation of concerns", but (in my not-so-humble opinion) MVC doesn't do this very well, especially when implemented "cook-book" fashion. Very often it just leads to a proliferation of modules, with three separate modules for every function, and no common code or common theme to tie things together and accomplish the real goal: minimize complexity and maximize reliability/maintainability.
"Classical" MVC is especially inappropriate in your typical phone GUI app, where, eg, management of a database table may be intimately connected to management of a corresponding table view. Spreading the logic out among three different modules only makes things more complicated and harder to maintain.
What does often work well is to think about your data and understand what sorts of updates and queries will be required, then build a "wrapper" for the database (or whatever data storage you use), to "abstract" it and minimize the interactions between the DB and the rest of the system. But planning this is hard, and a significant amount of trial and error is often required -- definitely not cook-book.
Similarly you can sometimes abstract other areas, but abstracting, say, a GUI interface is often too difficult to be worthwhile -- don't just write "wrappers" to say you did it.
Keep in mind that the authors of databases, GUI systems, app flow control mechanisms, etc, have already put considerable effort (sometimes too much) into abstracting those interfaces, so your further "abstraction" is often little more than an extra layer of calls (especially if you take the cook-book approach).
Model view controller was created to separate concerns in code instead of crating a hodge podge all in a single blob. (Spaghetti code) the view code is merely presentation logic, the model is your objects representing your domain and the controller handle negotiating business logic and integrations to services on the backend.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The Model View Controller concept is expressed all over the place as an important thing to keep in mind when developing an application. But when developing applications, I struggle to distinguish whether or not I'm using the MVC model and whether or not that is hurting my application. Why is the MVC concept important in application development and how does it help developers make better programs?
Well, like doing many things in life, it always helpful to be well organized. Models, Views and Controllers are distinctly different pieces of code that helps to provide different functions to your overall project. Because of that, they are kept separate and organized.
Imagine if you were designing a program. You wouldn't put all your code into one function, would you? No, you would divide them up into separate smaller functions that solve very specific tasks. Likewise, as programmers, we're constantly looking for ways to separate and divide our large applications to smaller bits of pieces. One of these organization design patterns is MVC, where, the model (the data) exists in one section, the view (the UI) exist in one section, and the controller (logic) exists in another section.
What problems does this solve? Well, just as how having separated functions solve the problems of readability, modularity, and coupling, so does MVC. Say if you wanted to change a piece of code, you can tackle it in a smaller subset that is more or less isolated from the larger piece of code. This allows you to add, modify or remove code more effeciently and logically. It also helps in testing, since similar code is sectioned into groups, you may be able to have better coverage of your tests cases. Also very important is that you end up writing a lot less code.
Hope this helps.
Have you heard of "separation of concerns"? MVC, in simple terms, is an architecture that allows different parts of a system to be loosely coupled (or separated). Views are typically dumb and display data and take user actions. Models represent the data and domain logic in your system. And controllers liaise between the View and the Model, often controlling flow. There are loads of variants on the original Smalltalk MVC pattern and nowadays it seems like every framework is MVC.
The advantages are it makes your code less fragile, easier to understand and change and easier to unit test. All because it is separated into different parts.
A good example is that I recently changed job and started working on a new project in PHP (I come from .NET background). The learning curve was much easier because we use an MVC framework. Because I already knew the pattern, I knew where everything "was", as such, and how the system was put together.
http://en.wikipedia.org/wiki/Model–view–controller
https://gamedev.stackexchange.com/questions/5372/mvc-like-compartmentalization-in-games
That's a question you'll understand once you've experienced a few software development projects...
Most prominently, it separates code into logical areas. UI code is kept in the UI (View), business logic is kept in the Controller, and objects are kept in the Model. If you need to update the UI, create a different UI (such as web interface), create web services or what not, then you don't need to spend forever and a day dissecting a tangled mash of incomprehensible code. You can also get different member of a team to specialise in a certain area, such as the UI or model, and this can lead to more robust code or perhaps allow a junior developed to work on something less complicated than the whole picture.
Here's an old post from pre-MVC Framework days when I worked with the Microsoft Web Client Software Factory (based on MVC... or MVPC... or whatever):
http://www.xosoftware.co.uk/post/2010/02/02/Design-Patterns-(As-Used-in-the-Web-Client-Software-Factory-WCSF).aspx
You are separating software components and creating a design that is loosely coupled. This will allow for easier maintenance, easier to read and shorter code, flexibility, and expand-ability. Many things follow this design patter (websites, mobile apps, ect.)
I can promise you learning it is well worth your time. I would suggest jumping in and starting with something simple like (CodeIgniter, PHPBlueprint) just to get your feet wet and see an MVC work.
A good book to checkout would be Head First Design Patterns.
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 5 years ago.
Improve this question
I am a big proponent of agile, but a friend of mine (who doesn't know agile yet - hes a managerial type ^^) asked me how I would go about planning and developing a complex distributed project, with a database layer, comms layer, interface, and integration into embedded devices.
The agile method emphasises the concept of releasing early and iterating, but in the scenario of a project with many inter-connected components that all need to be functional for the whole thing to work, it would be difficult to release an early version without working on all the components. How would agile help my friend here? How best would he utilize it?
Teams in my company face the same types of problems. We are building projects with a large number of moving parts and architectural layers that make it difficult to create a working product early on. Additionally, there are often specialty resources that need to be scheduled or slightly out of synch with the team. Some approaches we've taken are below It has been challenging, but these approaches seem to be helping.
Build as vertically as possible
In other words, strive to have something working, end to end as quickly as possible. We typically get there a few sprints in on a 9-16 month project.
You'll often find a significant number of layers can be mocked or held back.
Often, the initial customer facing components are place holders. We create a limited bit of functionality that is something like what the customer wants, but is likely to be very different in the final project. This allows us to prove the rest of the product at a system level and provide visibility from a system perspective.
Separate base architecture from the product
Our early sprints are often centered around infrastructure/architecture. For example, threading subsystems, performance monitoring, communications and test frameworks.
Treat the subsystems as separate deliverables
Fully define each subsystem
Complete (truly complete, not just a partial implementation) each subsystem
Load test each subsystem within the context of how it will be used in the final product
Make your first iteration to be dedicated to architectural design, including the identification of the necessary components and the definition of the relationships and communications between them.
Once you have a clear picture of how the components interact, build the skeleton of each one. That is, implement "stub" components that just have the communication part on place, and the rest of the functionnality just do nothing or return test data. Have an interation dedicated to this task (including testing the component communication mechanisms) as well.
Then you can plan iterations to fully develop each component in the appropriate order, so that the system can grow in a ordered way.
TDD - iterate with incomplete parts after writing tests. Mock the bits that aren't ready. Sounds exciting.
It is unlikely that each layer needs to be complete for it to be usable by the other layers - for example the persistence layer could just serialize objects to a file initially, and converted to use a database when the need arises. I would look at implementing the minimum of each layer needed by the initial stories and fleshed out to add functionality as the the system grows.
Growing a system this way means you only implement the functionality you need, rather than all the functionality you think you may need at some indeterminate time in the future.
If you cannot break the large project into smaller parts that are useful (i.e. enable some use cases) on their own, agile probably won't help you that much in this project. You can pick some techniques like pair programming, refactoring etc. but the overall planning has do be done in a conventional way.
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
In my experience, UI programming is very time consuming, expensive (designers, graphics, etc) and error prone - and by definition UI bugs or glitches are very visible embarasing.
What do you do to mitigate this problem?
Do you know of a solution that can automatically convert an API to a user interface (preferably a Web user interface?).
Probably something like a JMX console
with good defaults
can be tweaked with css
where fields can be configured to be radio button or drop down list, text field or text area, etc
localizable
etc
Developing UI is time consuming and error-prone because it involves design. Not just visual or sound design, but more importantly interaction design. A good API is always interaction model neutral, meaning it puts minimal constraints on actual workflow, localisation and info representation. The main driver behind this is encapsulation and code re-use.
As a result it is impossible to extract enough information from API alone to construct a good user interface tailored to a specific case of API use.
However there are UI generators that normally produce CRUD screens based on a given API. Needless to say that such generated UI's are not very well-suited for frequent users with demands for higher UI efficiency, nor are they particularly easy to learn in case of a larger system since they don't really communicate system image or interaction sequence well.
It takes a lot of effort to create a good UI because it needs to be designed according to specific user needs and not because of some mundane API-UI conversion task that can be fully automated.
To speed the process of building UI up and mitigate risks it is possible to suggest either involving UI professionals or learning more about the job yourself. Unfortunatelly, there is no shortcut or magic wand, so to speak that will produce a quality UI based entirely and only on an API without lots of additional info and analysis.
Please also see an excellent question: "Why is good UI design so hard for some developers?" that has some very insightful and valuable answers, specifically:
Shameless plug for my own answer.
Great answer by Karl Fast.
I don't believe UI programming is more time consuming than any other sort of programming, nor is it more error prone. However, bugs in the UI are often more obvious. Spotting an error in a compiler is often much more tricky.
One clear difference between UI programming is that you have a person at the other end, instead of another program, which is very often the case when you're writing compilers, protocol parsers, debuggers, and other code which talks to other programs and computers. This means that the entity you're communicating with is not well-specified and may behave very erratically.
EDIT: "unpredictable" is probably a more appropriate term. /Jesper
Your question of converting an API to a user interface just doesn't make sense to me. What are you talking about?
Looks like you are looking for the 'Naked Objects' Architectual pattern. There are various implementations available.
http://en.wikipedia.org/wiki/Naked_objects
I'm not providing a solution, but I'll attempt to answer the why.
So I don't speak for everyone, but for me at least, I believe one reason is because programmers tend to concentrate on functionality more so than usability and they tend not to be too artistic. I think they just tend to have a different type of creativity. I find that it takes me a long to time to create the right graphics, compared to how long it takes me to write the code (Though, for the most part, I haven't done any projects with too many graphical requirements).
Automatically generating user interfaces may be possible to some extent, in that it can generate controls for the required input and output of data. But UI design is much more involved than simply putting the required controls onto a screen. In order to create a usable, user friendly UI, knowledge from disciplines such as graphics design, ergonomics, psychology, etc. has to be combined. There is a reason that human-computer interaction is becoming a discipline of its own: its not trivial to create a decent UI.
So I don't think there's a real solution to your problem. UI design is a complex task that simply takes time to do properly. The only area where it is relatively easy to win some time is with the tooling: if you have powerful tools to implement the design of the user interface, you don't have to hand-code every pixel of the UI yourself.
You are absolutely correct when you say that UI is time consuming, costly and error prone!
A great compromise I have found is as follows...
I realized that a lot of data (if not most) can be presented using a simple table (such as a JTable), rather than continuously try to create custom panels and fancy GUI's. It doesn't seem obvious at first, but it's quite decent, usable and visually appealing.
Why is it so fast? Because I was able to create a reusable framework which can accept a collection of concrete models and with little to no effort can render all these models within the table. So much code-reuse, its unbelievable.
By adding a toolbar above the window, my framework can add to, remove from or edit entries in the table. Using the full power of JTables, I can hide (by filtering) and sort as needed by extending various classes (but only if/when this is required).
I find myself reusing a heck of a lot of code every time I want to display and manage new models. I make extensive use of icons (per column, rows or cells, etc) to beautify the screens. I use large icons as a window header to make each screen 'appear' different and appealing and it always looks like new and different screens, but its always the same code behind them.
A lot of work and effort was required at first to do the framework, but now its paying off big time.
I can write the GUI for an entirely new application with as many as 30 to 50 different models, consisting of as many screens in a fraction of the time it would take me using the 'custom UI method'.
I would recommend you evaluate and explore this approach!
if you already know or could learn to use Ruby on Rails, ActiveScaffold is excellent for this.
One reason is that we don't have a well-developed pattern for UTDD - User Test Driven Development. Nor have I seen many good examples of mapping User Stories to Unit Tests. Why, for example, do so few tutorials discuss User Stories?
ASP.NET Dynamic Data is something that you should investigate. It meets most, if not all your requirements
It's hard because most users/customers are dumb and can't think straight! :)
It's time consuming because UI devs/designers are so obsessive-compulsive! :)