Browse DevX
Sign up for e-mail newsletters from DevX


I Object : Page 2

Stop writing dataset-centric programs, start thinking about true object-orientation, and let's join forces to write programs and design architectures that are easier to understand and more accessible to all.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Building Quasi-intelligent Software
In order to build such software, you need to think about long-term things like scalability, extensibility, and maintainability. These things cannot be offered by the drag-n-drop experience advocated in Microsoft demos and fly-by-night consultants. They cannot, indeed, be offered by abusing the DataSet as a solution domain. Not only will such abuse negate key long-term returns on investment, it will also unnecessarily complicate the solution domain because you are trying to fit a square peg into a round hole, using a hammer as your only tool, and other such nifty and overused aphorisms. Yes, a DataSet can make persistence easier, but then you have to create other hoops and make it jump through them (e.g., "strongly-typed DataSets") in order to create a workable solution to your problems. A DataSet forces you to think in terms of the persistence platform instead of in terms of the problem domain and doesn't make it easy to address that problems that you are attempting to solve.

On the other hand, you could start with your problem domain—the real-world issues that you are attempting to solve—and model your solution using objects that correlate to that domain and behaviors that occur in that domain. Things will naturally fall into place then—you won't be wrenching the problems into your (or Microsoft's) predefined solution but rather your solutions will flow naturally and easily from your problems. Your solution objects will look like your problem objects, and they will behave alike. Note this implies that your design is not data-centric but behavior-centric. When solving problems, making decisions, and taking action, we only need data inasmuch as it assists in executing the behaviors that need executing. This is so central to OOD, and I know that most developers don't see it. (Trust me, I've argued with lots of them.)

We must stop looking at computers as just a handy way of storing data and start seeing them as facilities that make our lives easier, more efficient, and generally better. Instead of focusing on making data easier to store and read, developers should be focusing on making the business processes that the data supports more streamlined. Data only matters because it helps us make informed decisions, that is, to behave in a way that is most beneficial to us.

It seems that many people have missed the mark as they continue to think of OOD and OOP as just a way to group data intelligently.
It is almost absurd to be having this discussion now given that object-oriented design made its debut so many years ago. Nonetheless, it seems that many people have missed the mark as they continue to think of OOD and OOP as just a way to group data intelligently. That's just plain silly—that's what relational databases do! Let the database worry about how best to store data. Let the new-fangled business intelligence architects worry about how best to mine that data to produce reports that help drive key business decisions. And let us, the application architects, worry about how best to automate business processes.

You may be thinking I've digressed, but I haven't. This all speaks to the central topic here, which is, simply put, that you should not be using DataSets to solve your business problems except inasmuch as you need help persisting data. It can happily play a part somewhere in your solution, but it should not serve as the solution domain for custom software applications. Your solution domain should be composed of classes of objects that address the problems you are trying to solve, classes that are defined by their behaviors and that use data (perhaps even from a DataSet in the background somewhere) to inform their behaviors.

You should be building and buying tools that make this kind of object-oriented design easier to implement. This argument for DataSets from ease of implementation is, at best, a compromise and, at worse, a plain and simple lie. And the argument from developer experience will fall away as we make OOD better and more widely understood and as we make tools that require less and less experience to do good OOD. Don't get me wrong, I'm not saying that the architects at Microsoft are ignorami who are unaware of the things I'm talking about, nor are, necessarily, the folks who advocate DataSets as a good approach to custom software development. I think anyone who has been working with Microsoft technologies prior to .NET has, necessarily, been coerced into using data-driven design by previous earlier development platforms that did not support OOD.

DataSet thinking is a natural outgrowth of computing history up to this point, particularly in the Microsoft world. We do need ways to simply access, modify, and store data, but the industry has evolved tools that are specific to address those kinds of needs and will continue to evolve such tools (like Office, InfoPath, OneNote, WinFX, SQL Server, etc.). These things have become so easy as to, most of the time, not require a developer's time. Surely, custom development should not be (and often is not) doing just those things any longer; if it is, you need to re-evaluate whether custom development is truly needed. We need to move on to the next great thing, building on the shoulders of giants; that is to say now that we can do more for ourselves and in better ways, let's do it. Let's focus on what custom software truly brings to the table, make it easier to do that, and just do it.

Objects have been (and, ironically, still are becoming) the next big thing in software development. I don't see how they will ever be totally superseded precisely because they allow us to address real-world problems through software in natural ways. Surely we can continue to create tools that make OOD easier to design and implement, more efficient for computers to execute, and address limitations of technology. OOD is not at odds with or obsoleted by these goals or even by trends like SOA; rather these are (or should be) supplemental to OOD. Thus far I have not spent much time speaking to the benefits of OOD but have rather focused my efforts on dispelling the notion that the DataSet is a viable solution domain. This is partly because of the already-mentioned acquiescence that OOD is best if you have time. And I wager the reason for that general agreement is that it doesn't take a rocket scientist to know that a solution that is tailored to a problem will be of higher quality than one that is a general solution to be amended to fit.

This is true in nearly all human endeavors; just think of clothing, food, cars, houses, landscaping, etc. Custom is better. Having a solution that naturally solves a problem because it is tailored to fit is better by all accounts save economy. And it is no different with software. So, rather than attempt to make a one-size-fits-all solution, shouldn't we rather focus our energies on making custom solutions easier to implement? We still need to solve the economy problem, but we needn't sacrifice good design to do it. So since we've agreed that custom solutions that naturally fit a problem domain are better, why continue to have discord about this subject? Let's leave the object versus DataSet diatribe behind us and join our forces to make better and truly reusable architectures (reusable across similar problem domains) that are easier to understand and more accessible to all. But we have to commit to taking the first, painful steps of learning and, consequently, teaching others before we can achieve that goal. Who is with me?

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date