4 ms·

Often, you are only interested in a "view" of this object. A subset of the total methods and data of the real world object. For example, an inventory app ma

Often, you are only interested in a "view" of this object. A subset of the total methods and data of the real world object. For example, an inventory app may only car about the MSRP, dealer's cost, etc and not necessarily implementing the functions of a real car ( horn.honk() door.IsOpened). Now, software inside the car may well want to abstract the horn.honk() function for use. (maybe, i'm doubting it's that clean in implementation). Anyway, not ever app cares about ever aspect of every real world object. Hence lack of re-usability. Even 2 LOB (line of business) app may have different views to the same object. For instance, a telecom circuit. One app is concerned with the physical layout/design, where it runs, what equipment, what locations, what size (bandwidth) etc, etc. While another app may account for this circuit, figuring cost and revenue. Both may share data, but much more likely at a database level than actually pulling objects out of one, straight into another. I've just not seen that level of re-use in biz apps. String is used all over the place, but a highly specialized class for telecom accounting? Probably not. However, these apps probably share customer information because customer contact info is useful for billing and trouble shooting connectivity issues. So object re-use works great as a software vendor like Sun(oracle) or Microsoft. Java and .Net have some objects that see major re-use. Network, strings, web, drawing, etc. Very common, very easy to re-use. But LOB apps just don't have that re-usability. If they did, why would they need to hire you to work on them? They could just pull it out of the box.

adelle 16y ago
I'm having this problem right now. Simulation/Entity type object model is working quite well for one app, but add another app and the cracks in the abstraction become obvious. Using dynamic properties for the app-specific properties seems to help contain the problem. Also, putting app-specific code in extension methods. I see this problem as a limitation of our current tools. Splitting the object model into separate perspectives is too hard right now.
nlawalker 16y ago
Spot on about reuse - I think it's really the core of a lot of problems people have. Models get complicated because people naturally want to design them for reuse, when in almost every case it's just not feasible. You can't point to something like .NET and say "look at that level of reuse, our LOB applications should shoot for that," because entities in .NET represent things used by all computer programs, regardless of what they do. They model the machine and the network at a level of abstraction appropriate for the vast majority of computer programs out there - not all, but most. Trying to achieve reuse like that - hell, trying to achieve any reuse in a collection of LOB apps - is incredibly tough, and in most cases not worth it. What's an "employee?" Height/weight/age? ID number? Location? Skillset? LOB apps are just like people: they have different ideas of what are and what are not defining characteristics of an employee. Software development needs to focus on reuse of ideas, patterns and knowledge (both domain knowledge and computer knowledge), not code. The key to object modeling is making things loosely coupled and encapsulated enough that you can easily modify and add behavior later on, when you realize you actually need it, not throwing everything including the kitchen sink into your model. Even then, you can never be sure that your app or domain isn't going to take a hard left turn at some point and you need to do some major refactoring/remodeling.

adelle 16y ago

I'm having this problem right now. Simulation/Entity type object model is working quite well for one app, but add another app and the cracks in the abstraction become obvious. Using dynamic properties for the app-specific properties seems to help contain the problem. Also, putting app-specific code in extension methods. I see this problem as a limitation of our current tools. Splitting the object model into separate perspectives is too hard right now.

nlawalker 16y ago

Spot on about reuse - I think it's really the core of a lot of problems people have. Models get complicated because people naturally want to design them for reuse, when in almost every case it's just not feasible. You can't point to something like .NET and say "look at that level of reuse, our LOB applications should shoot for that," because entities in .NET represent things used by all computer programs, regardless of what they do. They model the machine and the network at a level of abstraction appropriate for the vast majority of computer programs out there - not all, but most. Trying to achieve reuse like that - hell, trying to achieve any reuse in a collection of LOB apps - is incredibly tough, and in most cases not worth it. What's an "employee?" Height/weight/age? ID number? Location? Skillset? LOB apps are just like people: they have different ideas of what are and what are not defining characteristics of an employee. Software development needs to focus on reuse of ideas, patterns and knowledge (both domain knowledge and computer knowledge), not code. The key to object modeling is making things loosely coupled and encapsulated enough that you can easily modify and add behavior later on, when you realize you actually need it, not throwing everything including the kitchen sink into your model. Even then, you can never be sure that your app or domain isn't going to take a hard left turn at some point and you need to do some major refactoring/remodeling.