What do you think?
-
I'm a C#.Net programmer and what I like to do is separate classes that only hold data and those that have functionality. I like that architecture because it's clear cut and I can immediately find any data or method and don't have to think long about it or search around where some method is. I think it's a good approach for multitier architecture, so when I'd change the database I wouldn't have to change all classes but only the ones that handle db connection. On the other hand I'm not quite sure if that's really object oriented programming. For example I need to read some data about hotels out of a db, edit it and write it back. I'd have a hotel class and a dbconnection class. The hotel class only holds data like rooms, prices, etc. without any methods (except for a deep copy method I add to all my classes) and dbconnection class has all the methods. I can't really see the advantage of adding the methods for connecting to the db to the hotel class, but that would be actual oop, while I'm doing something close to procedural programming or?
-
I'm a C#.Net programmer and what I like to do is separate classes that only hold data and those that have functionality. I like that architecture because it's clear cut and I can immediately find any data or method and don't have to think long about it or search around where some method is. I think it's a good approach for multitier architecture, so when I'd change the database I wouldn't have to change all classes but only the ones that handle db connection. On the other hand I'm not quite sure if that's really object oriented programming. For example I need to read some data about hotels out of a db, edit it and write it back. I'd have a hotel class and a dbconnection class. The hotel class only holds data like rooms, prices, etc. without any methods (except for a deep copy method I add to all my classes) and dbconnection class has all the methods. I can't really see the advantage of adding the methods for connecting to the db to the hotel class, but that would be actual oop, while I'm doing something close to procedural programming or?
Megidolaon wrote:
I can't really see the advantage of adding the methods for connecting to the db to the hotel class, but that would be actual oop, while I'm doing something close to procedural programming or?
What you have done is keep a clear separation of concerns, and that's good practice (as well as being good OOP).
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
I'm a C#.Net programmer and what I like to do is separate classes that only hold data and those that have functionality. I like that architecture because it's clear cut and I can immediately find any data or method and don't have to think long about it or search around where some method is. I think it's a good approach for multitier architecture, so when I'd change the database I wouldn't have to change all classes but only the ones that handle db connection. On the other hand I'm not quite sure if that's really object oriented programming. For example I need to read some data about hotels out of a db, edit it and write it back. I'd have a hotel class and a dbconnection class. The hotel class only holds data like rooms, prices, etc. without any methods (except for a deep copy method I add to all my classes) and dbconnection class has all the methods. I can't really see the advantage of adding the methods for connecting to the db to the hotel class, but that would be actual oop, while I'm doing something close to procedural programming or?
Have you considered a HotelManager class? The hotel has things such as rooms, but its the HotelManager that actually uses your data to make money out of the hotel building. Setting, say, a price per room or having rooms cleaned by a cleaning company is definitly something the HotelManager rather than the 'Hotel' does. What we consider 'hotel' in reality is actually a combination of the HotelBuilding and the HotelManaqer. Taking this view, it's the HotelManager who should interact with the your data, rather than the hotel.