Definitely not for anything where I even suspect I may re-use the functionality later on. Because re-use is one of the biggest benefit of OOP. You could actually stop there; forget about inheritance, polymorphism and the more exotic aspects. Just the ability to define a class for some basic piece of functionality and relish the opportunity to re-use it later on in a different development or change the internal workings for the better, without the calling developments ever knowing you did!!
That, and re-factoring. I love re-factoring. I could probably spend the rest of my life just going through other people's code in order to re-factor.
It's so fun!! Whenever I see a method containing more than 20 lines of code, my fingers start twitching. I usually end up with a phletora of private methods, each just a handful of lines long, but oh so clean and straightforward. The beauty of the principles of Clean Coding really makes my day, every day. I'd rather chop my hands off with a hacksaw. Because code is not only about functionality, but creating something that is esthetically pleasing. A procedural program, with its myriad forms, is ugly.
It's like reverting to prehistoric grunts and snorts after having mastered Latin. Or something like that. Or swapping Mozart for Katie Perry hope I'm not offending anyone's taste in music here.
It hurts. If someone already wrote some awesome object oriented code for, say, an ALV report or reading the files Eric actually has a good example in his comment below why can't we just copy-paste, uhm, adapt it? Does everyone really need to invent their own bicycle? One might scream again "this is not real OOP", but you know what - the heck with it. We need to start somewhere. I wrote initially that I enjoy both Mozart and Katie Perry, but it's not true.
Well, you try shouting Mozart at the top of your lungs in a car while sitting in traffic. What you need and what Head First provide Simplified example: I wrote a program that has a class for each operation carried out on data.
The check classes have three methods - pre, check, post. They can do radically different operations. Some derive values for other fields, some validate. The code looks something like. Here, each operation is entirely separate. I'm guaranteed that any changes I make to one won't affect any other.
As in know what it is, what it does, why you want to use it. Like, I can go to China and mutter a few sentences provided I rehearse from a recording of someone speaking Chinese but I wouldn't know the meaning, nor the cultural context, not to mention being able to reply to the subsequent comments from the native speakers. And, if I got one word wrong and ended up calling anyone something bad, I wouldn't know how to fix the situation.
Nor would a non-OOP programmer who just copies some calls to a method or two and gets an error because he failed to instantiate the object - or instantiates when all he needs is calling a static method which doesn't require instantiation.
I am going to modify my next blog such that I write a procedural version of the OO "state pattern" program I wrote, then we shall see which one is longer, mor complicated to understand etc. Then I will pretend the user has come up with more requirements, and see how much effort it makes to enhance the procedural version vs the OO version.
I'll start that tonight. Maybe the result will give me the example in letters of fire a thousand miles high I want. Matthew, you can write blogs very well exhibit A , please don't be coy. Explaining things is a lot more difficult. It's not something that comes naturally to me. But thanks. While there are far more important concerns than OO when designing for maintainability, that is its biggest strength.
The best way to make things maintainable is to have them loosely coupled. If the database selections for a report are handled with a global object and the display is handled in the local report, both the front end and back end are easier to modify.
It's highly unlikely you would get both requests at the same time. So either you change the global object to fetch more data, or you reuse the global object while building a web front-end. Although what I've described is possible with procedural, it seems easier with OO, and I've used both.
Here are my two cents:. Strengths of Object-Oriented Design:. There are well-known ways of building objects and relating them to one another in a common way design patterns , and their names make it easier to communicate with other developers. It's easier to say "MVC" rather than "I want to build collections of objects to handle the back-end and front-end components.
These were the hardest for me to learn, but they make massive CASE statements unnecessary, and all the different logic blocks can be refactored into their own objects. Abstracting away low-level details like this makes a program easier to read from a high level. You can write code like it's going to work, and then deal with all the error handling at the end of the TRY blocks, or anywhere it makes sense.
Just not right in the middle of your code. Can you tell what this program does even though it has no comments? I had a hard time getting the concept of interfaces until I thought about a friend of mine who's a voluntary fireman. How do you know a fireman? Easy: you spot the uniform. So, my friend, who's normally NOT a fireman, becomes one whenever he puts on his uniform.
Same with his other firefighting friends; the baker, the doctor, the nurse. The only assumption we have to make is that the uniform is proof of your fireman skills your methods. These methods skills are embedded in the uniform. They are predefined. You give the uniform to someone, and they're a fireman.
In addition to whatever else they might be. So clear example on Interface.. Never was able to explain to any one what exactly an interface so clearly I always find programming using Procedural approach comfortable and organized reason may be that I am ignorant regarding OO style of Programming.
That looks like you've got many global variables Global variables in procedural programming and remember I was a procedural programmer for many years are bad. It means all variables are in scope at all times. Mainly the problems come when someone else has to maintain the code.
That's so true I will admit, I rarely go for objects myself. BUT, one of the nightmares in procedural Then again, people who have huge TOP declarations are also probably the people who would have one class and stuff every data declaration in the class attributes, so that wouldn't be much different, would it? Oh, and one thing I "hate" about OO in SAP in particular , I have a lot of trouble debugging and understanding where to see the different variables' values But trust me I guess the problem is that in university the problems are posed to you in a way which is natural for you to "design" them in an object oriented way class vehicle, how many wheels, how many doors, class car inherits from class vehicle But, unfortunately, it seems that the real world doesn't like the object way so much I agree very much, however, with what someone said up here.
Having decent classes representing, for example, a sales order, or an invoice in SAP, with methods for the common steps like releasing, etc, this would be really helpful! Instead of each time looking for a BAPI or Function Module or whatever that can do whatever it is you're trying to do.
Because in one way or the other I know it will help me for future for eg while doing WD programming. Where you talking about Select-Options and Parameters? But such routines would most likely use totally different variables, even if they're global. What kind of a dumbass make a change without running a search? And even then "the consequences" would probably come up in testing. You know, I'm starting to agree with Paul Graham according to Wikipedia :. OOP's popularity within large companies is due to "large and frequently changing groups of mediocre programmers.
I hear what you and others are saying about OOP, but having worked in much smaller teams of great programmers I'm guessing the issues that others might have faced just never came up in my whole SAP career. Every time when, say, a program was difficult to maintain it was just because someone had no clue what they were doing. And clearly OOP would be of very little help in such case.
I'm guessing we just live in some kind of parallel ABAP universes. In mine we spend much more time on just getting a friggin' BAPI to work. Plenty, unfortunately. However, that's not the point.
With global variables, you are relying on the developer being consciencios. With proper scoping you don't. So you don't have to search, so it's quicker to make the change - and therefore cheaper. Further, if you do a search, you might find there's a collision. Now you've got to refactor the two forms, so that they don't interfere with one another.
More work. With proper scoping to start with, you don't have this issue. The discipline imposed by OO does indeed prevent too much damage.
But it also helps non-mediocre programmers make changes more quickly, with more certainty. Well, I don't think that proper scoping and OO are correlated. A mediocre programmer would, imho, fail in scoping his programs properly both in procedural and "OOP". Like I mentioned above, wouldn't a mediocre programmer just shove all sorts of variables in the class attributes and use them everywhere? I think a mediocre programmer would.
So, other than not being able to use obsolete statements and being forced to type properly every parameter, I don't see what kind of discipline in scoping is imposed by OO. PS: And I've seen this kind of OO wannabe type programs that simply have a shovel-load of variables in the class attributes and use methods as routines.
This is pure procedural in poor OO camouflage, that's all. I wasn't clear. I was talking about scoping in general, and then commenting on Jelena's quote.
However, I do think that a conscientious mediocre programmer is helped by the constraints of OO programming. If you had said "I don't think that proper scoping and the use of classes are correlated" I would agree with you but good OO design, by definition, means that your objects are encapsulated properly. I think it's very important to note that using classes or even poorly designed objects, for that matter does not mean your program is "object oriented". OO is an approach to designing programs so that objects interact with each other via published APIs ie.
So, point in case, it's not enough to write a program using classes and methods to "say" that you are programming in OO. And, imo, a mediocre programmer is not able to design a proper program in OO, regardless of using classes and methods. And I think I am probably in that group of mediocre programmers because I would definitely struggle to design a "classic ALV report" worthy of the "OO stamp", even using classes and methods And having said this It is simply a procedural program written with classes and methods.
For me, having a class called "main" that does everything is not OO at all. Thanks Bruno for the suggestion. My intention of this blog from first line is get the hang of OO concepts and never to explain advantages or design pattrens to follow. Thanks to every one for sharing lot of knowledge which i learnt a lot more from this blog comments. This thread has actually inspired me!! Right now I have a requirement that needs the information if a country is a member of the European Union or not.
If it wasn't for this thread, I would write a very simple select to table T and that would be it Even if the rest of the program is procedural, at least this is proper OO, and of course the potential is huge. If needed one would be able to create a subclass "european country", etc etc Until recently i was not in a position to dictate design of an application. And for the record had one of my designs scraped because the development lead thought -.
Anyway i had a chance to build a critical from a business perspective report on my own. Here are the 2 blogs i had published based on my experience -. I hope you'll enjoy reading these. First-things-first I am not a guru , just a learner. Message with Type E coming like that of Type A. Data records not being fetched completely. I am no exception. I wanted to participate by presenting my version of the code. I ended up with lines and more objects than you Probably i will pick up from here and start explaning things and advantages as conitinuation to this blog.
Thanks so much for your contribute. I got very intrigued about the "factories" you used and you got me reading about their advantages and when they are best used, because the advantages were not understandable for me from this example, and I don't think there are any. Maybe if the program has to be enhanced somehow. However, I think your contribution is a clear example of when using OO might not be the best option, replying to Matthew here or was it Paul?
So, if I compare your example written in "proper OO"? Nevertheless, I will understand if someone argues that this is too simple of an example for it to have any representative value. Factories are best uses when the author of the class wants to control the creation of instances, rather than allowing the class consumer to do it.
I recommend reading sourcemaking. There is even a page from Martin Fowler's Refactoring book about converting procedural-design-to-objects. OO is all about Analysis and Design. But I assumed here that requirement changes like new selection parameter or getting additional data from MAKT or MARC would effectively break the application and force a re-design. So this a design with some trade-offs for a specific problem. We could have an argument about which requirements are more likely to change.
I have made my choice, and I have derived a design. I think using OO forces to think more about design. With "procedural" style, bad design is not obvious. So often, I've done the modelling for an application and certain things that weren't clear, suddenly became blatently obvious through the modelling.
Further, at the modelling stage which is even cheaper than the syntax check stage design errors can often be clearly seen and dealt with.
People often use Factory Method as the standard way to create objects; but it isn't necessary if: the class that's instantiated never changes, or instantiation takes place in an operation that subclasses can easily override such as an initialization operation.
And from what I've seen in the article, factories are important when you want to provide different objects usually subclasses , which is not happening in your example.
So, even though I'm thankful for it because it tought me about factories, I still don't see the point in using them in this particular example. Couldn't you simply do this in a constructor method? You mention the constructor method is private, which one? You have control over the visibility of a constructor, and it is recommendable for the constructor to be private when you use factories, if you don't use them the constructor will obviously be public.
In a reply to Jelena Perfiljeva you also mentioned the "power of abstraction". I think nothing can be said about the power of abstraction in the SALV class. I can use it easily without having any idea on how it is implemented. That's the definition of abstraction to me. I give it a table and it displays it for me with an ALV.
I also don't have any idea on how it is implemented, and I can also use it, even if I prefer SALV much better, but I just want to say that abstraction is not exclusive to OO.
However, I don't think the classes written in your example really are candidates for the "abstraction and reusability stamp". I guess I'm learning! But I have the following question Regarding the other classes, PARAM and MARA, they have to be used together and any changes in the requirements for the parameters would mean a change in code everywhere, so impossible to reuse them without caring about the implementation imho.
I hope you don't misinterpret my comments. If you request a reference to, e. It's like a buffer. It does, indeed, look fantastic!! And like you said, writing this in procedural would have probably been a nightmare and not elegant at all. I will assert using factories instead is a good habit to assume because:. Your definition of abstraction is linked to functions.
With objects, the client should only care about the class public interface including e. We have to learn criteria to evaluate OO decomposition. I value. ABAP does not support generic table types in data reference. I am not sure I would go for it. The param object is a immutable value object , i.
The updated factory methods should now return the subclasses instead of the original classes. I welcome your feedback. OO leads to design thinking and challenging a design helps make it better. And what's great about OO, is that you could easily talk over the design with a Java developer, for example.
Don't get me wrong, but do you really need object-orientation to discuss design with another developer? Technically you should be able to discuss any design with another developer who has learned algorithm design and not just a particular langague.
The implementation details of the design might vary, but that's a whole another topic on semantic vs physical algorithms. Design patterns give a common language across OO that isn't language dependent. The strategy pattern, the decorator pattern etc. I would say, if you'll allow me, and this is just my opinion, for what it's worth, but I would say:. First, get your head straight and learn how to design and think in OO which is what I'm trying to do now.
Because I've seen some nasty OO developments, with shovel loads of variables in the class attributes, just like those huge top includes, and then shovel loads of "parameter-less" methods everywhere. If yes, i think you can accuse me of doing that too. Now can "procedural programming" cater to this.
In my opinion that completely defeats the purpose of OO programming and renders any claims for better maintainability of OO false! Actually, I wouldn't call that OO programming.
Like I've mentioned before, that is nothing more than procedural programming using classes and methods. If what you do is anywhere close to what I've seen before. So what you managed to achieve with going for classes and methods instead of FG and FM is that developers reusing your stuff will not be able to access the variables inside? Problem solved. So again the question is: can programming with classes and methods be called OOP?
Or does design and properly defining objects and relationships play the most important role here? Even procedural programs can have SoC. Of course not. And yes, i can encapsulate the data that's even better. Exactly, he has to change my class. What if there is someway to restrict him from changing my class I've no idea how to do that may be using custom namespace, restriction on package level etc? That's what encapsulation is all about, isn't it?
That way even an SAP standard class is not totally encapsulated, i can create a post-exit enhancement with access to pvt. Does that mean "encapsulation" is just a myth? This introduces a little bit of safety already, as many developers are a bit leery of changing someone else's code.
It also makes the conscientious programmer or the owner think before changing the class. Of course, if you're faced with a cowboy programmer, you're stuffed anyway - they'll do what they want. In your FI example, however, if you have a complex class with a "shovel load" of attributes and "parameter-less" methods, I would maybe then create a class objectify the open docs, closed doc, etc?
And look at the potential! Also, in my opinion, encapsulation doesn't mean people are not able to "reach inside the box", in my opinion it means they don't NEED to. I have my way. As for the right way, the correct way, and the only way, it does not exist.
That is where i would like to have something similar to persistence classes, but they dont work with large datasets. Thanks everyone for being so open to discussion and replying in such a meaningful and concrete manner. I feel this discussion has presented me with many new concepts which I will definitely be looking into for my future developments. I have a new requirement which requires for some customer info. So I thought There wasn't any standard class for customers that looked nice, so And then I thought For now I don't foresee any use for a factory but maybe in the future a requirement will arise to have a specialized sub-group sub-class of customers, so I guess predicting this and using a factory is always interesting.
But I failed miserably Also, why isn't there some kind of repository with these kind of reusable classes made by the community? I've started for country and customer I know there are already some standard ones existing, like purchase order I think, but the community could extend it and it would be great for everyone, now?
You mean something like this Project Objectify. As someone also mentioned, in case of a simple report the procedural code just seems to be more organized and straightforward. Looking at another example in Katan's blog , I just keep thinking "but why? By any means I'm not trying to drag everyone back into the "dark ages". But sometimes "good enough" is just that. Not everyone has all the time in the world to think of some kind of special design for a report that would otherwise take an hour to write.
I might be just lucky, but except for some very, very poorly written programs which OOP would not solve I'd say our maintenance costs are very low. So I'd have a hard time "selling" to IT management an idea to invest more time in the OO development upfront. Also I believe none of the "procedural to OOP" blogs I've read so far actually uses a good example to illustrate the reusability which would probably be of most interest to everyone.
At the least it needs to be shown how the same code can be reused in multiple programs. For example, in my old job we had several programs that uploaded the files.
There was a parameter for file name and a checkbox to specify whether the file is uploaded from an app server or a PC for testing. We had a routine in an include that just took those and returned the file in an internal table. This might be a good candidate for OOP re-write and a more practical example.
I actually converted last year a set of data load programs between a procedural approach and an OO approach. The old procedural approach had individual load programs that used a common subroutine pool. The new OO approach allowed me to create a base interface and then a root implementation and then sub-implementations per process.
It allowed me to focus on implementing "four unique" methods per process instead of copying and pasting a ton of similar code in new programs. The overhead of creating the framework was more work, but later on in the project when I needed to a create a new load for a new process, my effort to create was reduced.
In addition I also was able through the use of inheritance to not have to throw out all pieces of a load process but re-write parts of the process that changed when I went from flat-files to XML. I had better isolation and separation of relevant tasks. However it was the "design" of my programs that allowed for this and by taking an OO approach it made it possible. The great part is this was for "throw-away" code as a conversion program.
Keep in mind that my code probably violates some OO design principles because I don't care about method size and only care if a method is re-usable and performs a single logical task. In other words I only care about logical separation of code rather than line count or trying to make a complex class hierarchy.
The point is even if you don't dive into the full OO design patterns etc, moving away from procedural and just structuring your code in a reusable, object based design using ABAP objects will still give you the benefits. I honestly think for most folks used to procedural that it's better to move to object-based code using ABAP objects than trying to design full OO starting out.
With Java, feel free to follow pure OO philosophy. With ABAP be pragmatic. I was on a project comprising can't remember exactly exit functions in BPS a module that sits on top of BW. The first things I did was to write a framework. From my previous experiences of these The framework put all of these into one class, with a handful of abstract methods for the actual logic. Every exit function was then implemented as a subclass of this class, just implementing those abstract methods.
Any change to an exit function changes affected only that exit function. Importantly, it didn't lock any other exit function - this was in stark contrast to the way it had been done previously using function modules in function groups.
A syntax error in a function module, killed the whole group. A syntax error in a subclass only affects that class. Experience suggest the choice of what components of a complex system are primitive is relatively arbitrary and is largely up to the discretion of the observer of the system Booch et al, Object-Oriented Analysis and Design with Applications, 3rd Edition. I hope you realize both have a quite complex implementation.
I think our long training with functional decomposition lead us to see those statements as primitives. Objects are primitives in OO decomposition. With this in mind, my version of the report with 4 objects is still quite simple.
Check the class diagram in my first comment, and the sequence diagram:. My goal is to derive classes with a single responsability and few depencies, then write the rest of the code in term of those classes.
The typing is a killer? Haven't you got code completion switched on. But on the tenth time, the advantages of OO will enable the change to be made more quickly, and with less risk. And therefore cheaper. Not all developments are small.
But to start your journey into OO with a big development is foolhardy. Start with a small one. You may believe your maintenance costs are low, but I have to emphasise. The research done has demonstrated beyond reasonable doubt that maintenance is a significant cost of the Total Cost of Ownership even for well written programs.
OO has been demonstrated again and again to reduce TCO, therefore your management should be an easy sell. All the papers and metrics from reputable sources about this are freely available. A programmer who cannot make the switch as a corollary is neither average nor good, and should be quietly shuffled to a role where they can make a more cost-effective contribution.
Perhaps a management job. Googled 'object oriented programming cost' and, interestingly, one of the top links is this discussion on StackOverflow. It's a bit old but has many interesting points. In all honesty, I haven't spent a lot of time searching, but doubt there are studies specific to SAP regarding cost benefits of any particular programming methodology.
Not sure the studies in other environment would be of relevance to many SAP teams - we're not building a second Google here after all. I totally agree that in SAP we need to be pragmatic. And I think this is perfectly fine and it's exactly "pragmatic" or "realistic"? Anyway, I'm hoping more SCN blogs and documents will come out of this very interesting and productive discussion.
Without a doubt we can all learn a lot from each other. I agree with Jalena. If you need to spend so much time to "maintain" , itself means they were clueless about what they were doing, and this does not include the programmer alone or the procedural way of coding. In my consulting experience I have come across several people who still used procedural way, projects demanding "quick" solutions and teams excellent in procedural ABAP and they wrote great code. On the other hand when clients were more flexible, we were able to deliver entire solution using ABAP and build a class library for custom functions.
When I started my career, I was a VB programmer. This all reduced lot of coding and most importantly implementation efforts. However my TL felt, the programming is more complex and I being the only capable resource it is not a good idea to deploy it. Still upon my constant insistance and providing a proper trasition before I left that company 1 installation took place, But I kept receiving calls for nearly 6 months. That was a big eye opener. Never use technology unless a good support team is around to support.
You can not escape saying I don't know who is going to support it or they have to be good at it. I think you misunderstand. When measurements have been done by big software development companies with a vested interested in the answer on where the cost of a development lies between first concept to the development being retired, it was found that the majority of the cost is in maintenance, support and enhancement regardless of the quality of the code.
For poorly written programs the percentage is higher than for well written programs. If you don't make your programs simple and easy to enhance and fix when they go wrong as they inevitably do , you are increasing the cost of your programs dramatically. In order of cheapest to most expensive for fixes.
It doesn't matter if I write it procedurally or OO, it's going to be all over the place. Let us say someone else comes along and takes nine hours to get it working the way it was supposed to in the first place.
Is that a common occurrence? Every year the governments around the world change various taxes and this has an impact on the payrolls of companies running SAP. The object-oriented approach focuses on objects that represent abstract or concrete things of the real world.
These objects are defined by their character and properties that are represented by their internal structure and their attributes data. The behavior of these objects is described by methods i. As object orientation begins to take shape, each class assumes specific role assignments. This division of labor helps to simplify the overall programming model, allowing each class to specialize in solving a particular piece of the problem at hand.
Such classes have high cohesion and the operations of each class are closely related in some intuitive way. Sanjo Thomas. Skip to Content. Former Member. January 14, 1 minute read. Alert Moderator. Alerting is not available for unauthorized users. Assigned Tags. Similar Blog Posts. Related Questions. You must be Logged on to comment or reply to a post. Sijin Chandran. Hello Chitturi , Must say a very helpful document. Very much required. Keep it updated.
And am sure the list gonna be a bit more long. And please format 23rd and 25 row its looking odd. Like 0 Share. Right click and copy the link to share this comment.
Former Member Blog Post Author. Hi sij, Thank you for your support. Hi Chitturi , I had formatted the same. Hi sij, Thanks a lot and I welcome you to do some more additions too if you have a minute time to spend on this doc. Hello Chitturi , I would definitely like to add some. OK thank you. Regard's Smruti. I sent a mail on this one to sapnetwork technical team. Thanks in advance.
0コメント