Adding layers
-
Naerling wrote:
At this point, is anyone really disagreeing with me?
Nope. Adding abstractions which make your code more easy are always good. But keep it in mind, more generalization will make lot of trouble and you will end up layering over and over to satisfy all the requirements. And these kind of abstractions won't help you on other projects as each project will have different requirements. So if you plan you generalize too much, you will end up writing another ORM tool like hibernate. An interesting read : Law of leaky abstractions[^] :)
Best wishes, Navaneeth
Thanks for the article. I'll be sure to read it later! :)
It's an OO world.
-
I've been programming with .NET for half a year now. It's all pretty great and fairly easy, but I can't help to think that some classes/components were made to have an extra shell around them. Take the whole process of connecting and reading/writing data from and to a database. At the very least we need a Connection object and a Command object and dependent on what you want to do you need a DataReader, DataAdapter, Parameters, CommandBuilders, etc... It seems to me that constantly creating all those objects, configuring them etc. seems like a lot of work. So it would seem to me that it is easier to create a class that requires some parameters in its constructor, has some methods and functions that manage all the just mentioned classes and simply gives a resultset using something like DBClass.Execute. Basically it would then look something like:
Dim myClass as New DBClass(aString, commandType, connectionString)
myClass.AddParam(name, DBType.Int, value)
Dim result = myClass.Execute ' Or myClass.ExecuteASync!
' Do stuff with the result.Another example of stuff that just screams for an extra layer around it is the whole printing process. Have the PrintDialog, PrintPreviewDialog, PageSetupDialog, PrintDocument, maybe PrinterSettings, the whole event thing... I just want to say:
Dim p as New PrintClass(document)
p.Print ' Or, once again, p.PrintASync! ;)At this point, is anyone really disagreeing with me? Or do you really agree and know some other stuff that just calls to be put away in a programmer friendly class? :)
It's an OO world.
Its a simple design pattern named as "Facade" There are low level functions available in an API, but you might need to expose simpler interfaces to your "common" users; those who need very generic functionality. For specific cases, the users may take the pain of going deeper, but 95% of time, its not required. Hence wrapping an intricate functionality into a simple API (the target of Facade design pattern) provides both common as well as specific users the level of functionality desired by them. OOPS has lots to learn, and the more experience you get, the deeper you can think. Its good you want to get into design in 6 months and you would sure grow up to a happy professional :) Cheers (BTW: include design patterns in your quest, they would tell u a lot how things are designed)
-
Its a simple design pattern named as "Facade" There are low level functions available in an API, but you might need to expose simpler interfaces to your "common" users; those who need very generic functionality. For specific cases, the users may take the pain of going deeper, but 95% of time, its not required. Hence wrapping an intricate functionality into a simple API (the target of Facade design pattern) provides both common as well as specific users the level of functionality desired by them. OOPS has lots to learn, and the more experience you get, the deeper you can think. Its good you want to get into design in 6 months and you would sure grow up to a happy professional :) Cheers (BTW: include design patterns in your quest, they would tell u a lot how things are designed)
Thanks for your reply. Actually this topic is already a few weeks old. I have read up on various OOD principles and design patterns and it already helps me in day to day coding. I have not looked into the Facade Pattern a lot yet, but I will certainly do so. The problem with this pattern for me is where do you keep the line between abstract and real implementation. It seems really hard to make a Facade Class 'Closed for Modification, but Open for Extension.' ;)
It's an OO world.
